I always thought that metrics were like water. As long as something looks like one and is used like one, it is a metric. However, I was wrong. Metrics are more like champagne: only what comes from the Champagne region may be sold under the name. Everything else is sparkling wine. Likewise, metrics are only metrics if they were produced in the Vallée des Métriques. Everything that does not originate from there is just a sparkling roll-up. ...
Open source development thrives on remixing existing projects to solve new problems. The author reflects on years of finding projects that almost meet requirements, forking them, and contributing improvements back to the community. Experience running open source programs at Cisco and working with OpenTelemetry demonstrated that successful projects extend beyond code itself. Decisions about licensing, what to publish, and how projects evolve matter tremendously. The field has accumulated substantial guidance on these questions through established resources. ...
The author attended Vercel Ship conferences and noticed “observability” featured prominently in keynotes. After learning about Eve, Vercel’s new framework for “durable, filesystem-first AI agents,” the author decided to build a practical project combining Eve with OpenTelemetry and Bronto monitoring. The concrete challenge involved tracking technology events and Call for Papers deadlines scattered across multiple websites. This task required an agent capable of pulling from various feeds, reading details, categorizing events, and integrating with Slack and Jira for team coordination. ...
I am not a native English speaker and that’s why I used AI to answer your questions. I keep seeing this, or a version of it, on issues and PRs. Reading it over and over again, especially when written by first-time contributors, infuriates me, it triggers an irrational anger in me! I am also not a native English speaker, most of the other participants in this conversation aren’t either. ...
If you’re interested in observability, it is very likely that you read Mat Duggan’s Why Clickhouse is Winning the Observability Wars or one of the follow ups and responses to it, for example Charity Majors’. Both are fantastic articles, and I recommend that you spend the time reading them front to back, give them your attention! And by that I also want to get one thing out of the way, that the title here might suggest: I do not disagree with them, I actually agree wholeheartedly with them on why ClickHouse is the current dominant backend in Observability. And they deserve that spot, as I know first hand from working with their product and knowing some of the great people working on it. ...
I’ve been in the observability space long enough, through OpenTelemetry, by seeing and doing dozens of vendor pitches and enough “AI-powered” demos to last a lifetime. So I have a clear idea about what a company needs to be successful in this area, and what would actually make me passionate about working for one. Read the full article on Bronto Blog
A while back I was exploring an open source project I was using, and interested in contributing to, as it provided capabilities I needed but missed some additional ones I wanted to have. Naturally, I was looking for a CONTRIBUTING.md. The file existed, but it only contained a note, that issues and PRs are accepted. While this is key information that belongs in this file, I was missing instructions on how to set up the repository, how to run tests, and what criteria I need to meet to increase my chances of having a PR accepted. ...
Throughout my jobs in the observability space, I created or contributed to various demo and sample applications, which often follow the same premise: there is a “normal state” in which the application is running, and with a trigger, it moves into a “deviated state”. For example, there is the placeOrder transaction on a webshop that performs just fine, and orders and money are flowing into our hypothetical e-commerce company. However, with the click of a button (or a CLI command), an issue is injected into the application, and the placeOrder transaction stops working as expected. Orders go down, money stops flowing, hypothetical customers get angry! ...
Modern reliability practice is excellent at making complex systems operable at the service level, but users experience reliability at the level of end-to-end transactions and flows. This post explores why that gap exists and what it means for how we measure and manage reliability. Read the full article on Causely Blog
“What’s your favorite telemetry signal” has been the last question of the Humans of OpenTelemetry series for the last few years. At KubeCon EU 2024 my answer to this was “profiling, because I think this is really closing a big gap that was missing in observability”. But, today, I found out that my answer has changed, and I am leaning more toward what Vijay Samuel gave as an answer: “I feel metrics are the most powerful signal!” ...