As is the case with many new technologies, “observability” can take on different meanings depending on who you’re talking to. In conversations with customers, analysts, and reading what’s online, we’ve seen and heard a few definitions.
Despite the variability in definitions, the general consensus is that observability’s goal is to provide better insight into the application – which is increasingly important as applications become more distributed, unpredictable, and ephemeral. One aspect of observability that has become mainstream is the idea that there are three “pillars”:
- Logging – A record of events to help understand what changed in the system/application behavior when things went wrong. For example, using Grafana Loki to log certain events.
- Metrics – A value pertaining to your system/application at a point in time. For example, using Grafana to understand resource utilization, or app performance metrics like throughput and response-time.
- Tracing – A representation of a single user’s journey through an application transaction. For example, using Jaeger to understand the call flows between services or how much time it takes a user to finish a transaction.
And, as service meshes are increasingly being leveraged in the development of microservice applications, it plays an important role in exposing even more information about the application. Per Red Hat’s definition, a service mesh is a dedicated infrastructure layer that provides a way to control how different parts of an application share data with each other. This layer can document the quality of application interactions and how well all the moving parts work together, making it easier to optimize communication and avoid downtime as an app grows.
With the help of these four concepts and technologies, developers can gain deeper visibility into the behaviors of their applications. Unfortunately, this still requires multiple tools, dashboards, and viewpoints – there’s no element that ties everything together. This becomes even more challenging to solve when you consider the complexity of modern applications – there are more components to manage, and they experience ever-changing demand. A performance issue can arise within the service itself (which is what logging, metrics, and tracing can help discover), but a problem can also arise from the underlying stack of each of these services. When a performance problem occurs, the question arises: is it the code, or the node? To answer this question, you need a 4th pillar of observability – context.
With Lemur, we’ve created a free software tool that takes a top-down, full-stack approach to managing performance. Lemur packages up open source observability tools and provides their insights in the context of our “supply chain” (on the left in the screenshot below).
By bringing these tools together in a singular view, developers can quickly determine exactly what is causing a performance issue and better understand their microservice applications.
Observability is more than a buzzword – it’s going to be a critical practice as containers and microservices increase in adoption, and application complexity grows. If you’re interested in learning more about Lemur, check out this on-demand webinar. Or, click here to get started today – it's free forever and available to anyone.