Today’s software is built over distributed systems. When microservices, load-balancers, serverless compute, flexible infrastructure, and containers interact, it can be hard to track how the system is behaving, and how errors are manifesting. There are many more potential combinations of things going wrong, and sometimes they sympathetically reinforce each other. This can lead to new types of challenges.
The goal of observability is to empower your team to be able to:
You can accomplish that by improving your system’s observability.
Observability is about being able to ask arbitrary questions about your environment without having to know ahead of time what you wanted to ask.
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. We say that a system is “observable” to the extent that you can explain what is happening on the inside just from observing it on the outside, preferably without having to add new, special-case instrumentation to get your new question answered.
Monitoring for known problems doesn’t address the growing number of new issues that arise. You need to be able to ask questions you had not anticipated.
Honeycomb is designed to help you you gather as much context as you can from your production systems so you can investigate and debug new and complex problems. Having an observable system means that everyone on your team has the ability to understand what’s happening in your software.
Improving software observability requires two things: the ability to capture telemetry data with a lot of runtime context, and the ability to query that data iteratively in order to find new insights.
Wide, structured events are the form of telemetry data that truly enables observability in software. Honeycomb works by ingesting your structured events and making them available to interact with in near-real time.
You send Honeycomb large numbers of events. Honeycomb allows you explore your data by querying on any dimension, aggregating your events to compute a count or a P95 (95th percentile), or visualize them as a heatmap. You can group and filter them on any dimension. This ability allows you to track down the behavior of a single user, code release, feature flag, server, or endpoint. You can pivot from any of those views to distributed traces, allowing you to follow the path of execution through your distributed system. Read more about how you can query your data in Honeycomb.
To get the most out of Honeycomb’s features, get started by instrumenting your code.
Ready to try it out? Start sending data to Honeycomb.
If you’re new to this topic and want a deeper introduction, download our whitepapers:
