Observability Engineering, 2nd Edition

Chapter 5. Structured Events Are the Building Blocks of Observability

In Part I, we introduced differences between the three pillars and unified models of observability. In this chapter, we show how that unification happens by unraveling the myth that the standard observability telemetry signals—logs, metrics, and traces—must inherently be managed as different datatypes.

For years, we software engineers have been taught to squint at our systems through different keyholes: metrics for a pulse check, logs for the narrative, and traces for extended views of complex actions. Each of these views has its own tooling, with its own conventions and dogma, that treats each as fundamentally different kinds of data, collected and stored in separate silos. But the problem that separation creates isn’t just philosophical. The shape of the data you collect constrains the questions you can ask later. When you pre-decide the shape, you pre-decide the investigation.

That siloed split that impedes your debugging abilities, however, is merely a historical artifact. Unfortunately, many of us software engineers haven’t fully realized that because squinting through different keyholes is the only method we’ve known since we first started coding. Instead of collecting three different representations of the same system state, we can primarily capture one context-rich representation (the wide, structured event) and use that to generate the appropriate view we need (metric, log, or trace), on demand, from ...