Monitoring refer to some graphs, alarms, or stats that have to be read by a human. These alerts can be received through email or SMS, or can also be visual on a browser. After observing these alerts, one is supposed to take action. So, raising an alert is automatic, but to rectify it, you need manual intervention. Somewhat like Nagios to perhaps send an alert if something is not working as expected. This is not the case anymore in a microservice environment. With the growing number of microservices in one system, you need smart monitoring in place. If they identity a failure or malfunction in the system, the monitoring system should be smart enough to take corrective action. If they find a service down when it is supposed to be up, then the monitoring system should try to restart that service. If it fails again and again, then it can analyze the log and find some common issues, such as connection time, out or so on. Take predefined action based on log analysis:
In any distributed microservices architecture, communication will be as shown in the preceding diagram. So, there are many services talking to so many other services. So, there are many challenges to maintain many metrics. Metrics such as request per second, available memory, number of live connections, failed tried authentication or expired tokens, how many dropout on which page, and so on. These parameters are important for understanding the user behavior, application behavior in peak and slow time, and so on. Once monitoring is in place, the operation team will be notified about failure. Finding the exact cause and rectifying it in the preceding distributed environment will take time. Then there comes the reactive monitoring. It is very hard to work with distributed systems without reactive monitoring.
Traditionally, all monitoring tools generally support the needs of the DevOps team. Mostly, they have a weak UI experience, and sometimes these tools have only configuration files. However, in microservices, you're decentralizing the tools and processing out to multiple development teams. The development teams will also include non-operations people such as developers, QA, and product management. With modern UI technologies, it should be really easy for teams that are not in operation, such as developers, to set up and use their own monitoring as a self-service, while still giving the DevOps team an overall picture.
Fast shipping is another good feature in microservices , which adds or removes any feature quickly. Make a parallel release of a new feature and send some traffic on that. Basically, here, we are trying to get user reaction on a new topic. This is what we call A/B testing. After this, the product guys try to improve the application. This will raise the bar for monitoring. Here, we are not trying to find failure in the system; instead, we have a variety of applications and are trying to observe user reaction to a new feature, which, in fact, makes the product guy realize the effectiveness of that new feature.
With big data, data science, and microservices, monitoring microservices runtime stats is required to know not only your application platform, but also your application users. You want to know what your users like and dislike, and how they react. Monitoring is not limited to alerts any more.