Tracing

OpenTelemetry is not valuable because it produces more telemetry. It is valuable when it helps an engineer answer a production question quickly: what changed, who is affected, where did the request fail, and what should happen next? This guide is a practical starting point for teams moving from basic instrumentation to an observability practice that is useful, affordable, and sustainable. Who this is for This is for software engineers, platform teams, and SREs running distributed applications. It assumes you want vendor-neutral instrumentation and an operational model that works across services, languages, and deployment environments. ...

Ideally, you should be using distributed tracing to trace requests through your system, but Kafka decouples producers and consumers, which means there are no direct transactions to trace between them. Kafka also uses asynchronous processes, which have implicit, not explicit, dependencies. That makes it challenging to understand how your microservices are working together. However, it is possible to monitor your Kafka clusters with distributed tracing and OpenTelemetry. You can then analyze and visualize your traces in an open-source distributed tracing tool like Jaeger or a full observability platform like New Relic. In this post, I will leverage a simple application to show how you can achieve this. ...

“Instrumentation” is one of those words that gets thrown around constantly in the observability world - but what does it actually mean, and how does it work in practice? I’ve run this as a hands-on workshop several times, and what I find most effective is starting from first principles: build a tiny app, make it produce telemetry, and watch what comes out. By the end you understand why the pieces fit together the way they do. ...