Blog / Observability and monitoring

How to Learn Observability and Monitoring From Books, in Order

July 26, 2026 · 2 min read

Monitoring answers questions you thought to ask in advance. Observability is about whether you can answer questions you did not anticipate, from the telemetry you already emit. That distinction sounds like marketing until the first time a distributed system fails in a way none of your dashboards were built for, and every graph is green while users are timing out.

The reading order matters here because the tooling literature ages fastest. A book about a specific metrics stack is partly obsolete in three years; a book about how to define what "working" means for a service is not. So: definitions and practice first, then tools, then the deeper performance and resilience material.

Define the problem properly

Start with Observability Engineering, which is the clearest statement of the modern position: high-cardinality, high-dimensionality structured events over pre-aggregated metrics, and the ability to slice arbitrarily after the fact. It is written by people with an obvious commercial interest in that position, which is worth holding in mind, but the technical argument stands on its own.

Then Site Reliability Engineering, the Google book. It is the foundational text for the whole discipline — error budgets, toil, on-call design, postmortems without blame, and the original articulation of service level objectives. It is uneven in places and reflects one company's scale, but the parts that generalise generalise very well.

Implementing Service Level Objectives is the necessary follow-up, because the SRE book explains why SLOs matter and this one explains how to actually pick them: choosing indicators, setting targets you can defend, computing error budgets, and handling the organisational conversation when the budget runs out.

Learn a real toolchain

Prometheus: Up and Running is the practical instrumentation book — exporters, PromQL, alerting rules, and the pull model's implications. Prometheus remains the default open-source metrics stack, so this is worth doing hands-on even if you use a commercial vendor.

The Art of Monitoring covers a broader stack and is the most dated title on this path; its tooling chapters reflect an earlier generation of the ecosystem. If you have already worked through the Prometheus book, read it selectively for the framing on monitoring as a design activity and skip the tool walkthroughs.

Go deeper on performance and failure

Systems Performance is the heavyweight. Brendan Gregg's methodologies — USE, workload characterisation, the tracing tools — are what you reach for when the dashboards say the service is fine and it is not. This is the book that connects observability to what the kernel, the disk, and the scheduler are actually doing, and it repays years of returning to it.

Database Reliability Engineering extends the same operational thinking to the stateful layer, which is where most serious incidents ultimately originate: capacity, replication, backups that have actually been tested, and schema changes that do not lock the world. Close with Learning Chaos Engineering, a short introduction to deliberately injecting failure — which only makes sense once your observability is good enough to see what the injected failure does, hence its position at the end.

If your interest is more front-of-stack, the web performance optimization hub picks up the browser-side story. Follow the full path to read these in sequence.

Follow the full ordered path here: How to Learn Observability and Monitoring From Books, in Order.

FAQ

Is observability just a rebrand of monitoring?
Partly, and the marketing has muddied it. The substantive difference is cardinality and question-asking: monitoring checks predefined conditions, observability aims to let you interrogate arbitrary dimensions after the fact. Observability Engineering makes the case; the SRE book shows that much of the practice predates the term.
Do I need SLOs at a small company?
You need the reasoning, not necessarily the ceremony. Implementing Service Level Objectives is useful even for a two-person team because it forces the question of what level of failure is actually acceptable, which is worth answering before an incident rather than during one.

Follow the full reading path

Ready to learn something deeply?

Build a reading path — free

Keep reading

Explore related subjects