opentelemetry

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

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

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. Lo

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.com/5wDwhYhoDM— Suresh G (@sur

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. The base application and its infrastructure I’ll use the same base ap

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. I want to be able to add more comp

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. Instead: The Kotlin service used the e

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. In this post, I explore the different aspects of the Collector: The data kind: logs, metrics, and tracesPush and pull modelsOperations: reads, transformations, and writes First steps A long time ago, observabilit

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