Observability Engineering

by Charity Majors

Observability is critical for engineering, managing, and improving complex business-critical systems. Through this process, any software engineering team can gain a deeper understanding of system performance, so you can perform ongoing maintenance and ship the features your customers need. This practical book explains the value of observable systems and shows you how to build an observability-driven development practice.

Authors Charity Majors, Liz Fong-Jones, and George Miranda from Honeycomb explain what constitutes good observability, show you how to make improvements from what you're doing today, and provide practical dos and don'ts for migrating from legacy tooling, such as metrics monitoring and log management. You'll also learn the impact observability has on organization culture.

You'll explore:

The value of practicing observability when delivering and managing complex cloud native applications and systems
The impact observability has across the entire software engineering cycle
Software ownership: how different functional teams help achieve system SLOs
How software developers contribute to customer experience and business impact
How to produce quality code for context-aware system debugging and maintenance
How data-rich analytics can help you find answers quickly when maintaining site reliability

Genres: Technology, Software, Programming, Technical, Computer Science, Nonfiction, Engineering

ebook

Reviews

[Federico · Rating 2 out of 5]

As someone has already written, this book is a lot about observability and not enough about engineering.

While I genuinely appreciate and respect the authors, I found the book poorly balanced, and not very practical.
Too many chapters insist on the difference between monitoring and observability while remaining too vague to appreciate such difference.
Some chapters show code which I found too detailed to be useful. In other chapters, I expected to see some code but there wasn't.
Observability is advertised as something that makes a dev look like a "freaking wizard", but the book doesn't prove it. An example payload of an observability event could have helped.

My judgement could well be biased by my initial knowledge of the subject: I started this book knowing nothing about observability.

I would now like to read either a more balanced and practical version of this book, or a new book entirely, titled something like "Observability in practice" or "From zero to observability"

[Avraam Mavridis · Rating 4 out of 5]

Great content but a bit repetitive specially in the beginning

[Ibrahim · Rating 3 out of 5]

At the beginning, the book emphasized the difference between observability and monitoring but it comes to what should be to invest most of the book of how to apply it practically, it fades.

I only recommend the first few chapters and if you are interesting in know the technical storage requirements then the fourth part is good

[Mark Torres · Rating 4 out of 5]

Solid book, definitely a must-read for anyone who's interested in all things observability. The authors are clearly knowledgeable not only about observability, but also about how messy typical production systems are and why observability is commonly a "that would be nice to have" concept for most orgs that at best have some sort of ad-hoc telemetry set up. There were plenty of instances of the authors pointing out bad debugging behaviors, such as the arbitrary print statements or the quickly outdated runbooks or the "tribal knowledge" of intuition miraculously passed down from senior to junior developers, all practices normalized in my own tech experiences and that I've found myself to commonly do. It's opened my eyes to ways that I can be more proactive about designing observable systems and the long-term benefits of developing software within observable systems. Even as someone who's not an SRE, I've come away with some best practices to implement in my own pipelines.

[Leo · Rating 3 out of 5]

This might be an ok-ish intro to observability, but, in my opinion, it lacked content, and tried covering too much at once. First several chapters are quite repetitive, and mostly trying to persuade developer that one really needs observability. I already believed that (otherwise I probably won't be reading the book), but I wanted to know more on how to improve current system (or build a new one) by adding observability to it. And that's what I was missing. From technical standpoint, it reads like all observability is is tracing, and system to query results of tracing, and I feel like it's a much broader topic. And just after talking about technical stuff for a bit, when I thought "now that becomes interesting, tell me everything" - book switched to cultural aspects and other topics. These discussions were interesting, but anyways - not quite what I was looking for.
List of further recommended reading is really good, imho - I was planning to read "SRE book" anyways, and recommending it bumped it up in my list even higher.

[Isidro López · Rating 2 out of 5]

No matter how much I usually enjoy reading Charity Majors thoughts and posts (it's the only author among the three that I follow, sorry), I confess that this book didn't reach my expectations :-/

I can only agree with some other reviews I just read: from my point of view, it's missing a lot of practicality, a lot of practical content. I would have preferred having several detailed and real-world examples about how to apply and get the value of observability (e.g. with code, screenshots, private videos, I don't know) rather than several chapters with information for building your own o11y platform.

I absolutely recommend following everything shared by Charity Majors, it's pure gold. But this book... I think it highly depends on your needs and expectations :-/

[Kiryll Kadyrka · Rating 4 out of 5]

Although repetitive, probably the best starting point on observability. Some parts are bloated, but the general idea is relayed perfectly.

[Jonathan Price · Rating 3 out of 5]

The core message is a good one, but this book just isn't dense enough. I think the authors went to great pains to limit how much of this was a pitch for Honeycomb, but that just ended up with a bunch of chapters with not much meat on them. More examples, even with Honeycomb, would have been useful, or just less chapters and filler.

Skip to chapter 5 and skim liberally and this is a useful book to read, but it really could have been a ~30 page white paper as written.

[Hanson Ho · Rating 4 out of 5]

Excellent primer on the emerging space of Observability, providing the technical basis for investigating unknown-unknowns in complex modern software systems. It gives a good overview of the field, how it differs from the well understood technologies used to keep an eye on and debugging production issues (e.g. metrics, logging, and monitoring). If you want to grok what the big deal is, this is a great place to start.

[Sven · Rating 2 out of 5]

Shallow and repetitive.

The main message is:
- use traces with a lot of high cardinality dimensions
- have good exploration tooling to slice and dice it
- focus on end user experience

Useful as a quick introduction, but not something I'll re-read in a few years I think.

[Matt · Rating 3 out of 5]

The book puts across a critical point that rather few in the industry take seriously: that we can't have working systems unless we look at systems as a whole, including the people building and operating them (ie. socio-technical systems). In that context, the idea of observability that the authors put across is a similar tectonic shift as we saw with the adoption of distribution version control systems or unit testing. Just this is worth getting the book.

However, After the first handful of chapters, where this point is made and explained, the authors unfortunately re-heat the same topic again and again. Perhaps I wasn't the target audience for this book, because I got the point the first time around, so the later chapters felt repetitive and lacking the zest of the beginning ones.

[Gustavo Leiva · Rating 5 out of 5]

Given there is a lot of buzz about observability, i was looking for more detailed information about it and how it is different from traditional monitoring practices. I think the book does a good job explaining the concept and the foundations. The level of detail felt good enough for me. There are 2 chapters on how to implement your own observability solution that seemed a little rushed but they were interesting to read anyway.
It was also good to read the chapters dedicated to the socio/cultural changes in the org to adopt observability, as well as the maturity models to assess where every org is at.

[Mikhail Filatov · Rating 2 out of 5]

The authors are obsessed with proving that Observability is not Monitoring. They dedicate like half a book to discussing it.
They provide very generic definition of Observability, but after reading a few chapters with real content (8-12) all the fuss is about events with not fixed schema and distributed tracing+ telemetry storage and processing for distributed applications.
Useful stuff? Yes, absolutely. For an article 1/8 of the book size.
It is also funny that while selling Observability they claim that micro services based apps are full of weird, not repeating errors with no intuitive way to understand. Nice ad for micro services 😃

[Yannick Grenzinger · Rating 2 out of 5]

If the book didn't had "engineering" in the title, I would have given a 3 star rating.

1/3 of the book is a very long intro about how observability is different from monitiring and why it's needed. 1/3 is more about organizational concerns and how to apply it.

I didn't fully read it because I was missing the most important part for me : How to put into practice observability ? What type of infra do you need ? Which data do you send to this "observability" system ?

This is an interesting book for directors and managers and could be great if more straight to the point but it's not so much for engineers.

[Blake · Rating 2 out of 5]

I was disappointed with this book. While it gave a concrete definition to observability versus monitoring, I feel like that’s mostly what I walk away from this book with. It seems very repetitive with some extra fluff just to reiterate the same thing throughout most of the book. At one point, the book does go over (in a very high level) how to develop your own observability framework, but it was such high level, it felt pointless. I come to books for more in-depth topics, but this book just overall seemed to be high level generic topics around observability which made it very boring to read. I was definitely expecting more substance from this book.

[Michael Haupt · Rating 2 out of 5]

Sadly, the book oscillates between overly repetitive and wordy parts, and detailed beefy parts. It suffers from a lack of coherent structured writing.

For example, the authors describe at great length, in the first few chapters, why observability is preferable to monitoring. A point well made, if in too many words. Once that's established, subsequent chapters keep making the same argument over and over, which is plain annoying - the reader got that in the first few chapters.

This could maybe be condensed into four or so longer blog posts. Not necessary to make a book out of it.

[Thiago Ghisi · Rating 5 out of 5]

The best technical book I have read in a very long time!

Fascinating book introducing many new revolutionary concepts and practices on how to achieve production excellence and reliability in 2023.

I would say is probably the most ground breaking book on the space after Google SRE book that came up almost 10 years ago.

Strongly recommend to developers and especially to managers and tech executives.

[Adham Salama · Rating 1 out of 5]

This is the worst technical book I have ever read in my life. Mainly because there is nothing technical about it. The first 4 chapters/80 pages area all about how observability is different from monitoring.
WE GET IT. HOW CAN A PERSON STRETCH A SINGLE SENTENCE INTO 80 PAGES?!!!! INSANE!!!

I stopped reading the book because I don't want to spend the rest of my life reading that OBSERVABILITY IS NOT MONITORING.

[V. Tei-Lee]

Disclaimer: I read only a free sample of the book. And I'm planning to revisit the full book later.

The sample was mostly focused on what observability is, but not how to achieve it, are there any drawbacks such as the elevated costs, if there are then how to find a balance between full observability and performance. I might ask too much, but I'd like to see the ideas regarding these problems.

[Edmund · Rating 2 out of 5]

The low rating is primarily down to this book's need for an aggressive editor. There is some good content contained within the book, but it could have come in a much more succinct package. As such, I wouldn't recommend this book to others.

[Josa Vicente · Rating 5 out of 5]

A good book about Observability, keeping clear main points. Focus on separate monitoring from observability. Maybe the final part of the book, more focus in politics and management is a little more boring. But in general an excellent book to approach the topic.

[Rémi Goyard · Rating 4 out of 5]

Very interesting book. Gives a strong presentation of the observability landscape, and why observability differs from monitoring.
Everyone in a company willing to observe their system should have read this book!

[Damien · Rating 4 out of 5]

This is a truly excellent book, which could become a must-have.
It doesn't get a 5/5 because of the guest author chapters, which were of a really lower quality.

[George Cocu · Rating 3 out of 5]

It should have been a 150 pages book.

[Charles Guertin · Rating 5 out of 5]

Great relatable book. Observability is a must for SREs such as myself who want to effectively debug incidents in production. Loved it.

[Illia · Rating 2 out of 5]

So many text about almost nothing. It seems like author wrote about 30-40,pages of actual information and afterwards asked ChatGPT to make 400 pages out of it.

[Sean Ankenbruck · Rating 5 out of 5]

Great introduction to the core concepts of Observability in modern software development.

[Misho Tektumanidze · Rating 3 out of 5]

Would’ve given 4 stars if it wasn’t so repetitive

[Jascha · Rating 2 out of 5]

They just try to sell you their product, even if the first thing they say is they do not. Nothing much really.

[Lun Wang · Rating 4 out of 5]

"Structured events are the building blocks of observability", tracking is just a good solution, we can also implement good observability by logging with structured events.