Jaeger embraces OpenTelemetry collector

Pavol Loffay
May 1, 2020 · 3 min read

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. See Jaeger and OpenTelemetry post by Yuri Shkuro on the long-term integration roadmap.

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. This has several benefits:

Roadmap

In the long term we would like to base the Jaeger collector, agent and ingester components on OpenTelemetry collector. These new components will be separate distributions with new image and binary names.

Our goal is to provide a smooth migration from existing binaries by supporting legacy Jaeger configuration (flags, env. vars, Jaeger configuration file). However, there will be a couple of breaking changes:

  • a different set of metrics exposed by these components
  • different health check and metric endpoints
  • not all flags will be supported in the new component e.g. ,

Follow this milestone on Github to see what is missing for the first stable release.

In the meantime, you can use collector image with the tag .

Configuration & give it a try!

Upstream OpenTelemetry collector is configurable via a configuration file that is provided as a flag at application startup. If the configuration file is missing the collector will not start because it does not know what components (receivers, processors, exporters) should be used.

Jaeger’s build of the OpenTelemetry collector is opinionated about the configuration and it always uses a set of default components: Jaeger receiver, processors, and exporter. The exporter is one of Jaeger’s supported storage backends: Elasticsearch, Cassandra, Kafka (buffer). The configuration provided in the file is merged with the default configuration.

Jaeger specific components can be configured by the same flags that were exposed by the Jaeger collector e.g. . The configuration provided in OpenTelemetry config has higher precedence.

The configuration precedence from the lowest to the highest is as follows:

  1. Jaeger default values <Jaeger config file< environmental variables < flags (Viper’s default precedence order)
  2. OpenTelemetry configuration file

Let’s have a look at an example that configures Jaeger OpenTelemetry collector:

  • Enables Elasticsearch backend with URL , primary shards (default is ) and replica shards (default )
  • Disables batch processor (enabled by default). It’s disabled because it is not specified in the array.
  • Enables attribute processor (disabled by default). Note that new components have to be explicitly added to the pipeline.
docker run --rm -it -v ${PWD}:/config \
-e SPAN_STORAGE_TYPE=elasticsearch \
jaegertracing/jaeger-opentelemetry-collector \
--config-file=/config/config.yaml \
--es.server.urls=http://localhost:9200 \
--es.num-shards=3

The content of :

exporters:
jaeger_elasticsearch:
es:
server-urls: http://elasticsearch:9200
num-replicas: 2
processors:
attributes:
actions:
- key: user
action: delete
service:
pipelines:
traces:
processors: [attributes]

The storage exporter can be configured via the same environmental variable as Jaeger collector or it can be specified in .

Jaeger Operator

Because the new components can be considered as almost drop-in replacements for existing Jaeger binaries we will be able to directly use them in the Jaeger Operator, by explicitly providing the image name in the CR. The required change in the Jaeger Operator is to expose the OpenTelemetry configuration in the CR. At the moment this is just a design proposal that is being discussed in the issue jaeger-operator/issues/1004.

Following the same configuration as in the previous section, the OpenTelemetry configuration is directly embedded into Jaeger collector node:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: simple-prod
spec:
strategy: production
collector:
config: |
exporters:
jaeger_elasticsearch:
es:
server-urls: http://elasticsearch:9200
num-replicas: 2
processors:
attributes:
actions:
- key: user
action: delete
service:
pipelines:
traces:
processors: [attributes]
storage:
type: elasticsearch
options:
es:
server-urls: http://localhost:9200
num-shards: 3

Conclusion

We have explained how the Jaeger project integrates with OpenTelemetry collector and what are the key differences between these components. Share your feedback with us and try our new collector based on OpenTelemetry.

References

JaegerTracing

Open source distributed tracing platform at Cloud Native…

JaegerTracing

Open source distributed tracing platform at Cloud Native Computing Foundation (graduated). https://jaegertracing.io

Pavol Loffay

Written by

Software engineer working in observability space. Working on Hypertrace, OpenTelemetry, Jaeger, OpenTracing, MicroProfile projects.

JaegerTracing

Open source distributed tracing platform at Cloud Native Computing Foundation (graduated). https://jaegertracing.io

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store