Service visibility and observability

It can be seen that observability is the first step of the service governance feedback mechanism , Only get enough valuable data , To analyze and control the running state of the service .

One 、 Service visibility

The service metadata platform is responsible for maintaining service related metadata information , It mainly includes the service level 、 Interface level 、 The metadata information of these dimensions at the topology level , Through the service metadata platform , It can provide full visibility to the system . To enhance the flexibility of service query , It can support multiple service query methods , For example, query according to the service department 、 Query according to service attributes, etc , Service basic information platformization, etc . The basic information of the service is as follows .

1） The service description ： Briefly describe the basic capabilities of service provision , Applicable scenarios of services, etc , For potential service users , If necessary, a detailed description of the service can be added wiki, And the corresponding email group and communication group of the service .

2） Service ownership ： Service current department 、 Serving the current owner etc. .

3） Service external interface ： Service interface definition , Instructions for use and precautions, etc .

4） service SLA： External service SLA promise .

5） Upstream and downstream topologies of services ： The upstream and downstream dependencies of each service are maintained in the service mall , Based on upstream and downstream dependencies , You can not only query the usage mode and usage of upstream and downstream services , At the same time, the upstream and downstream service notifications can also be made in case of major service changes .

6） Service change ： The Service Mall maintains a change log for each important change in the service , In case of important changes, upstream and downstream dependencies will be notified through corresponding mechanisms , The upstream and downstream will assess whether adaptation and upgrading are required , In this way, service users can understand the whole development context of the service from the change history .7） Service access and resource quota management ： How to access the service , How to apply for resource quotas .

8） Service online deployment and offline test environment information ： Describes the online and offline deployment information of the service , Users directly use... Based on the environment given by the platform .

Two 、 Change visibility

Change is the main factor causing system failure , Systematically sort out and record the changes of each dimension , It is not only convenient to trace and locate the fault , It can also be based on a complete change event library , Reasons for these changes 、 Comprehensive audit and analysis of quality and impact , Find something regular from it , Establish corresponding improved feedback closed loop .

Service change is the most important source of change , Common service change methods include application change 、 Configuration change 、 Data change and plan change, etc . For microservice architecture , In addition to focusing on changes to the current service , We also need to pay attention to the changes of upstream and downstream dependent services , And the change of deployment level associated services , For example, other service changes on the same physical machine as the current service mix .

In addition to service changes , It is also necessary to record all environmental changes around the service , For example, network changes 、 Machine changes 、 Machine room change 、 Switch change , These changes may affect the normal operation of the service .

3、 ... and 、 Observation visibility

Microservices architecture , Each micro service adopts distributed deployment , And distributed communication through the network , With the expansion of the number of microservices and the scale of clusters , Various types of faults will occur in the system , And many faults can not be predicted in advance . Therefore, microservice observation visibility is required , It can be divided into Logging（ Log system ）、Metrics（ Measurement system ） and Tracing（ Distributed tracking system ）3 A hierarchical .

• Logging system log

Used to record discrete events in the system , For example, service debugging information and error information , Logs are the cornerstone of system monitoring , It is also the first starting point for service status monitoring and problem diagnosis , The log can be used to roughly judge whether the system is running normally . Logs are the most common 、 The most common monitoring means , However, log monitoring and alarms of services generally need to be added manually , Not only is it inefficient , It's easy to miss . At the same time, the log format and log information of different services may be different , It is not convenient to standardize , Not only log collection 、 It is troublesome to handle and display , There are too many personalized needs , And the logs of each service are not uniform , The whole system problem location based on log is also very troublesome .

• Metric System

To improve the standardization of logging and monitoring , Introduced Metric The concept of ,Metric This is to process the aggregatable parts of the log through standardized protocols ,Metric Define a complete set of log collection 、 Transmission and processing standards , adopt Metric It can realize the standardization of logging and monitoring , At the same time, it is based on Metric Log aggregation feature of , The aggregated logs will be much smaller , Reduce the cost of the logging system .

• Tracing System

Tracing Used to record request level information , It will track the execution process of the entire link and the time-consuming information of each stage , be based on Tracing, You can locate request performance issues and cross service interaction related issues .