Observability: logs, metrics and traces
What observability means and how its three signals work together: logs for detail, metrics for trends and alerts, distributed traces for following a request across services, OpenTelemetry for collecting all three, correlation between them, SLIs and SLOs, and designing systems you can debug in production.
CodexBash, , 6 min read
A single application on one server is fairly easy to debug: read its log, reproduce the problem, attach a debugger. A system of a dozen services, queues and databases is different. A request is slow, but which of the eight services it touched made it slow? Errors rose at 14:05, but why? Observability is the ability to answer such questions about a running system, including questions you did not anticipate, from the data it emits. In practice it rests on three kinds of data, often called the three pillars: logs, metrics and traces. This article explains what each is good at, how they fit together, and how to design for them.
Sign in to read the rest
The whole 6 minute article is free with an account, along with every problem, lesson and tutorial. No card.