sources of metrics

Welcome back to my series about metrics for optimization. In the last blog, I discussed the meaning of optimization, determining what you are trying to optimize, and learning how to discover if your enterprise’s optimization goal is a business or technology goal. If you did not get the chance to read my last blog, I suggest you do so as you need to understand what optimization is to progress to our next topic, which is the sources of metrics you should use.

Now, we will look into how you can collect metrics or get information from the technology side to derive and drive your optimization process. 

Application Performance Monitoring (APM) Metrics

Typically if you ask an engineer how their application is performing, they will almost always by default, look at the application performance monitor (APM) space. This is often based on tools that can delve deeply into how an application operates and performs based on internal parameters and metrics.

If you have one big monolithic application that would run everything and you would then need to monitor all the different internal components of that engine. Luckily, several companies came to the forefront to support gathering those metrics. This was a fantastic innovation because now a tool exists that lets you learn all kinds of insights about your application and how it is performing, but you still need to take information and correlate it to your source of optimization.

What has been really helpful today is that most APM systems have a way of exporting metrics to collect the information not just as an end result of an application environment but as a constant update to the system. You can see, given a certain load coming into the environment, how your application is performing. Also, the APM space has expanded with the concept of microservices or multicomponent services. I believe multicomponent services are a little more common than most actual microservice environments, but whatever “scale” of service disaggregation you may have applied to your application, the APM services let you get the same level of detail about how your application performs internally. A classic example of this is using APM across a business logic service and a database to understand how each component affects the performance of the other. 

Often, I can collect database metrics separate from application core logic metrics and front-end web service metrics to leverage in my application performance analysis. 

Request Error Duration (RED) metrics 

APM is one approach to collecting metrics. The other thing we are starting to see more correlated use of is request error duration (RED) metrics.  

These metrics were originally derived from network components and services such as firewalls and load balancers. The interesting thing about these metrics is that they often are effectively a black box to the application. With RED metrics, the application is being monitored externally. We are looking at how long a specific transaction takes to run through a component or the latency response to a request that actually shows up at the front of a system. We don’t know what is happening inside the box of the application. So, for example, you don’t know the queue depth for an internal resource or how long it is taking to process a single queue’d element, but you can see that when a request shows up and the latency of those individual requests. 

One thing that is interesting about the RED metrics is that they tend to have consistency in meaning because we are looking at the same class of information going into and out of any application component. We are looking at specifically the number of requests, request latency, request duration, errors that are coming back, goodput versus bad put sort of interactions. 

Now that you know the different sources of metrics we encounter with optimization. Tune in to our next blog to find out which one you should pick and why.