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

This article mainly explains "how to use Prometheus to monitor applications in Kubernetes". The explanation in this article is simple and clear, easy to learn and understand. Please follow the ideas of Xiaobian slowly and deeply to study and learn "how to use Prometheus to monitor applications in Kubernetes" together!

What is Prometheus Surveillance?

There has been a lot of news lately about Prometheus, especially in monitoring applications in Kubernetes. Before we dive into the RED approach, let's take a look at some background. Applications run on containers and are scheduled by Kubernetes, where they are highly automated and dynamic. Traditional monitoring tools are usually server-based and only monitor static services, so when monitoring applications in this dynamic environment, traditional monitoring tools often have difficulty meeting this requirement.

Prometheus was needed.

Prometheus is an open source project originally developed by SoundCloud engineers. It is specifically designed to monitor microservices running in containers. At each time interval, data flows out of the running service and is stored in a time-series database that can then be queried via the PromQL language. In addition, because the data is stored in time series, when problems occur, diagnosis can be made based on these time intervals, and long-term monitoring trends of infrastructure can be predicted-these are two of Prometheus 'main functions.

At Weaveworks, we built services on top of Prometheus 'open source distribution and created a scalable, multitenant version as part of our software-as-a-service concept called Weave Cloud.

Now that the service has been running for a few months and monitoring itself using Weave Cloud, we've gained some experience monitoring cloud native apps and designed a system based on that experience to determine what needs to be measured before detecting code.

What should I test?

When setting up Prometheus monitoring, it is important to identify the types of metrics that need to be collected, which are relevant to the application. The selected metrics simplify troubleshooting when failures occur and also maintain high stability in services and infrastructure. To help understand the importance of instruments, we define a system called the RED method.

The RED approach follows the principles mentioned in Four Golden Signals and focuses on detecting what end users care about when using web services.

In the RED approach, we manage each microservice in the architecture by monitoring three key metrics:

Request Rate -Number of requests per second served by your service

Errors -Number of failed requests per second

(Request) Duration -The time spent per request, expressed in time intervals

RED method hopes to cover the most typical Web service problems by three indicators: Rate, Errors and Duration. These metrics can also reflect the error rate of requests. These three metrics allow us to detect issues that typically impact the customer experience.

If you want to get more detailed information, you also need to use the Saturation indicator. The Saturation metric is used in the USE (Utilization Saturation and Errors) method and refers to a resource with extra jobs that cannot be serviced and must therefore be added to the queue for subsequent processing.

USE vs. RED method

Compared to the two methods, USE method focuses more on monitoring performance and uses this as a starting point to find root causes of performance problems and bottlenecks in other systems.

Ideally, we could use both USE and RED methods when monitoring applications.

Why measure the same metrics for every service

From a monitoring perspective, if you can handle each service, your operations team can continue to expand on that basis.

What does scalability mean for operations teams? We look at it from this perspective, how many services can a team support. Ideally, the number of services a team can support is independent of team size and depends on other factors, such as the type of response to SLA agreements and whether 24/7 coverage is required.

How do you decouple the number of services you can support from the size of your team? The idea is to make every service the same. This reduces both the amount of training the team has to do for a particular service and the amount of content callers need to document when special service-specific situations occur, such as high-pressure incident response scenarios or so-called "cognitive loads."

Capacity planning: Consider QPS (queries per second) and latency

Automate tasks and sound alerts: The advantage of RED is that it helps you think about how information is displayed in dashboards. With these three indicators, you can tweak the layout of your dashboard to make it easier to read and alert when problems occur. For example, a layout might mean that each service has a different Weave Cloud notepad that contains requests & errors for PromQL queries, as well as delays for each service.

There is no doubt that it is easier to automate repetitive tasks if all services are treated as the same.

PromQL queries

Monitor metrics in RED methods on Weave Cloud

limitations

In fact, this approach (RED) works only for request-driven services--for example, it causes errors when processing batch-oriented or streaming services. It's also not perfect for request-driven applications, and the USE method works better when there's something else to monitor--such as host CPU& memory or cache resources.

Thank you for reading, the above is "how to use Prometheus to monitor applications in Kubernetes" content, after learning this article, I believe you have a deeper understanding of how to use Prometheus to monitor applications in Kubernetes, and the specific use needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

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.