Dev Note

OpenTelemetry in 2026: Observability Has Finally Grown Up
For most of the 2010s, observability was a vendor lock-in problem. Your metrics were in Datadog. Your traces were in New Relic or Jaeger. Your logs were in Splunk or ELK. Switching any of them meant ripping out instrumentation code, rewriting dashboards, and re-training oncall engineers.
OpenTelemetry changed this. It’s now the undisputed standard for telemetry collection, and the ecosystem has matured to the point where “just use OTel” is genuinely safe advice for most production systems.
This is what the landscape looks like in 2026 and how to use it well.
Photo by Carlos Muza on Unsplash
What OpenTelemetry Actually Is
OTel is three things:
A specification — defines what traces, metrics, and logs look like (semantic conventions, data models, protocols)
SDKs — language implementations for instrumenting your code (Go, Java, Python, Node.js, .NET, Rust, and more)
The Collector — a vendor-neutral agent/gateway that receives, processes, and exports telemetry to backends
The key insight is the separation of instrumentation from export. Your code instruments using OTel APIs. Where that telemetry goes (Datadog, Honeycomb, Jaeger, your own Prometheus) is a configuration decision, not a code decision.
App → OTel SDK → (OTLP protocol) → OTel Collector → [Jaeger, Prometheus, Grafana, Datadog, ...]
The Three Pillars in 2026
Traces
Tracing is where OTel started (it merged OpenCensus and OpenTracing) and where it’s most mature.
A trace represents a single request’s journey through your system. Each unit of work is a span. Spans have a parent-child relationship forming a tree, and spans from different services that share a trace_id form a distributed trace.
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="http://collector:4317")
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("order-service")
def process_order(order_id: str):
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order.id", order_id)
        span.set_attribute("order.service", "payment")
        
        result = charge_payment(order_id)  # Creates a child span automatically
        
        if result.success:
            span.set_status(trace.StatusCode.OK)
        else:
            span.set_status(trace.StatusCode.ERROR, result.error)
        
        return result
Auto-instrumentation handles the basics without any code changes. For Python:
pip install opentelemetry-instrumentation-fastapi opentelemetry-instrumentation-sqlalchemy
opentelemetry-instrument --exporter otlp python -m uvicorn app:main
This automatically instruments FastAPI routes, SQLAlchemy queries, outgoing HTTP calls, and more. Most of your traces come for free.
Metrics
OTel metrics reached GA in 2023 and are now the recommended approach for greenfield systems. The model is different from Prometheus’ pull-based scraping:
meter := otel.Meter("order-service")
// Counter: monotonically increasing value
ordersProcessed, _ := meter.Int64Counter(
    "orders.processed",
    metric.WithDescription("Total orders processed"),
    metric.WithUnit("{order}"),
)
// Histogram: distribution of values
orderLatency, _ := meter.Float64Histogram(
    "orders.processing.duration",
    metric.WithDescription("Order processing latency"),
    metric.WithUnit("ms"),
    metric.WithExplicitBucketBoundaries(5, 10, 25, 50, 100, 250, 500, 1000),
)
func ProcessOrder(ctx context.Context, order Order) error {
    start := time.Now()
    
    err := doProcess(ctx, order)
    
    duration := time.Since(start).Milliseconds()
    orderLatency.Record(ctx, float64(duration), metric.WithAttributes(
        attribute.String("status", statusFromErr(err)),
    ))
    ordersProcessed.Add(ctx, 1, metric.WithAttributes(
        attribute.String("payment_method", order.PaymentMethod),
    ))
    
    return err
}
OTel metrics export to Prometheus (via the Prometheus exporter or via the Collector’s Prometheus remote write exporter) or directly to your backend via OTLP.
Semantic conventions are the underrated feature here. OTel defines standard attribute names for common operations: http.request.method, db.system, messaging.system, etc. When everyone uses the same attribute names, dashboards and alerts become portable across teams and organizations.
Logs
Logs are the newest pillar to reach stability. OTel’s log model integrates with existing log frameworks (SLF4J, Python logging, slog in Go) via log bridges — adapters that send existing log records into the OTel pipeline.
// No code change needed — just configure the OTel Log Bridge
// In your OTLP exporter config, existing SLF4J/Log4j logs flow through OTel
The real value: logs get correlated with traces automatically. If your logging happens within an active span, the trace_id and span_id are attached to the log record. In your observability backend, you can click from a trace span directly to the logs that were emitted during that span. This is genuinely transformative for debugging.
The OTel Collector: Your Telemetry Pipeline
The Collector deserves more attention than it typically gets. It’s not just a forwarder — it’s a programmable telemetry processing pipeline.
# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
        - job_name: 'node-exporter'
          static_configs:
            - targets: ['node-exporter:9100']
processors:
  batch:
    send_batch_size: 1024
    timeout: 1s
  
  resourcedetection:
    detectors: [env, system, docker]
  
  filter/drop_health_checks:
    traces:
      span:
        - 'attributes["http.target"] == "/health"'
  
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors-policy
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: slow-traces-policy
        type: latency
        latency: {threshold_ms: 1000}
      - name: probabilistic-policy
        type: probabilistic
        probabilistic: {sampling_percentage: 1}
exporters:
  jaeger:
    endpoint: jaeger:14250
  prometheusremotewrite:
    endpoint: "http://prometheus:9090/api/v1/write"
  otlp/honeycomb:
    endpoint: api.honeycomb.io:443
    headers:
      x-honeycomb-team: ${HONEYCOMB_API_KEY}
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resourcedetection, filter/drop_health_checks, tail_sampling]
      exporters: [jaeger, otlp/honeycomb]
    metrics:
      receivers: [otlp, prometheus]
      processors: [batch, resourcedetection]
      exporters: [prometheusremotewrite]
Key Collector features:
Tail sampling: Make sampling decisions after seeing the full trace. Always sample error traces; probabilistically sample everything else. This is impossible with head-based sampling (where the first service makes the decision before knowing how the trace ends).
Data transformation: Rename attributes, redact PII, add resource attributes. Clean up telemetry before it reaches your backend.
Fan-out: Send the same telemetry to multiple backends simultaneously. Run Jaeger for local debugging and Honeycomb for production analysis.
OTel Operator for Kubernetes
In Kubernetes, the OTel Operator automates instrumentation injection via mutating webhooks:
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  exporter:
    endpoint: http://otel-collector:4317
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: AlwaysOn
  python:
    env:
      - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED
        value: "true"
  java:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-python-app
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-python: "true"  # ← That's it
The operator injects the OTel SDK and auto-instrumentation as an init container. Zero code changes. Works for Python, Java, Node.js, .NET, and Go.
What OTel Still Doesn’t Solve
The Cardinality Problem
OTel doesn’t stop you from creating metrics with unbounded cardinality. Adding user_id as an attribute to a high-traffic metric will destroy your Prometheus. OTel gives you the power to do this; it doesn’t protect you from it.
Attribute cardinality budget: keep high-cardinality data (user IDs, order IDs) in traces, not metrics. Metrics should use low-cardinality attributes (status codes, service names, regions).
Context Propagation Gaps
Auto-instrumentation handles standard HTTP and gRPC. It doesn’t handle:
Custom async message queues with proprietary protocols
Background jobs triggered by cron
External vendor SDKs that don’t propagate OTel context
You’ll need manual instrumentation for these. Budget time for it.
Vendor Lock-In Isn’t Dead
OTel standardizes data collection and transmission, not data analysis. The value you get from your observability platform (alerting, dashboards, ML-based anomaly detection) is still vendor-specific. Migrating analysis tools is still painful — just less painful than migrating instrumentation code.
Recommended Stack in 2026
For teams building new systems:
Component
      Recommendation
    
SDK
      OTel auto-instrumentation + manual for custom spans
    
Collector
      OTel Collector (agent mode on each node, gateway for processing)
    
Traces
      Jaeger (self-hosted) or Honeycomb (managed)
    
Metrics
      Prometheus + Grafana
    
Logs
      Loki (self-hosted) or your cloud provider’s managed logging
    
Unified
      Grafana Cloud (all three in one managed platform)
    
For teams already on Datadog or New Relic: configure your OTel Collector to export to them via OTLP. You get vendor-portable instrumentation with your existing backend.
Getting Started
Deploy the OTel Collector alongside your application
Enable auto-instrumentation for your language
Verify traces in a local Jaeger instance
Add custom spans for business-critical operations
Add semantic attributes using OTel conventions
Configure tail sampling once you understand your traffic pattern
Add the OTel Operator to Kubernetes for cluster-wide coverage
The entry cost is genuinely lower than it was two years ago. The auto-instrumentation ecosystem has matured; the Collector is stable; the Kubernetes Operator handles most of the plumbing. If you’re starting a new service today, there’s no reason not to instrument with OTel from day one.
Observability is no longer a nice-to-have. With distributed systems, it’s your primary debugging tool. OTel is the best foundation for it that exists.

OpenTelemetry in 2026: Observability Has Finally Grown Up

댓글