Being able to observe how your software performs has always been important for developing software that operates efficiently, but perhaps never more so than now, with the proliferation of microservices and distributed systems.
In the case of a monolithic application running on a single machine, one can more or less get away with using logs alone for troubleshooting. In a distributed architecture, however, the question is not just what went wrong, but where? Which of the 20 microservices along the request path servicing an HTTP request caused the issue? The way to find this answer is to employ more signal types beyond logs: metrics and traces.
Metrics offer aggregate health and performance insights into our application
Traces tell us where issues are occurring
Taken together, logs, metrics, and traces can give us insight into our distributed applications.
While observability can provide insights you might otherwise miss, not all observability is created equal. Open source observability (OSO) tools and specifications can deliver the information you need without the downfalls of more traditional, proprietary tools, such as vendor lock-in and limited access to information.
In this Guide, you will learn:
Why open source observability benefits us all
The importance of open standards
Best practices for overcoming common open source observability challenges
What is open source observability?
The Cloud Native Computing Foundation (CNCF), home of open source projects such as Kubernetes, OpenTelemetry, and Prometheus, among many others, defines observability as:
… the capability to continuously generate and discover actionable insights based on signals from the system under observation. In other words, observability allows users to understand a system’s state from its external output and take (corrective) action.
Based on this definition of observability by the CNCF, we can define open source observability as anything that delivers actionable insights via open source software, and that is based on open standards, such as OpenTelemetry, for collecting signals like logs, metrics, and traces.
While this definition of OSO focuses on open source tooling and standards, I will point out that it is only of secondary relevance if you run the open source software yourself or outsource the operation to a vendor or cloud provider that offers APIs and web-based UIs. In fact, as we’ll discuss later, outsourcing this aspect may even be advisable. Beyond that, I think it’s also important to clarify a key observation, which may not be so obvious if you’re new to the space: Open source is not a business model. Rather, it is a way to collaborate and distribute software. Again, this point will become more important as we go on, because the ways that open source projects choose to collaborate and govern themselves can have downstream effects on you as a user.
First, let’s have a look at where OSO excels. Then we can talk about its limitations and I will share a few insights that I’ve gathered over the past decade working at several open source start-ups, Red Hat, and now at AWS on a service team that offers open source software as a service.
Open source observability is good for all of us
Larger enterprises that have workloads both on-premise and across one or more cloud providers often bet on open source as a strategy to minimize vendor lock-in and to use in negotiations with a vendor. This is certainly the case when it comes to OSO. With an OSO standard and toolset, companies can run the OSO stack themselves, which means they are less dependent on a specific vendor. In addition, the open standard ensures that there will be no need to reinstrument or reconfigure their code if they do need to move vendors. All of this together adds up to a better position for OSO users when negotiating pricing with vendors.
While open source software and standards can offer some universal benefits, not all open source is equal. Let’s have a look at a cloud native open source stack that you might end up choosing, and examine how this is the case:
Linux and Kubernetes as the operating systems.