Shulou(Shulou.com)05/31 Report--

This article introduces to you whether there is any way to do API monitoring, the content is very detailed, interested friends can use for reference, I hope it can be helpful to you.

Preface

For the management of API, it is very important to do API monitoring. Some time ago, I read a book about API traffic management released by the Nginx community. I feel that the content in the book is not bad. Combined with my experience in practical application, I will sort out some methods of API monitoring today.

After reading the original documents, I feel that these foreign technical people are still very organized before doing things, and recently they are also reading a book on community management, in which they divide the level of community research into three layers: Frameworks, Theories, and Models. The following is a brief explanation. I feel that this methodology is very practical and I feel it can be used in many places.

The framework is about the general direction and clarifying the relationship between the various parts, so that we can reach a consensus under this framework.

Theory is a more explicit concept than framework. It is a further refinement of each module or sub-module under the framework, or a technical or principled explanation and guidance for dealing with specific things.

The model is more specific, to solve the explanation and guidance of specific events. Researchers use models to test various hypotheses based on theory, and models can be developed using a variety of tools, including mathematics, statistical techniques, and so on.

This is a framework for doing things, and there should be such a model for people who are thinking and dealing with things.

So today, when I sort out the content of API monitoring, I also want to follow such a basic idea.

The basic Framework of API Management

I think there are several aspects in the management of API:

Basic development management of API (API design, interface meta-information, call management, testing, current limiting, routing management, etc.)

Basic monitoring of API (traffic, time consuming, error code, availability monitoring, etc.)

Security control of API (STL, authentication, certificate, etc.)

Advanced features of API (scalability, caching, scaling, performance analysis, traffic amplification analysis, etc.)

From the basic development management of API to the hierarchical management of advanced functions, from basic availability to security and controllability. The basic design of API is also a very complicated matter, and it is not so easy to do a good API design. I'm going to write a series to introduce it later. Today's focus is on the basic monitoring of API.

API monitoring level

API monitoring is also in line with the above theory, there is also a theoretical framework. First of all, the monitoring of API is graded, which is for the implementation of monitoring. Many things will be very clear after layering, no matter in understanding and how to implement them. Let's see how API monitoring is graded.

Infrastructure monitoring

Service level monitoring

Business level monitoring

Infrastructure monitoring

Here we are mainly concerned with the reliability of hardware cpu, disk, memory, etc., as well as the reliability of components such as operating system, queue service, etc. The last article also introduced how to quickly analyze these problems in the positioning system. These are the basis for the stable operation of services, so the monitoring of these facilities is a general practice, which is not only available in API monitoring, but if you want to do complete API monitoring, the last part is of course indispensable.

Service level monitoring

In the service level monitoring, the main concern is whether the service components are healthy and reliable, such as monitoring data reading and writing, file creation, service basic survival, service invocation delay, service performance and so on.

Business level monitoring

Finally, there is business-level monitoring, different application scenarios and businesses, the content of monitoring is also different. For example, you need to monitor the number of purchases, the number of login users, the number of messages sent, the number of gifts received, the route taken, and so on. Different business scenarios need to monitor different indicators, which is very characteristic.

API monitoring common monitoring indicators

Although the third level of monitoring mentioned above has many features, they still have something in common with the content of the monitoring. So here are some commonly used types of monitoring indicators.

Speed

Rate is a commonly used monitoring indicator, data transmission rate, increase rate, access rate, call rate, etc., this indicator is designed to monitor the service capacity of your system. Generally speaking, the larger the index, the stronger the service ability.

Request delay

This indicator is often related to the above speed indicator. Generally speaking, the smaller the value, the better your service performance. This indicator can generally be collected on the API gateway or on the client side.

Error rate

The monitoring of system errors is very important to a system, as well as the statistical count of different error codes. With the monitoring of these indicators, the availability of the system will be monitored.

It is also problematic to simply look at the first two indicators, because sometimes the access rate and request delay of the system will perform very well when the system fails, but there are actually a lot of error requests and error returns. for example, the system's fast error return, a large number of error requests and so on.

Quota sudden overload

This is also a point to be monitored, many times there is instantaneous overload, which also exposes some potential problems in the system.

Average value of index

It is necessary to monitor the stability, service capacity and service characteristics of the system. In many cases, we should not only look at the current state value, but also further look at the average value of the service index in the last 5 minutes, 10 minutes, 15 minutes and so on.

Common Monitoring models of API Monitoring

The above is all laid the groundwork, this part is actually what I want to share today, I think this part of the content is more interesting. I have listed so many index types above, and each type will derive a lot of indicators when they are actually implemented, so the question arises: do we have to look at all the indicators when we analyze system problems? This estimate is very difficult, so how to do it?

Speaking of this question reminds me of a practice in the stock market: the index. It is mentioned here that if you understand the so-called index, you should know what I am going to say. The stock index can use a special algorithm to calculate a value for some delineated stock indicators in the stock market to indicate whether the stock market is good or bad. For example, the United States has the NASDAQ composite index, and China has the Shanghai Composite Index and the Shenzhen Composite Index.

So the so-called monitoring model I introduce here is a similar idea, but this model has been combed out by other companies or organizations, not my original ha.

USE model

Here is an introduction to the first model: USE (Utilization, Saturation, and Errors), which was first proposed by Brendan Gregg and is currently at Netflix, the author of the famous "BPF Performance Tools" book with a tome of more than 1300 pages. He mentioned that he proposed this model so that people can quickly locate and solve the problem without being overwhelmed by the details.

Gregg said that by asking three questions, you should be able to have a very good understanding of your system: how is the utilization? What's the saturation? What is the error or error rate?

Utilization utilization refers to the utilization and availability of systems such as CPU, disk, Imax O, etc.

Saturation saturation is the degree of business or request that the system is waiting to process, indicating whether it exceeds the maximum capacity of the current system.

Errors error or error rate is also easy to understand, which is the error event that occurs when the system is dealing with these business or requests.

A more detailed explanation of the model can be found on his personal website: http://www.brendangregg.com/usemethod.html.

In fact, this is also the case. In my previous translation article, I introduced how to locate the Linux system. In fact, most of the methods are like this.

Maybe you say what does this have to do with API monitoring? Gregg's earliest goal is indeed for system index analysis, but in fact this method model can be applied to system thread analysis, and network request analysis is also possible. But fundamentally, it is still a monitoring model mainly aimed at infrastructure.

RED model

RED (Requests, Errors, and Duration), this model was proposed by Tom Wilkie in 2015, it is an upgrade of the USE model, the USE model will be easier to use in the stand-alone model, but in the current distributed environment, micro-service environment, it is very difficult to quickly locate the problem, so the RED model is more useful in the health assessment of complex systems. We can see that the indicators used are not many. It is also like the soul question above: how many requests do you have in your system? What is the error or error rate? How long will it take?

There is not much explanation for these three indicators here. In fact, people usually use these indicators in their investigation of the API interface, but I guess many people have never thought of using indicators to build a model to reflect the overall stability and reliability of the system. And this model is very good, especially for micro-services.

You can see that this corresponds to the service level monitoring above. The RED model is a way to evaluate the overall availability of the system. Through the complete monitoring of the system request (the whole process from the start of the request to the return), and extract three key indicators to evaluate the availability of the system. The RED model is generally used at the API gateway layer, where services can be monitored.

LETS model

LETS (Latency, Errors, Traffic, and Saturation), the whole model was put forward by Google in 2003. in fact, this model is a model put forward by Google when he proposed their SRE. These four indicators are called "The Four Golden Signals" in the book SRE. The book says that if you can only focus on four indicators, focus on these four: delay, error, traffic and saturation.

"If you can only measure four metrics, focus on these four: Latency, Errors, Traffic, and Saturation."

This model provides an evaluation of the availability of the system with a minimum set of concerns. Through the attention of these four indicators, you will find most of the problems in the system. Unlike USE, which is low-level, it is a monitoring and analysis model for service availability.

Summary

There must be a certain methodology to guide things. The purpose of this article summarized here today is to sort out the monitoring aspects of API, and sort out the basic levels of API monitoring, common indicators and common monitoring models.

For the monitoring model of API, it should also be explained here that different monitoring models focus on different issues, or different levels of monitoring. And in the actual team, this part of the work is generally divided into several organizations to complete. Different teams have different concerns, so you can choose different models for specific concerns.

Another thing to say is that for API monitoring, although the levels, indicators and models mentioned above are summarized by predecessors. However, with the development of the times and the progress of technology, when we use it in the actual scene, we should, on the one hand, choose the appropriate one, and on the other hand, we should also think about whether the optional model is suitable for the current scene. If you do not adapt and there is no better choice, you can abstractly develop a model for your own scene. So that the customized model can accurately reflect the state of their own system.

A picture is worth a thousand words:

There is no way to do API monitoring to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.