Software is becoming exponentially more complex.
To successfully deliver and run a product or service under these escalating conditions, you need observability.
Observability is a term from control theory.
“In control theory, observability is a measure of how well internal states of a system can be inferred by knowledge of its external outputs. The observability and controllability of a system are mathematical duals.” - Wikipedia (https://en.wikipedia.org/wiki/Observability)
In the world of software products and services, observability means you can answer any questions about what’s happening on the inside of the system just by observing the outside of the system, without having to ship new code to answer new questions. Observability is what we need our tools to deliver now that system complexity is outpacing our ability to predict what’s going to break.
When environments are as complex as they are today, simply monitoring for known problems doesn’t address the growing number of new issues that arise. These new issues are “unknown unknowns,” meaning that without an observable system, you don’t know what is causing the problem and you don’t have a standard starting point/graph to find out.
Having an observable system means you have the instrumentation you need to understand what’s happening in your software. Observability focuses on the development of the application and the rich instrumentation you need, not to poll and monitor it for thresholds or defined health checks, but to ask any arbitrary question about how the software works.
You can’t predict what information you’re going to need to know to answer a question you also couldn’t predict. Honeycomb is designed to let you gather as much context as you can from your systems so that you can investigate and debug new and complex problems in your infrastructure.
If you’re new to this topic and want a deeper introduction, download the first e-guide in the Honeycomb Observability Series: “Achieving Observability”.