Application monitoring is critical to providing users with quality products and experiences. However, collecting a large number of application metrics alone does not solve the real problem. Software companies need a way to gain actionable insights from metrics so that they can quickly fix problems that users are experiencing.
Enter the RED method. Origin of the RED method
The RED method is a monitoring method that Tom Wilkie created based on what he learned while working at Google. RED is derived from some of Google’s established best practices known as “Four Golden Signals” developed by Google’s SRE team.
The main reasons behind RED are previous surveillance philosophies and methodologies, such as: USE method It wasn’t exactly in line with the goals of the software company or the latest software architecture. While USE applies further to hardware and infrastructure, the RED method aims to focus on what the user of the application is actually experiencing.
The goal of the RED method is to ensure that the software application works well for the end user above all else. In today’s world of microservices architecture, containers, and cloud infrastructure, hardware-related metrics are less important as long as service-level goals (SLOs) are met. RED method description
RED represents rate, error, and duration. These represent three key metrics to monitor for each service in the architecture. Rate-The number of requests the service is processing per second.
Error-Number of requests that failed per second.
Duration-The time it takes for each request.
These three metrics give you a solid understanding of service performance. The number of requests provides a baseline of the amount of traffic going to the service. These error part of the request tell you if the service is working within the SLO. Finally, the time it takes each request to be processed by the service provides insight into the overall user experience of the application. Benefits of the RED method
The first advantage of the RED method is that it helps reduce the cognitive load that engineers need to determine why there is a problem with the service. RED abstracts the internal details of each service into something that can be understood throughout the architecture. Not only does this help you resolve issues faster, but it also makes it easier for you to grow your operations team by allowing members to on-call services that you didn’t create yourself. The RED abstraction makes it easy to understand what’s wrong and how to fix it. Even if the service you are trying to fix is a black box that is virtually unknown internally, engineers can examine the telemetry data to determine the best action to improve the user experience. The same metric is used for all services, reducing training time and service-specific knowledge. Another advantage of the RED method is that it more closely matches the overall purpose of the user and the company. Users don’t care about infrastructure. They don’t care about your CPU usage, your memory usage, or other hardware metrics. They care if they […]