OpenTelemetry Fundamentals + Spring Boot Integration

OpenTelemetry is the CNCF vendor-neutral standard for application instrumentation. One SDK, one set of APIs, exportable to any backend — Datadog, Grafana Tempo, Jaeger, New Relic, Honeycomb. Covers traces, metrics, and logs.

The value proposition

• Instrument once, export anywhere
• Before OTel, every APM had its own agent; switching vendors meant rewriting instrumentation
• OTel solves lock-in; every major APM now consumes OTLP (its wire protocol)
• As of 2026: traces stable, metrics stable, logs maturing

Three integration paths for Spring Boot

Java Agent (easiest, zero-code)

• Download opentelemetry-javaagent.jar; launch with -javaagent flag
• Auto-instruments Spring MVC, Spring WebFlux, JDBC, HTTP clients, Kafka, Redis, MongoDB
• Configure via env vars: OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT
• Start here for any new service; minimal effort, big coverage

Spring Boot Starter (more control)

• Add opentelemetry-spring-boot-starter dependency
• Configure via application.yml; integrates with Spring auto-config
• Plays well with Actuator and Micrometer

Manual SDK (most control)

• Build OpenTelemetrySdk programmatically; wire up TracerProvider, exporters, samplers
• Use for custom setups or when the agent isn't an option

Manual instrumentation for business spans

• Auto covers HTTP, DB, messaging — but your domain logic needs explicit spans
• Use Tracer API: spanBuilder, setAttribute, makeCurrent, recordException, end
• Wrap in try-with-resources (Scope) and try/catch/finally pattern
• Add business attributes: payment.id, customer.region, order.total

The Collector is the fanout/processing proxy

• Receives OTLP from apps; processes (batch, sample, scrub); exports to one or more backends
• Tail-based sampling: decide what to keep after seeing the full trace
• PII scrubbing: strip sensitive fields before sending to third-party backends
• Multi-backend: send to Datadog and Grafana Tempo simultaneously for migration or redundancy
• Deploy as sidecar, DaemonSet, or gateway; gateway mode is most common at scale

Semantic conventions matter

• OTel defines standard attribute names: http.request.method, db.system, messaging.destination
• Backends have pre-built dashboards expecting these names
• Deviating means rebuilding dashboards — stick to conventions

Sampling strategy

• Default: 10% head-based plus force-sample-on-error plus tail-based in Collector
• Balances cost and debug value
• Tail-based keeps errors and slow traces preferentially

What to avoid

• Don't run OTel Java Agent and vendor agent simultaneously — duplicate instrumentation, broken traces
• Don't rip out mature vendor instrumentation to adopt OTel for purity — migrate incrementally
• Don't ignore cardinality; OTel doesn't save you from bad label design

The strategic answer

• OTel is the portability bet for 3+ year architecture
• Start with Java Agent for new services; zero-code, broad coverage
• Add manual instrumentation for business-domain spans
• Deploy a Collector for flexibility and processing
• Export to whichever backend fits your cost/feature needs; can change later