Effective Monitoring of Microservices using AGILE principles
By: Aakash Vaswani
Tags: Agile, Monitoring, Microservices

Using and implementing Microservices on a platform that is orchestrated dynamically, the benefits provided by the cloud environment is the driving force. Making scalable applications (public, private and hybrid) is the ultimate aim.

Organizations offer best solutions by creating Cloud-native applications, with infinite computing power and modern application services and data and for developers, to be far ahead of their competitors to meet customer demands.

Major components of a cloud-native application

Companies such as Netflix and AirBnB, provide online services via software primarily developed on the cloud, have been very successful nowadays. The reason behind their unprecedented success is quick delivery of software. This is a result of applied DevOps and microservice principles. As a result, these companies can scale the number of users at a much faster pace and perform market experiments quickly to gain knowledge about their clients functionalities used extensively that need to be scaled in future to meet the future demand.

When it comes to monitoring in microservice environment, it is seen as one of the most crucial aspect of any application. The sole reason behind this is using monitoring techniques, one is able to know or gain insights which part of the entire system needs scaling, or which part needs the traffic to be diverted to some other part and many other advantages. Currently prevailing monitoring techniques include: Raygun APM, Zipkin, Apache Kafka, Zafana, Prometheus, etc. These monitoring techniques have their own set of advantages and drawbacks to which further research is still going on.

Monitoring of Microservices –

Monitoring is the process through which we measure and manage IT applications. But this definition just briefs about monitoring and gives only 1 aspect of it. It is much more than that. Monitoring is the process which acts as the translation between the metrics generated by and business value of your applications. Those metrics are then translated into a measurable way that any user can interpret, which results in a feedback from the user for future deliverables. Monitoring techniques have changed over the years and is still evolving for better.

Traditional monitoring assumes that a service of an application is not short lived. It’ll be there for some time. In this world of containers, virtualization and cloud; application infrastructures are changing faster than one can imagine. Containers are updated way quicker. Hence setting up a monitoring environment is difficult. Organizations in this case need some dynamic mechanism for monitoring with the right amount of abstraction. This is made possible using the existing tools available for monitoring of microservices.

Contrary to the Traditional monitoring methods/tools, present monitoring methods are based on some principles.

Monitor containers and what runs inside them Use Orchestration Systems (Example — Kubernetes, Docker Swarm, etc.) Prepare for elastic, multilocation services . Monitor APIs

Metrics of Monitoring–

Every application has its unique need of monitoring. Hence various categories of monitoring metrics are present. They include:

Application Metrics

Application metrics are specific to an IT application. For example, successful registrations in the app in the last 1 hour. Such data can give insights of the functional behavior of the supplication as a whole.

Platform Metrics

Platform metrics provide the nuts and bolts of your infrastructure. Examples include:

Such metrics are used to understand system behavior and performance, mostly at a lower level. Indication or alerts of a degraded system performance, which can potentially lead to system failure or decrease in overall throughput is given by such metrics. Hence these metrics can avoid big system failures. For example, The Raygun APM platform

System Events

New code deployments in a microservice application and system failures have a strong connection. Hence, maintaining a log file of those deployments in the time-series data along with other metrics is the key to solving the given problem. Different events such as configuration updates, scaling up/down of services, and other operational changes are also recorded in the log file. The log file then can be used to correlate different events.

Existing Techniques/Tools for Monitoring–

The broad categories of existing monitoring tools/techniques falls as: libraries and platforms. There exist a few tools which have both, supporting a library that instruments code and providing a platform that is useful for collection of data.

Libraries — They are used in a system/service during its phase of development. Frameworks and languages, such as Java, Go, .NET, etc.; have resources (libraries) that lets a developer code efficiently. These resources/libraries can be utilized for loging and monitoring purposes. Both, paid and open source libraries are available for use. For example, SPF4J for Java and App Metrics for .NET.

They are used in a system/service during its phase of development. Frameworks and languages, such as Java, Go, .NET, etc.; have resources (libraries) that lets a developer code efficiently. These resources/libraries can be utilized for loging and monitoring purposes. Both, paid and open source libraries are available for use. For example, SPF4J for Java and App Metrics for .NET. Monitoring platforms — Their primary aim is the gathering and analysis of metric data from sources such as, applications, OS (operating system) and network platforms. For example:

— Their primary aim is the gathering and analysis of metric data from sources such as, applications, OS (operating system) and network platforms. For example: Raygun APM : It is a platform is that gives its users instrumentation data and collector processes. This is very helpful because it gives a visual dashboard to easily interpret data metrics. Supports — Ruby, .NET, and Java.

: It is a platform is that gives its users instrumentation data and collector processes. This is very helpful because it gives a visual dashboard to easily interpret data metrics. Supports — Ruby, .NET, and Java. Zipkin : It is an open-source tracing system that lets organizations analyze or get alerts for latency issues. It is also used for tracing calls between various microservices. It has instrumentation libraries and the collector processes that gather and store tracing data.

: It is an open-source tracing system that lets organizations analyze or get alerts for latency issues. It is also used for tracing calls between various microservices. It has instrumentation libraries and the collector processes that gather and store tracing data. Apache Kafka : It is a system that processes streams by using a methodology, similar to a “publish/subscribe”, where a logical stream is maintained, which contains reading and writing data. If used in sync with tools like Zipkin, it can provide a comprehensive solution for metrics data transmission and store.

: It is a system that processes streams by using a methodology, similar to a “publish/subscribe”, where a logical stream is maintained, which contains reading and writing data. If used in sync with tools like Zipkin, it can provide a comprehensive solution for metrics data transmission and store. Prometheus & Grafana: It is an open source project mainly used for systems monitoring and alerting purposes. It is widely used along with Grafana, the visualization dashboard that makes monitoring readable easily. Due to all these advantages that Prometheus and Grafana provide, it is widely popular among the developer circles of the IT community.

Problems associated with existing Monitoring techniques:

Although microservices monitoring forms one of the most important aspect of any software/service development, the tools currently available in the market aren’t completely perfect. Just like no code is ever bug free, no monitoring tool has all the advantages. For instance, one monitoring tool may give the overall performance rating of the system, while it may not give you the individual service calls, which is highly important if the organization is interested in scaling the microservices.

To list a few disadvantages/drawbacks of currently available microservice monitoring tools:

No complete set of monitoring metrics. Any monitoring tool, existing in the industry right now, doesn’t offer monitoring of all metrics in 1 system.

Reduces performance of the entire system. When systems employ more than 1 monitoring tools in conjunction with each other (For example, Prometheus with Grafana), a lot of computational resources are utilized, which leads to reduction in overall system performance.

As the load increases, some tools become slow eventually.

If scaling of the service needs to be done, manual changes of metric thresholds is to be done, which becomes a very tedious task. And when too many metrics need manual configuration of thresholds for alerts, it becomes a tedious task for the team to do it regularly, when scaling is done.

Not supportable for long term usage, because of change in business logic. For instance, a company X changes its business logic, then accordingly metrics need to be updated.

Additional configuration is required using complex query languages for monitoring setup in certain tools. Some tools like Prometheus need understanding of complex query languages to set and receive monitoring alerts.

Expensive. Some tools are freely available over the internet as they are open source projects, while some which provide good performance, like raygun APM are paid.

Too much computation is done in some monitoring environments, which ultimately leads to system performance degradation.

In spite of all these drawbacks that are present in existing tools, companies extensively make use of them. The sole reason behind it is that there is no other alternative available to them. In this article, a solution is presented that tries to tackle some of these issues using the principles of Agile methodology.

Strategies needed for Effective monitoring of microservice applications —

Above given ladder depicts the stages necessary to be implemented in the monitoring environment so that nothing is left unmonitored.

An ideal and effective monitoring techniques should have the following steps in its architecture to provide a comprehensive microservice monitoring experience to the user.

External system scan along with internal service scan.

Centralized logging mechanism.

User to be given an option of metrics that he/she wants to monitor and rest aren’t monitored. Thus hugely saving computation power by not monitoring unnecessary details of the system.

Involving Agile principles by having sprints of monitoring, where monitored data is sent to a centralized cloud server from where it can be retrieved anytime.

Customizable UI as per Users choice.

An alternative monitor, in case existing monitoring tool is too loaded to monitor. In large systems this may happen, as there are millions of records of data to be processed and based on specific prerequisites, alerts are to be given to the user. In such cases alternative monitoring mechanism, may help by distributing the load and there by speeding up the entire process.