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.
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
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.
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 --
-- 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. ☺️
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. 🐝
You can follow @mipsytipsy.
Tip: mention @threader_app on a Twitter thread with the keyword “compile” to get a link to it.
Enjoy Threader? Sign up.
Threader is an independent project created by only two developers. The site gets 500,000+ visits a month and our iOS Twitter client was featured as an App of the Day by Apple. Running this space is expensive and time consuming. If you find Threader useful, please consider supporting us to make it a sustainable project.