OpenTelemetry

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