Microservice monitoring based on five principles

Microservice monitoring based on five principles
GuideOur requirements for microservices can be summarized into one word: speed. This demand for faster provision of fully functional and reliable software completely changes the software development model. There is no doubt that this change has an impact on software management, including the way systems are monitored. In this article, we will focus on the major changes that need to be made to effectively monitor microservices in the product environment. We will formulate 5 guiding principles for this new software architecture to adjust your monitoring methods.

Monitoring is a key part of a microservice control system. The more complex your software is, the more difficult it is to understand its performance and troubleshooting. In view of the huge changes in Software Delivery, the monitoring system also needs to be thoroughly transformed to achieve better performance in a microservice environment. The following describes the five principles for monitoring microservices:

1. Monitor containers and their contents.
2. Monitor service performance, rather than container performance.
3. Monitor elastic and multi-site deployment services.
4. Monitoring API.
5. Map your monitoring data to your organizational structure.

With these five principles, you can establish more effective monitoring of microservices on the way forward to microservices. These principles allow you to cope with technological changes and organizational changes that come with microservices.

Microservice monitoring principlesMonitoring containers and their contents

Containers are important for building microservices. The speed, portability, and isolation of containers make it easy for developers to fall in love with microservices models. The benefits of containers have already been described in detail.

Containers are like black boxes for peripheral systems. This is of great benefit to the development. From the development environment to the production environment, and even from the developer's notebook to the cloud, they bring a high degree of portability. But when it comes to monitoring and solving service problems, this black box makes the conventional method hard to work. We will think: what is running in the container? What is the running performance of programs and codes? Does it have any important output indicators? From the perspective of DevOps, you need to have a deeper understanding of the container instead of simply knowing the existence of some containers.

A typical measure in a non-container environment is to allow a proxy to run in the user space on the host or virtual machine, but this does not apply to containers. Because the advantage of containers is small, various processes are separated and dependencies are minimized.

Moreover, in terms of scale, thousands of monitoring agents are a nightmare of expensive resource waste and management for a medium-size deployment. There are two potential solutions for containers: 1) require your developers to directly monitor their code, or 2) A common kernel-level detection method is used to view all applications and container activities on the host. We will not explain it in detail here, but each method has its advantages and disadvantages.

Use the Business Process System to remind the service performance

It is not easy to understand the running data in container containers. A single container is much less complex to measure than a container that makes up a function or service.

This is especially suitable for application-level information, such as which request has the shortest response time or which URLs encounter the most errors, but it also applies to architecture-level monitoring, for example, the number of resources allocated in advance is exceeded for a service container.

More and more software deployment requires oneOrchestration SystemOrchestration systemTo convert the logical Planning of an application to a physical container. Common orchestration systems include Kubernetes, Mesosphere DC/OS, and Docker Swarm. A team can use an orchestration System (1) to define microservices (2) to understand the current status of each deployed service. You can think that an orchestration system is even more important than a container. Containers are short-lived and can only meet your service needs.

The DevOps team should focus on operational features to stay as close as possible to the monitoring service experience. If the application is affected, these alarms are the first line of defense to evaluate the situation. However, it is not easy to obtain these alarms unless your monitoring system is based on containers.

Native containerContainer-nativeSolution ExploitationOrchestration metadataOrchestration metadataDynamically aggregates container and application data, and calculates monitoring Metrics Based on each service. Based on your orchestration tools, you may want to perform in-depth detection at different levels. For example, in Kubernetes, you usually have Namespace, ReplicaSet, Pod, and some other containers. Aggregating these different layers is necessary to eliminate logical faults and is irrelevant to the physical deployment of the containers that constitute the service.

MonitoringElasticityService

Elastic service is not a new concept, but it changes much faster in the native container environment than in the virtual environment. Rapid changes will seriously affect the normal operation of the detection system.

Monitoring of traditional systems often requires manual adjustment of inspection indicators based on software deployment. This adjustment can be specific, such as defining a single indicator to be captured, or configuring the data to be collected based on the application's operations in a specific container. We can accept small-scale containers (for example, dozens of containers), but it is hard to afford them on a large scale. The centralized monitoring of microservices must be able to grow and decrease freely with the elastic service, without manual intervention.

For example, if the DevOps team has to manually define which service the container contains to be monitored, they will undoubtedly miss because Kubernetes or Mesos regularly create new containers on a daily basis. Similarly, if the code is released and placed in the production environment, the O & M team is required to installCustom status endpointsCustom stats endpointIt also brings more challenges for developers to obtain basic images from the Docker repository.

In a production environment, establish monitoring for complex deployment across multiple data centers or clouds. For example, if your service spans private data centers and AWS, amazon's AWS CloudWatch is hard to achieve this. This requires us to establish a monitoring system across different regions and run it in a dynamic native container environment.

Monitoring API

In a microservice environment, APIs are generic. Essentially, they are the only component that exposes services to other teams. In fact, the API response and consistency can be viewed as an "Internal SLA", even if a formal SLA (Service Level Agreement) has not yet been defined ).

Therefore, API monitoring is also necessary. API monitoring can have different forms, but obviously it is definitely not a simple binary upper/lower check. For example, you can understand the most commonly used time functions.EndpointEndpointIs valuable. This allows the team to see changes in service usage, whether due to design changes or user changes.

You can also record the slowest endpoint of the service, which may reveal major problems, or at least point to areas that need optimization in the system.

Finally, the ability to track system service response is another important capability. It is mainly used by developers and helps you understand the overall user experience, at the same time, the information is divided into two parts based on the underlying and application perspectives.

Map your monitoring to your organizational structure

This article focuses on microservices and monitoring. Like other technical articles, this is because many people are concerned about this layer.

For those familiarConway's LawConway's lawThe system is designed based on the development team's organizational structure. The creation of faster and more agile software forces the team to think about re-adjusting their development organization and managing its rules.

So if they want to benefit from this new software architecture (microservices), their team must map microservices to the team itself. That is to say, they need a smaller and more loosely coupled team and can choose their own direction as long as they can meet the entire demand. In each team, you have more control over the use of development languages, bug submission, and even job responsibilities.

The DevOps team can enable a monitoring platform for this: Each microservice team can have its own alerts, metrics, and control panel, as well as a view of the overall system.

Summary

It is quick to make microservices popular. Development organizations want to provide customers with more features faster, and then microservice technology will come. The architecture will turn to microservices and the popularity of containers will make quick development possible, all the related processes took the train of course.

Finally, the basic monitoring principles need to adapt to the technologies and structures that come with microservices. The sooner the development team recognizes this change, the easier it is to adapt to the new architecture of microservices.

From: https://linux.cn/article-8034-1.html

Address: http://www.linuxprobe.com/5-principles-monitoring.html