Don’t Keep your Monolith in the Dark, Monitor it as a Microservice
By: Gil Adda
Tags: Elasticsearch, Serverless, Monitoring, Monolith, Methodology

The evolution to cloud services, microservices and serverless applications brought with it a standardization of monitoring methods for cloud services. Those standards evolved based on experience of SRE engineers from different companies. For those of you who may have a monolith application, microservices monitoring methods can still be applied.

Today, I’ll dive deeper into those standards and how to apply them. Doing so will provide you with insights on your monolith application health, usage metrics, errors and bottlenecks.

Monitoring Standards in the Microservices and Serverless World

Monitoring standards can be split into Resource Usage Monitoring and Application Metrics Monitoring.

Resource Usage Monitoring

Resource Monitoring deals with collecting resource statistics. Resources are CPU, Memory, IO (network and disk), disk space and external services availability (network shares, databases). With so many parameters, which one do you use to monitor? You may start with the usual suspects, memory, disk space, IO and CPU. The USE method described below, defines what to collect per resource.

The USE method by Gregg Brendan, describes how to collect the following metrics per resource:

Usage — resource usage amount, e.g. amount of memory the process uses

— resource usage amount, e.g. amount of memory the process uses Saturation — degree to which the resource has extra work it needs to service, often queued

— degree to which the resource has extra work it needs to service, often queued Errors — number of resource error events

USE Method dashboard of a Kubernetes cluster node

Application Metrics Monitoring

On the other hand, Application Metrics Monitoring is about collecting internal metrics from the application to identify modules’ capacity and errors. This could be the number of HTTP requests and response codes generated by your web server. The metrics to collect are described by the following standards:

The RED method is described by Tom Willkie and derived from the “Google 4 signals” standard that is described below. These metrics below are relevant for both a microservice and a monolith application:

Rate — number of requests, per second on your function call

— number of requests, per second on your function call Errors — number of failed requests, and their type

— number of failed requests, and their type Duration — duration of requests. It may be the average per period, and a histogram of percentiles of it

The 4 Golden Signals method was published by Google SREs and contains 4 metrics. The 3 metrics in the RED method above (though named differently) and an additional metric called Saturation. It measures the function load as the number of requests waiting to be processed. High saturation means high load on the function. Note that CPU utilization, is not always an indication of a high load.

The APDEX score is an open standard to measure the actual users’ service level vs. planned application performance. The score is from 0% (lowest) to 100% (best) and is calculated by dividing the sum of satisfactory requests and half of the tolerable requests by the total amount of requests. For example, we planned a response time of 500 milli-seconds, however, we got 50% of calls below 500 milli-seconds and 30% below 700 milli-seconds (our tolerable response time). Our APDEX score is 65%, calculated by (50% + 1/2 * 30%) / 100%

Monitoring your Monolith as a Microservice

In this section, you will see how those methods can be implemented in a monolith application.

Resource Usage Monitoring

You can implement Resource Monitoring by using a monitoring agent that will collect information from the system OS and processes. The metrics should be those described in the USE method.

Application Metrics Monitoring

Application Monitoring can be done in the following way:

Split your monolith system into modules. Each module should declare one or more interfacing function, that the flow passes through. If you miss a clear interface function, maybe it’s time to re-factor the code. Let’s discuss a monolith application dealing with Stock and Order management

Choose the important business and user flows . Try to focus on the most important ones. Break one major flow at a time into a sequence of calls, passing through the modules and the interfacing functions.

. Try to focus on the most important ones. Break one major flow at a time into a sequence of calls, passing through the modules and the interfacing functions. Identify the “Interface functions” that will expose metrics. In the diagram below, you can see the flow passing through the “interface” functions.

Choose a software library -to expose metrics from the selected functions to your monitoring system. For example, open census or micrometer provide a common data model (e.g. counter, gauge, histogram objects), and the ability to send metrics to various monitoring systems. But a moment before, you need to decide on your monitoring technology. If you don’t have a monitoring system, CNCF has a number of options to choose from.

-to expose metrics from the selected functions to your monitoring system. For example, open census or micrometer provide a common data model (e.g. counter, gauge, histogram objects), and the ability to send metrics to various monitoring systems. But a moment before, you need to CNCF has a number of options to choose from. Reporting metrics — after integrating the metric reporting library (sometimes called instrumentation library), it’s time for reporting metrics. The RED method convention will a good start for the selected functions. Later, the saturation and the APDEX score can be added.

Graph Your Metrics

Graph your metrics on dashboards to give you a clear picture of where your monolith system functions spend time and which of them raises errors. Aligning the dashboard close to the flow sequence of calls, will help you to identify the probable cause. The last function with the occurrence of the error, is closer to its source. Grafana or Elastic Kibana are good examples of dashboard systems.

Dashboard of request rates

To measure user experience, calculate the APDEX score based on the RED method metrics, and display it in your graph as a single metric. If you monitor your APDEX score constantly, you can set an alert and react when it downgrades.

Applying cloud services monitoring standards allows you to concentrate on the user experience, system capacity, errors and their probable cause. The way to implement it in your monolith system will be to pass through using a monitoring system, instrumenting your code and in the end, graphing them on a dashboard. A good start will be using the RED method and later extending it with the APDEX score and saturation. Monitoring your resources could be applied according to the USE method.