Tracing
Distributed tracing connects a single item across multiple steps and services.
OpenTelemetry Integration
Enable tracing with standard Quarkus OpenTelemetry settings and export to your collector.
quarkus.otel.enabled=true
quarkus.otel.exporter.otlp.endpoint=http://otel-collector:4318
quarkus.otel.exporter.otlp.protocol=http/protobufWhen OTLP tracing is enabled, spans and span events are emitted to the collector in real time. That is the live topology source for Tempo. Prometheus does not ingest or poll spans.
Sampling
For high-volume pipelines, use sampling to control overhead while keeping representative traces. Client spans can be forced for selected services via:
pipeline.telemetry.tracing.client-spans.force=true
pipeline.telemetry.tracing.client-spans.allowlist=ProcessCsvPaymentsInputService,ProcessCsvPaymentsOutputFileServiceCustom Spans
Add spans around external calls or expensive transformations to make hotspots visible:
try (Scope ignored = tracer.spanBuilder("payment.validate").startScopedSpan()) {
// validation work
}Context Propagation
For streaming pipelines, ensure context is carried across async boundaries and emitted in downstream services. Use MDC for logs and OpenTelemetry context for traces.
Tracing Strategy
- Use meaningful span names (step + action)
- Capture failures as span events
- Avoid logging sensitive payloads in span attributes
- Record step class and pipeline run attributes (
tpf.*) - Enable per-item spans only when needed (
pipeline.telemetry.tracing.per-item=true)
TPF runtime tracing also emits:
tpf.pipeline.runspanstpf.stepspanstpf.step.starttpf.step.emittpf.step.retrytpf.step.successtpf.step.error
For replay JSON versus live Tempo usage, see Replay & Live Topology.
AWS Lambda and X-Ray
For Lambda deployments that use AWS X-Ray, add Quarkus Lambda X-Ray support:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-amazon-lambda-xray</artifactId>
</dependency>For SnapStart/tiered compilation operational guidance, see: