Leading your organization to use OpenTelemetry is a challenge. In addition to all the usual project hurdles, you’ll face one of these two situations: convince your teams to use OpenTelemetry, or convince them to move from the telemetry tool they are already using to OpenTelemetry. Most people don’t want to change. You’ll need lots of effort and baby steps. My tip is the following: the fewer the changes, the higher your chances of success.

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.

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.

I have presented my OpenTelemetry demo many times, and I still do. Each time, the audience is different. To make no two presentations the same, I always ask attendees what stack they are more interested in. I also regularly add new features for the same reason. I was a victim of the IT crisis last summer, and my company fired me, so I no longer work on Apache APISIX. They say that the Chinese ideogram for crisis contains the ideogram for opportunity. I used this opportunity to join LoftLabs.

I recently compared three OpenTelemetry approaches on the JVM: Java Agent v1, v2, and Micrometer. I used Kotlin and coroutines without overthinking. I received interesting feedback on the usage of @WithSpan with coroutines: Nice one..by the way to instrument the coroutine context properly, don't we need "opentelemetry-extension-kotlin" also? Without that, spans are not recorded properly for suspend functions (https://t.co/DSgJklnllD) pic.twitter.

My demo of OpenTelemetry Tracing features two Spring Boot components. One uses the Java agent, and I noticed a different behavior when I recently upgraded it from v1.x to v2.x. In the other one, I’m using Micrometer Tracing because I compile to GraalVM native, and it can’t process Java agents. I want to compare these three different ways in this post: Java agent v1, Java agent v2, and Micrometer Tracing.

I continue to work on my Opentelemetry demo. Its main idea is to showcase traces across various technology stacks, including asynchronous communication via an MQTT queue. This week, I added a couple of components and changed the architecture. Here are some noteworthy learnings; note that some of them might not be entirely connected to OpenTelemetry. Here’s an updated diagram. New components appear in violet, and updated components appear in green.

Last year, I wrote a post on Open Telemetry Tracing to understand more about the subject. I also created a demo around it, which featured the following components: The Apache APISIX API GatewayA Kotlin/Spring Boot serviceA Python/Flask serviceAnd a Rust/Axum service I’ve recently improved the demo to deepen my understanding and want to share my learning. Using a regular database In the initial demo, I didn’t bother with a regular database.

The OpenTelemetry Collector sits at the center of the OpenTelemetry architecture but is unrelated to the W3C Trace Context. In my tracing demo, I use Jaeger instead of the Collector. Yet, it’s ubiquitous, as in every OpenTelemetry-related post. I wanted to explore it further.

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.