In this article we are going to explain Jaeger integration with the OpenTelemetry collector, describe differences between these two and have a look at Kubernetes deployment via Jaeger Operator. OpenTelemetry collector is a vendor-agnostic service for receiving, processing and exporting telemetry data. In the Jaeger project we have decided to deprecate the Jaeger collector and migrate its functionality to an implementation based on OpenTelemetry collector.

In this article you will learn how to generate Jaeger model classes and gRPC services from protobuf definitions. The generated code can be used to write integrations or it can be used in tests to query tracing data from Jaeger-query service. This is the use case we are going to look at in more detail.

Distributed tracing remains one of the most important features of any tracing system. Nearly a year ago, we announced Elastic APM distributed tracing, let’s take a look at how this useful feature works behind the scenes. Over the past few years, many applications have adopted microservice architecture. Each of the services in a microservice architecture can have their own instrumentation to provide observability into the service.

Distributed tracing is great — it helps you identify (micro)services within complex architectures having issues interfering with user experience, such as high latency or errors. But once a problematic service is identified, it can be difficult to find out which methods are to blame for the slowdown. Well, we have some big news to share for our Elastic APM users within the Java ecosystem.

We’re really big fans of OpenTelemetry at Honeycomb. As we’ve blogged about before, OpenTelemetry is the next phase of the OpenTracing and OpenCensus projects. Instead of working on separate but similar efforts, those two projects have merged to create OpenTelemetry. This is wonderful for the larger community as it gives people a clear way to instrument their code for metrics and traces that isn’t specific to any tool or vendor. OpenTelemetry is a CNCF sandbox project.

Finding slow JavaScript code can be a tricky problem to solve. Small code changes can have a big impact on the performance of your code. Fortunately, many different approaches can help you nail down the exact source of the problem. In this post, you’ll learn about three methods that’ll bring you the results you’re seeking. You can trust manual code inspection, but that has its disadvantages.

In the previous blog post Data analytics with Jaeger aka traces tell us more! we have introduced our data science initiative and platform. The ultimate goal is to develop new functionality within the Jaeger project based on AI/ML that will provide new insights into our applications. This type of functionality is also referred to as AI operations (AIOps). Jupyter notebooks provide a simple user interface for experimenting with data.

Weave trimmed troubleshooting fat, cut API response time from seconds to milliseconds with Jaeger.

In this article we will look at the agent-like instrumentation tool T-Trace. The tool provides non-intrusive instrumentation capabilities for applications running on GraalVM. We will instrument a simple NodeJS application by using T-Trace and OpenTracing API with Jaeger NodeJS tracer.

Software monitoring allows developers and IT professionals to observe events occurring within a monitored system. The data gathered by monitoring processes offers visibility into how the monitored entity is behaving and provides warning signs indicating that some aspect of the system deserves greater attention. More and more software is migrating to the cloud, and monolithic software is being decomposed into microservices to create distributed applications.