Jaeger 2.22.0

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Jaeger 2.22.0 on Ubuntu 24.04 as the software version, choose your Region, then choose Launch through EC2. Choose m5.large, your key pair and a security group as above.

Traces are stored on the root volume under /var/lib/jaeger/data, so give it room for your traffic and retention (48 hours by default). 30 GiB or more is a sensible start.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=30,VolumeType=gp3}' \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=jaeger}]'

First boot takes a few seconds after the instance is running. Jaeger is ready a few seconds after that.

Connect over SSH as ubuntu, the default SSH user for Jaeger 2.22.0 on Ubuntu 24.04:

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot sets the password and the certificate, then nginx and Jaeger start. Check the three units and the first-boot marker:

systemctl is-active jaeger nginx jaeger-firstboot
sudo test -f /var/lib/sac/data/jaeger-firstboot.done && echo FIRSTBOOT_DONE

All three units are active and the first-boot marker is present:

active active active FIRSTBOOT_DONE

Only SSH and nginx listen on network ports. Everything Jaeger opens is on the loopback address:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | grep -v '127.0.0.5' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort

0.0.0.0:22 users:(("sshd"),("systemd")) 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx")) 0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx")) 127.0.0.1:13133 users:(("jaeger")) 127.0.0.1:16685 users:(("jaeger")) 127.0.0.1:16686 users:(("jaeger")) 127.0.0.1:4317 users:(("jaeger")) 127.0.0.1:4318 users:(("jaeger")) [::]:22 users:(("sshd"),("systemd")) [::]:443 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx")) [::]:80 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx"))

Query Jaeger's own health endpoint, on the loopback address:

curl -s http://127.0.0.1:13133/status | jq -r .status

StatusOK

Read the credentials file:

sudo cat /root/jaeger-credentials.txt

The file is readable by root only. It contains:

# Jaeger 2.22.0 on Ubuntu 24.04 (sac) - generated on this instance's first boot. # This password is unique to this instance; none was baked into the image. Keep this file secret. JAEGER_URL=https://<public-ip>/ JAEGER_USER=admin JAEGER_PASSWORD=<JAEGER_PASSWORD> OTLP_HTTP_TRACES_URL=https://<public-ip>/v1/traces # Web UI + query API: https://<host>/ (HTTP basic auth with the user and password above) # Trace ingest: OTLP/HTTP (protobuf or JSON) POST to https://<host>/v1/traces with the SAME basic auth, e.g. # OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://<host>/v1/traces # OTEL_EXPORTER_OTLP_TRACES_HEADERS="Authorization=Basic <base64 of admin:password>" # OTEL_EXPORTER_OTLP_TRACES_CERTIFICATE=<a copy of /etc/nginx/tls/jaeger.crt> # OTLP gRPC (4317) and HTTP (4318) listen on 127.0.0.1 only: use an SSH tunnel or a collector on this instance. # Health: https://<host>/healthz (no login; answers "ok") # The certificate is self signed (minted on this instance): accept the browser warning once, give senders the # certificate, or install your own. Serve a DNS name instead:
sudo jaeger-set-hostname <your-dns-name>
# Data (Badger): /var/lib/jaeger/data Self-test:
sudo /usr/local/sbin/jaeger-selftest.sh
# User guide: https://secureanycloud.com/stacks/jaeger-2-22-0/

The URL uses the instance's public IP address from the EC2 instance metadata. The certificate also names the public DNS name and the private IP address, so https://<public-dns-name>/ and https://<private-ip>/ work too.

If you stop and start the instance without an Elastic IP, the boot service picks up the new address and issues a new certificate for it. To serve Jaeger under your own DNS name, see Step 9.

A request without the password gets nginx's 401, and the health check answers without one:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/
curl -sk https://127.0.0.1/healthz

401 ok

Applications send traces with OTLP over HTTP to https://<host>/v1/traces, with the user admin and the password from the credentials file. To see it work on the instance, send one example trace of a checkout request that passes through three services (frontend, shop-api and payments, seven spans), in OTLP's JSON encoding.

The small shell function jg passes the password from the credentials file to curl on standard input, so the password never appears on a command line:

jg() {
sudo sed -n 's/^JAEGER_PASSWORD=\(.*\)/user = "admin:\1"/p' /root/jaeger-credentials.txt | curl -sgk -K - "$@"; }
TRACE=$(openssl rand -hex 16);
T0=$(( $(date +%s) - 5 )) ts() { printf '%s%09d' "${T0}" $(( $1 * 1000000 )); } span() {
# id parent name kind start_ms end_ms attributes-json printf '{"traceId":"%s","spanId":"%s","parentSpanId":"%s","name":"%s","kind":%s,"startTimeUnixNano":"%s","endTimeUnixNano":"%s","attributes":[%s]}' \
  "${TRACE}" "$1" "$2" "$3" "$4" "$(ts "$5")" "$(ts "$6")" "$7"; } attr() { printf '{"key":"%s","value":{"stringValue":"%s"}}' "$1" "$2"; } svc() { printf '{"resource":{"attributes":[%s]},"scopeSpans":[{"scope":{"name":"demo"},"spans":[%s]}]}' "$(attr service.name "$1")" "$2"; } FRONT="$(span 1000000000000001 "" "GET /checkout" 2 0 420 "$(attr http.route /checkout),$(attr http.request.method GET)"),$(span 1000000000000002 1000000000000001 "POST /api/orders" 3 20 400 "$(attr server.address shop-api)")" SHOP="$(span 2000000000000001 1000000000000002 "POST /api/orders" 2 30 390 "$(attr http.route /api/orders)"),$(span 2000000000000002 2000000000000001 "SELECT orders" 3 40 160 "$(attr db.system.name postgresql),$(attr db.operation.name SELECT)"),$(span 2000000000000003 2000000000000001 "POST /charge" 3 170 380 "$(attr server.address payments)")" PAY="$(span 3000000000000001 2000000000000003 "POST /charge" 2 180 375 "$(attr http.route /charge)"),$(span 3000000000000002 3000000000000001 "card-network authorize" 3 200 360 "$(attr peer.service card-network)")" printf '{"resourceSpans":[%s,%s,%s]}' "$(svc frontend "${FRONT}")" "$(svc shop-api "${SHOP}")" "$(svc payments "${PAY}")" > /tmp/demo-trace.json jg -X POST -H 'Content-Type: application/json' --data-binary @/tmp/demo-trace.json https://127.0.0.1/v1/traces; echo echo "trace id: ${TRACE}"

Jaeger accepts the whole trace. An empty partialSuccess means no span was rejected:

{"partialSuccess":{}} trace id: 85ebcfe31dbcdf5c6d81179a713e86b1

The same upload without the password is refused by nginx before it reaches Jaeger:

curl -sk -o /dev/null -w '%{http_code}\n' -X POST -H 'Content-Type: application/json' --data-binary @/tmp/demo-trace.json https://127.0.0.1/v1/traces

401

Ask Jaeger which services and operations it has seen, through the query API (the same API the web UI uses):

jg() {
sudo sed -n 's/^JAEGER_PASSWORD=\(.*\)/user = "admin:\1"/p' /root/jaeger-credentials.txt | curl -sgk -K - "$@"; } jg https://127.0.0.1/api/v3/services; echo jg "https://127.0.0.1/api/v3/operations?service=shop-api" | jq -c '[.operations[].name]'

{"services":["frontend","payments","shop-api"]} ["POST /api/orders","POST /charge","SELECT orders"]

Search for the traces that touched payments in the last hour and list their spans:

jg() {
sudo sed -n 's/^JAEGER_PASSWORD=\(.*\)/user = "admin:\1"/p' /root/jaeger-credentials.txt | curl -sgk -K - "$@"; } jg -G https://127.0.0.1/api/v3/traces --data-urlencode query.service_name=payments \
  --data-urlencode "query.start_time_min=$(date -u -d '-1 hour' +%Y-%m-%dT%H:%M:%SZ)" \
  --data-urlencode "query.start_time_max=$(date -u -d '+1 minute' +%Y-%m-%dT%H:%M:%SZ)" --data-urlencode query.search_depth=1 \
  | jq -r '.result.resourceSpans[] | (.resource.attributes[] | select(.key=="service.name") | .value.stringValue) as $svc | .scopeSpans[].spans[] | "\($svc): \(.name)"' | sort -u

frontend: GET /checkout frontend: POST /api/orders payments: POST /charge payments: card-network authorize shop-api: POST /api/orders shop-api: POST /charge shop-api: SELECT orders

Jaeger also derives the service dependency graph from the traces:

jg() {
sudo sed -n 's/^JAEGER_PASSWORD=\(.*\)/user = "admin:\1"/p' /root/jaeger-credentials.txt | curl -sgk -K - "$@"; } jg -G https://127.0.0.1/api/dependencies --data-urlencode endTs=$(( $(date +%s) * 1000 )) --data-urlencode lookback=3600000 | jq -c '.data'

[{"parent":"frontend","child":"shop-api","callCount":1},{"parent":"shop-api","child":"payments","callCount":1}]

In the browser, open the URL from the credentials file. Your browser warns once about the self-signed certificate. Accept the warning, or install your own certificate (Step 9). Then sign in as admin with the password from the credentials file.

On Search, pick a service (here frontend) and choose Find Traces. The chart shows each trace's duration over time, and the table lists the traces with their services and span counts.

Select a trace to open its timeline. Each row is a span, indented under its parent, and the bars show when it ran and for how long. Here the database query and the card network call are the two longest steps inside shop-api and payments.

System Architecture draws the dependency graph between your services from the traces it has stored.

The example data is yours to delete. It ages out after 48 hours. For a clean store sooner, stop Jaeger, empty /var/lib/jaeger/data/badger and start it again.

Point your OpenTelemetry SDKs or your OpenTelemetry Collector at https://<host>/v1/traces (the private IP or your DNS name, which the certificate names) with basic authentication.

Copy the instance's certificate (/etc/nginx/tls/jaeger.crt) to the senders so that they can verify it, or install a certificate that your systems already trust (Step 9).

Any OpenTelemetry SDK (Java, Python, Go, Node.js, .NET and others) reads the standard environment variables. The header value is Basic followed by the base64 of admin:<password>, with the space written as %20:

OTEL_SERVICE_NAME=my-service OTEL_TRACES_EXPORTER=otlp OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://<host>/v1/traces OTEL_EXPORTER_OTLP_TRACES_HEADERS=Authorization=Basic%20<base64 of admin:password> OTEL_EXPORTER_OTLP_TRACES_CERTIFICATE=/etc/ssl/jaeger.crt

Compute the base64 value on the instance without the password appearing on a command line:

sudo sed -n 's/^JAEGER_PASSWORD=//p' /root/jaeger-credentials.txt | tr -d '\n' | sed 's/^/admin:/' | base64 -w0; echo

OpenTelemetry Collector (or Grafana Alloy's otelcol components): send traces with the otlphttp exporter and the basicauth extension:

extensions: basicauth/jaeger: client_auth: username: admin password: ${env:JAEGER_PASSWORD} exporters: otlphttp/jaeger: endpoint: https://<host> auth: authenticator: basicauth/jaeger tls: ca_file: /etc/otelcol/jaeger.crt service: extensions: [basicauth/jaeger] pipelines: traces: receivers: [otlp] exporters: [otlphttp/jaeger]

OTLP gRPC (port 4317) is not exposed. To use it from your workstation, forward it over SSH and send to localhost:4317 without TLS:

ssh -i <your-key.pem> -N -L 4317:127.0.0.1:4317 ubuntu@<public-ip>

Keep the password in a secrets store or in a file that only the sender can read, never in source code. The Jaeger documentation and the OpenTelemetry documentation cover instrumenting each language.

Jaeger stores traces in an embedded Badger database on the local disk under /var/lib/jaeger/data/badger, with no separate database to run. It keeps traces for 48 hours. Traces that you archive from the web UI (Archive Trace) go to a second store, /var/lib/jaeger/data/badger-archive, which is kept for 30 days. The settings are in /etc/jaeger/config.yaml. Print the storage section:

sudo grep -A6 'sac_store:' /etc/jaeger/config.yaml | head -7

sac_store: badger: directories: keys: /var/lib/jaeger/data/badger values: /var/lib/jaeger/data/badger ephemeral: false ttl:

To keep traces for 7 days, change spans: 48h under sac_store to spans: 168h (sudo nano /etc/jaeger/config.yaml), then run sudo systemctl restart jaeger. Keep every 127.0.0.1 endpoint as it is.

Badger reserves its value log files in 2 GiB pieces. These are sparse files, so they use only the space their data needs.

For higher volumes or long retention, Jaeger can use Elasticsearch, OpenSearch or Cassandra instead (jaeger_storage backends; see the storage documentation). jaeger.service is blocked from the instance metadata service, so it cannot use an instance role. A remote store needs its own credentials.

Point a DNS record at the instance (an Elastic IP keeps the address stable), then set the name that Jaeger is served as. This command mints a new self-signed certificate for the name, updates nginx, the list of origins the web UI may post from and the URLs in /root/jaeger-credentials.txt, and keeps the name across reboots:

sudo jaeger-set-hostname <your-domain>

To use a certificate from a public or internal certificate authority instead (for example one issued by Let's Encrypt for <your-domain>), copy it over the generated pair and reload nginx. Running jaeger-set-hostname again replaces it with a self-signed one:

sudo install -m 0644 <your-domain>.crt /etc/nginx/tls/jaeger.crt
sudo install -m 0600 <your-domain>.key /etc/nginx/tls/jaeger.key
sudo nginx -t && sudo systemctl reload nginx

The shipped self-test checks that:

• the set of listening ports is exactly the expected one, and every Jaeger port is on the loopback address
• Jaeger holds no outbound connection
• an unknown host name is dropped
• requests to the web UI, the query API and trace ingest without a password, with admin/admin or with a wrong password are refused by nginx, while this instance's password is accepted
• a cross-site post or WebSocket upgrade is refused
• the instance metadata service cannot be reached from inside the jaeger and nginx services, while it can from your shell

The password is handed to curl in a root-only temporary file, never on a command line. Run the self-test:

sudo /usr/local/sbin/jaeger-selftest.sh

selftest OK: listening tcp lo:13133 lo:16685 lo:16686 lo:4317 lo:4318 lo:53 pub:22 pub:443 pub:80 | jaeger listeners 127.0.0.1:13133 127.0.0.1:16685 127.0.0.1:16686 127.0.0.1:4317 127.0.0.1:4318 (loopback only), no outbound connection; healthz ok, unknown Host dropped (444); anonymous UI+API+ingest 401, admin/admin and wrong passwords 401 (nginx auth), per-instance password 200 (UI + query API), cross-origin POST and WebSocket 403; instance metadata blocked inside jaeger and nginx (000), reachable from the host shell (200)

Add --ingest to also send one span for a service called sac-selftest and read it back.

The metadata block is a systemd setting on each service. Show it:

systemctl show -p IPAddressDeny jaeger nginx jaeger-firstboot

IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32 IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32

A request for a host name that the instance does not serve gets no answer at all. nginx closes the connection, so curl exits with code 52:

curl -sk -o /dev/null -w '%{http_code}\n' -H 'Host: attacker.example' https://127.0.0.1/healthz; echo "curl exit $?"

000 curl exit 52

The certificate was generated on this instance for its own addresses. Inspect it:

sudo openssl x509 -in /etc/nginx/tls/jaeger.crt -noout -subject -ext subjectAltName

subject=CN = <public-ip>, O = sac X509v3 Subject Alternative Name: IP Address:<public-ip>, DNS:<public-dns-name>, IP Address:<private-ip>, DNS:<private-dns-name>, IP Address:127.0.0.1, DNS:localhost

Print the Jaeger and nginx versions and the build record summary:

/usr/local/bin/jaeger version 2>/dev/null; echo nginx -v 2>&1 grep -E '^(tag commit|toolchain |govulncheck)' /usr/share/doc/jaeger/BUILD-PROVENANCE.txt | cut -c1-110

{"gitCommit":"462bb49fcff9af4be9556bf0206d07f5171bd8d7","gitVersion":"v2.22.0","buildDate":"2026-10-06T11:44:34Z"} nginx version: nginx/1.24.0 (Ubuntu) tag commit 462bb49fcff9af4be9556bf0206d07f5171bd8d7 toolchain go1.27.3 linux/amd64, official tarball https://go.dev/dl/go1.27.3.linux-amd64.tar.gz govulncheck v1.9.0 -mode=binary on this binary: Your code is affected by 0 vulnerabilities. This scan al

These are the files that matter:

• /usr/local/bin/jaeger: the Jaeger binary, run by jaeger.service as the jaeger user
• /etc/jaeger/config.yaml: Jaeger's settings, including receivers, storage and retention, and the loopback endpoints
• /var/lib/jaeger/data: trace storage (Badger) and the archive store
• /etc/nginx/sites-available/sac-jaeger: the nginx site, with HTTPS, basic authentication, and a proxy to 127.0.0.1:16686 and 127.0.0.1:4318
• /etc/nginx/jaeger.htpasswd: the basic authentication user and password hash (SHA-512 crypt)
• /etc/nginx/tls/: this instance's certificate and private key
• /root/jaeger-credentials.txt: URL, user and password (root-only)
• /usr/share/doc/jaeger/: the Apache License 2.0, Jaeger's NOTICE and the build record with the source offer

Run these lines in your SSH session. The new password is read at a prompt and reaches openssl on standard input, so it never appears on a command line or in your shell history:

read -rsp 'New password: ' NEWPASS; echo printf 'admin:%s\n' "$(printf '%s\n' "$NEWPASS" | openssl passwd -6 -stdin)" | sudo tee /etc/nginx/jaeger.htpasswd >/dev/null unset NEWPASS

nginx reads the file on every request, so the new password works at once. Update it on every SDK and collector that sends traces.

Then update or delete JAEGER_PASSWORD in /root/jaeger-credentials.txt (sudo nano /root/jaeger-credentials.txt). To give each team or collector its own login, append another user:hash line in the same format.

• Keep port 443 open only to the networks that need the web UI and to the applications or collectors that send traces, and keep port 22 open only to your admin network. Never open 16686, 16685, 4317, 4318 or 13133.
• Use your own DNS name and a certificate from a certificate authority that your senders trust (Step 9).
• Keep the password in a secrets store and change it when people leave (Step 12). Traces can carry URLs, user identifiers and query text, so treat them as sensitive data and scrub attributes in your SDK or collector where needed.
• The instance applies Ubuntu security updates automatically. To update Jaeger itself, read the release notes, back up /var/lib/jaeger/data, and replace /usr/local/bin/jaeger with a newer build. Check its checksum against the release's sha256sum.txt, then restart the service.