Observability is a relatively new concept being applied to production software systems. In an attempt to explain what it means and how to achieve it, some have tried to break it into three parts with the “three pillars of observability” — splitting it into metrics, tracing, and logs. But I think that misses a critical point of what it means to observe a system.

Observability measures how well you can understand your system’s internal state based on signals and externally-visible output. The term describes one cohesive capability. The goal of observability is to help you clearly see the state of your entire system.

When you unify these three “pillars” into one cohesive approach, a new ability to understand the full state of your system in several new ways also emerges. That new understanding doesn’t exist within the pillars on their own: it’s the collective sum of the individual parts when you take a unified approach. Simply defining observability by its individual components misses the bigger picture.

Considering Capabilities on Their Own

A good analogy for describing how this system comes together is one of using color-filtering lenses. Color-filtering lenses remove some wavelengths of information in exchange for emphasizing others. When you need to focus on particular shades of red, using a red lens can help and it’s the tool you should reach for. But in order to see the big picture, you need to be able to see all the vivid colors as they come together in real time.

For example, let’s say that you notice that a production service seems to be acting up. Let’s look at how different lenses see that problem.

#monitoring #contributed #sponsored #big data