Operations | Monitoring | ITSM | DevOps | Cloud

In this tutorial, we will go through a working example of a Ruby application auto-instrumented with OpenTelemetry. To keep things simple, we will create a basic “Hello World” application, instrument it with OpenTelemetry’s Ruby client library to generate trace data and send it to an OpenTelemetry Collector. The Collector will then export the trace data to an external distributed tracing analytics tool of our choice.

Jaeger is an open-source end-to-end distributed tracing tool for microservices architecture. On the other hand, Elastic APM is an application performance monitoring system that is built on top of the ELK Stack (Elasticsearch, Logstash, Kibana, Beats). In this article, let's explore their key features, differences, and alternatives. Application performance monitoring is the process of keeping your app's health in check. APM tools enable you to be proactive about meeting the demands of your customers.

Jaeger and New Relic are tools used in the application monitoring and observability domain. While Jaeger is an open source tool under Cloud Native Computing Foundation, New Relic is a SaaS vendor in the observability domain. Let us explore the key differences between Jaeger and New Relic in this article. New Relic is an extensive SaaS tool and provides application performance as well as infrastructure monitoring. Jaeger provides an open-source solution for end-to-end distributed tracing.

Jaeger and OpenTracing are both open-source projects. Jaeger was originally built by teams at Uber and then open-sourced. The OpenTracing project was also started by teams at Uber, and hence they are compatible with each other. While Jaeger is an end-to-end distributed tracing tool, OpenTracing is a set of APIs and libraries that can be used to instrument your application.

Open Telemetry represents an effort to combine distributed tracing, metrics and logging into a single set of system components and language-specific libraries. Recently, OpenTelemetry became a CNCF incubating project, but it already enjoys quite a significant community and vendor support. OpenTelemetry defines itself as “an observability framework for cloud-native software”, although it should be able to cover more than what we know as “cloud-native software”.

There’s no strict definition of a distributed system. But generally speaking, if you have reached a point where you’re running more than five interdependent services at once, that means you’re running a distributed system. It also means you are more than likely experiencing difficulties when troubleshooting using traditional debugging tools. Unfortunately, pulling up multiple tools, each built for a monolithic world, doesn’t help pinpoint the problem.

In this blog series, we are covering application instrumentation steps for distributed tracing with OpenTelemetry standards across multiple languages. Earlier, we covered Golang Application Instrumentation for Distributed Traces and DotNet Application Instrumentation for Distributed Traces. Here we are going to cover the instrumentation for Java.