Deployment

Jaeger backend is released as a single binary or container image (see Downloads). Despite that, it can be configured to operate in different roles, such as all-in-one, collector, query, and ingester (see Architecture).

Configuration

An explicit YAML configuration file must be provided via the --config command line argument (see Configuration). When running in a container, the path to the config file must be mapped into the container file system (the -v ... mapping below):

docker run --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  -p 4318:4318 \
  -p 5778:5778 \
  -p 9411:9411 \
  -v /path/to/local/config.yaml:/jaeger/config.yaml \
  jaegertracing/jaeger:2.dev.0 \
  --config /jaeger/config.yaml

Scaling

Both Jaeger collector and query are stateless and thus many instances can be run in parallel.

Upgrades

Since Jaeger microservices (components) are stateless, all the state lives in the data store(s). When no breaking changes are introduced in a release, the order of upgrades for individual Jaeger components does not matter.

We try to avoid any kinds of breaking changes in new versions, but sometimes they are unavoidable and will be clearly called out in the release notes. In those cases the safest upgrade order is by starting from the end of the ingestion pipeline: first query, then ingester if using Kafka, then collector. This order ensures that the receiving component is running on a newer version and is capable of understanding any protocol changes from the other components earlier in the pipeline before those are upgraded.

Finally, sometimes we introduce storage schema changes that may require some proactive steps before upgrading Jaeger components. Such changes will always be marked as breaking changes in the release notes and contain specific instructions for upgrading.

Management Ports

The following intra-oriented ports are exposed by default (can be changed via configuration):

See APIs for the list of all API ports.

SPM

Service Performance Monitoring (SPM) requires a deployment of Prometheus-compatible metrics storage (see SPM page).

Service Maps

In order to display service dependency diagrams, production deployments need an external process that aggregates data and computes dependency links between services. Project spark-dependencies is a Spark job which derives dependency links and writes them directly to the storage.

Where to Go Next