After years of helping developers monitor and debug their production systems, we couldn’t help but notice a pattern across many of them: they roughly know that metrics and traces should help them get the answers they need, but they are unfamiliar with how metrics and traces work, and how they fit into the bigger observability world. This post is an introduction to how we see observability in practice, and a loose roadmap for exploring observability concepts in the posts to come.

Credit: Unsplash What is monitoring? What is observability? Monitoring shows you how a Kubernetes environment and all of its layers are operating. Observability, on the other hand, is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.

Observability vs monitoring, what is the difference? Monitoring is the what to observability’s why. Here we dig into the differences.

Two popular deployment architectures exist in software: the out-of-favor monolithic architecture and the newly popular microservices architecture. Monolithic architectures were quite popular in the past, with almost all companies adopting them. As time went on, the drawbacks of these systems drove companies to rework entire systems to use microservices instead.

Monitoring cloud-native systems is hard. You’ve got highly distributed apps spanning tens and hundreds of nodes, services and instances. You’ve got additional layers and dimensions—not just bare metal and OS, but also node, pod, namespace, deployment version, Kubernetes’ control plane and more. To make things more interesting, any typical system these days uses many third-party frameworks, whether open source or cloud services.

Software development firms need to develop and deploy software solutions and changes quickly, safely, and as demanded by the client. DevOps can help! There’s a major subset of DevOps you can’t overlook: observability.

The best way to be sure that you keep a secret is not to know it in the first place. Managing secrets is a notoriously difficult engineering problem. Across our industry, secrets are stored in a bewildering variety of secure (and sometimes notoriously insecure) systems of varying complexity. Engineers are often trying to balance the least worst set of tradeoffs. At Honeycomb, we asked: What if we didn’t need to know your secrets to begin with?