,
6 tweets,
2 min read
Read on Twitter
This is an excellent, carefully observed piece on the cultural impact of observability tooling on an engineering team.
The architectural source of truth *has* to move out of our heads and into a shared tool, and tracing can really help here.
The architectural source of truth *has* to move out of our heads and into a shared tool, and tracing can really help here.
I'm always background processing about better, simpler ways of explaining observability and why it matters. (I have no hobbies 🙄) You can *almost* reduce it to this simple formula:
High Cardinality Events + Tracing == Observability
High Cardinality Events + Tracing == Observability
It's not completely accurate and does not account for all types of systems, but it ranks a lot higher than "three pillars" does on the truthiness scale.
It would not offend me as an engineer to make this statement in marketing material. It rounds up to true.
It would not offend me as an engineer to make this statement in marketing material. It rounds up to true.
I realized this while writing a long post last week called "so you want an open source observability tool".
The post works backwards from the definition of observability -- handle unknown unknowns, understand any internal system state without shipping code to handle it --
The post works backwards from the definition of observability -- handle unknown unknowns, understand any internal system state without shipping code to handle it --
-- and extrapolates the technical requirements for storage, retrieval, and UX. You can use it as a checklist to see if a vendor who claims to do observability actually does or not, or you can use it to build or cobble together OS o11y.
Please tell me if you do so. ☺️
Please tell me if you do so. ☺️
I also link to existing efforts in that vein. The post isnt up yet bc it got swiped for honey blog, but will go up Tuesday so look for it then. 🐝
