observability opentelemetry

OpenTelemetry configuration gotchas

Last week, I described several approaches to OpenTelemetry on the JVM, their requirements, and their different results. This week, I want to highlight several gotchas found across stacks in the zero-code instrumentation. The promise of OpenTelemetry Since its inception, OpenTelemetry has unified the 3 pillars of observability. In the distributed tracing space, it replaced proprietary protocols Zipkin and Jaeger. IMHO, it achieved such success for several reasons: First, a huge industry press

observability opentelemetry distributed tracing spring boot quarkus kotlin coroutines

OpenTelemetry Tracing on the JVM

You may know I’m a big fan of OpenTelemetry. I recently finished developing a master class for the YOW! conference at the end of the year. During development, I noticed massive differences in configuration and results across programming languages. Even worse, differences exist across frameworks inside the same programming language. In this post, I want to compare the different zero-code OpenTelemetry approaches on the JVM, covering the most widespread: Spring Boot with Micrometer Tracing

devops opentelemetry jaeger observability tracing

End-to-end tracing with OpenTelemetry

Whether you implement or not microservices (and you probably shouldn’t), your system is most probably composed of multiple components. The most straightforward system is probably made of a reverse proxy, an app, and a database. In this case, monitoring is not only a good idea; it’s a requirement. The higher the number of components through which a request may flow, the strongest the requirement. However, monitoring is only the beginning of the journey. When requests start to fail en