How to keep your microservices available by monitoring its metrics

It’s not a secret that microservices increase many things in your project: including its complexity.

Imagine that beautiful picture: a lot of services stopping in a domino style, and you can’t figure out where it started, what happened, and who will be the next one to fail. Nightmare!

That’s why there’s metrics and monitoring processes. They allow you to not be “reactive” (#jokealert). Instead, you can be prepared for anything.

This article will cover some aspects on how to use metrics to keep your services available and how it can be done by using Helidon, specially its MicroProfile implementation.

About metrics

First, let's understand what is a metric:

Metric is a measure used to evaluate, to control and/or to select quantitatively: a person, a process, an event or an institution.

It's important emphasize the word *quantitatively*: an useful metric have to be concret. It needs to be something that you can measure in numbers, not in concepts.

For example: you do your anual review with your boss and he/she said that you did great this year because you worked very well with your team mates. That's a concept, we can't consider it as a metric for our purposes.

But, instead, he/she said that you did great because your brought $1M to your organization, and your goal was $800K. That's a metric (and a good one for you, congratulations!).

It's measurable, countable and comparable. You can consider limit, average, sum, etc.

Metric ≠Healthcheck

Sometimes there are some misunderstanding of what is a metric and what is a healthcheck, and some people may think they are seemed to each other.

Healthcheck is anything that's says that some service is alive or not.

"Hey service, are you alive? Yes!"

"Hey service, are you alive? No…"

Ok, that's a good information for instance, but usually it's not enough. Just because a service is alive, doesn't mean it's working well. That's where metrics are pretty usefull.

Metrics helps you to qualify the health of your service. To exemplify it, let's use the Rocky Balboa service.

Scenario 1: Before the fight

Healthcheck: I'm Rocky Balboa. I'm alive.

Jab strengh: 100%

Bleeding: 0 ml/s

Vision: 100%

Sweat: 1 ml/s

Confidence: 10

Pronounce: "Adrian"

Here our Rocky Balboa service is doing great! Now let's compare it after a while.

Scenario 2: After 15 rounds against Ivan Drago

Healthcheck: I’m Rocky Balboa. I’m alive.

Jab strengh: 0.5%

Bleeding: 100 ml/s

Vision: 1%

Sweat: 200 ml/s

Confidence: 0

Pronounce: “Aaanhanaaannnn”

Here our service is alive, but facing some issues. He will run out of blood in a few seconds, he barely can punch his oponent… and, the worst part: we can't understand what he is saying.

That's how a metrics works together with a healthcheck. It will gives you important information about usage, performance, peaks and or idleness, to say a few of them. By monitoring and make a good use of these information, you can, for example:

• Plan when/how to scale up or down
• Define when you need a vertical/horizontal scaling
• Decide to break down some part of your application to a separated service

It will helps you not only to keep you microservices available, but also to have a smart use of your resources.

MicroProfile metrics

There are 3 types of metrics in MicroProfile specification.

1. base
2. vendor
3. application

Base is required for any MicroProfile implementation and has 4 groups of metrics:

• JVM
• Threads
• Thread pools
• Classloading
• OS

Vendor is optional and, as the same suggest, it's any metric created by a vendor on its own implementation. It's not portable.

Application is optional and is created by you (you powerfull developer!), in your application source code.

All metrics in MicroProfile are exposed by using a Rest API and has two output formats: JSON and Prometheus.

In both formats you have the same types of metrics:

• Gauge
• Counter
• Meter
• Histogram
• Timer

Take a look at the examples bellow:

Gauge JSON

Counter JSON

Meter JSON

Histogram JSON

Timer JSON

Metrics oriented code

We've seen there is a metric type called "application". That's where you can create your own metrics, specific for your own application.

The way that you do it from the MicroProfile specification is really simple: just add an annotation:

Gauge metric example

And here is the full list of annotations and their use:

M=Method, C=Class, T=Type

Now that you get it how to add metrics to your application, let's go deeper with Helidon specifics.

Helidon

The Helidon project is:

• A set of libraries for microservices development
• Open Source (Apache 2.0)
• Helidon SE: microframework
• Helidon MP: MicroProfile implementation

To compare it to others microservices frameworks:

The image bellow shows how SE and MP relates to each other:

As you can see, there's a "Cloud Integrations" described in the Helidon architecture. It's prepared to allows you to integrate your microservices with you preferred cloud provider.

Helidon SE has much more a functional style programming, like this:

Helindon MP, on the other hand, has a JAX-RS approach. Like this:

For example, a Timed method using a Helidon MP would be like this:

On the other hand, a Counted method using Helidon SE would be like this:

No matter which one you are using, your Helidon application will expose and handle metrics in the same way. So you can monitor them no matter what.

Now it's your turn! Try your own code using MicroProfile metrics and let me know the results.

If you want to check more code using both Helidon MP and Helidon SE, check out the full source code that supports this article:

eldermoraes/helidon-metrics

Also, check the MicroProfile Metrics specification and Helidon project page:

eclipse/microprofile-metrics

Helidon