<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=1200&amp;auto=format&amp;fit=crop"><h2 id="opentelemetry-in-2026-the-observability-standard-that-finally-won">OpenTelemetry in 2026: The Observability Standard That Finally Won</h2>In 2020, the observability space was fragmented: Jaeger for tracing, Prometheus for metrics, and various log shippers that didn’t talk to each other well. Every vendor had proprietary SDKs, and migrating meant rewriting instrumentation. In 2026, that story has fundamentally changed. OpenTelemetry (OTel) has won.Not “won” in the sense that nothing else exists—but won in the sense that it’s the default, the expected baseline, the thing you get for free when you spin up a Kubernetes cluster or start a new cloud project. This post covers what that win looks like in practice and how to get the most out of OTel in 2026.<img src="https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=900&amp;auto=format&amp;fit=crop" alt="Monitoring dashboard with metrics and traces"> Photo by Luke Chesser on Unsplash<h2 id="the-short-history-of-why-otel-won">The Short History of Why OTel Won</h2>OpenTelemetry was born from the merger of OpenTracing and OpenCensus in 2019. The CNCF project made a controversial bet: define a single open standard for distributed telemetry (traces, metrics, logs) that every vendor would adopt, rather than fragment the ecosystem.It worked because vendors had a collective action problem: individual proprietary SDKs created lock-in, but that lock-in was increasingly a sales blocker rather than a moat. When Datadog, Honeycomb, Grafana, New Relic, Dynatrace, and all three major clouds committed to OTel as the primary ingestion format, the ecosystem tipped.By 2025, the OTLP (OpenTelemetry Protocol) was the default telemetry protocol—the way HTTP became the default for web APIs. In 2026, opting out of OTel requires a deliberate decision.<h2 id="the-three-pillars-status-in-2026">The Three Pillars: Status in 2026</h2><h3 id="tracing-ga-since-2021">Tracing (GA since 2021)</h3>Distributed tracing was OTel’s first production-ready signal. The model is mature:<div><pre><code>from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(
 BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
)
trace.set_tracer_provider(provider)

tracer = trace.get_tracer("my-service")

@app.get("/orders/{order_id}")
async def get_order(order_id: str):
 with tracer.start_as_current_span("get_order") as span:
 span.set_attribute("order.id", order_id)
 
 # Auto-instrumentation handles downstream HTTP/DB calls
 order = await db.fetch_order(order_id)
 
 span.set_attribute("order.status", order.status)
 return order
</code></pre></div>Auto-instrumentation libraries for Python, Java, Node.js, Go, and .NET handle the boilerplate—you get traces from HTTP clients, database drivers, gRPC, Redis, and more without manual span creation.<h3 id="metrics-ga-since-2023-mature-in-2026">Metrics (GA since 2023, mature in 2026)</h3>OTel metrics replaced the need for per-vendor metrics SDKs. The semantic conventions namespace (<code>http.server.request.duration</code>, <code>db.client.operation.duration</code>, etc.) means metrics from different libraries are comparable across services and organizations.<div><pre><code>import (
 "go.opentelemetry.io/otel"
 "go.opentelemetry.io/otel/metric"
)

meter := otel.GetMeterProvider().Meter("order-service")

orderCounter, _ := meter.Int64Counter(
 "orders.created",
 metric.WithDescription("Total orders created"),
 metric.WithUnit("{order}"),
)

requestDuration, _ := meter.Float64Histogram(
 "http.server.request.duration", // OTel semantic convention name
 metric.WithDescription("HTTP request duration"),
 metric.WithUnit("s"),
)
</code></pre></div>The big win: OTel metrics work with both push (OTLP to Prometheus/Grafana Mimir) and pull (Prometheus scrape endpoint) models. You instrument once and route to any backend.<h3 id="logs-ga-since-2024-widely-adopted-in-2026">Logs (GA since 2024, widely adopted in 2026)</h3>Logs were the last signal to reach stability, but the bridge between trace context and logs is now the killer feature:<div><pre><code>import logging
from opentelemetry._logs import set_logger_provider
from opentelemetry.sdk._logs import LoggerProvider
from opentelemetry.sdk._logs.export import BatchLogRecordProcessor
from opentelemetry.exporter.otlp.proto.grpc._log_exporter import OTLPLogExporter

# Logs are automatically tagged with trace_id and span_id
logger = logging.getLogger("order-service")

@app.post("/orders")
async def create_order(order: OrderRequest):
 with tracer.start_as_current_span("create_order"):
 logger.info("Creating order", extra={"customer_id": order.customer_id})
 # This log line will have trace_id and span_id automatically injected
 result = await process_order(order)
 logger.info("Order created", extra={"order_id": result.id, "status": result.status})
 return result
</code></pre></div>The result: in Grafana or Datadog, you can click a trace span and immediately see the logs emitted during that span’s execution—across all services, without any manual log correlation.<h2 id="the-otel-collector-the-backbone-of-modern-observability">The OTel Collector: The Backbone of Modern Observability</h2>The OTel Collector is the infrastructure component that makes OTel practical at scale. It’s a standalone daemon that:<ul><li>Receives telemetry (OTLP, Jaeger, Prometheus, Zipkin, Kafka, etc.)</li><li>Processes it (filtering, sampling, enrichment, transformation)</li><li>Exports it to any backend (Jaeger, Zipkin, Prometheus, Datadog, Honeycomb, Elasticsearch)</li></ul><div><pre><code># otel-collector-config.yaml
receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:
 timeout: 5s
 send_batch_size: 1000
 
 # Tail sampling: keep all error traces, sample 10% of success traces
 tail_sampling:
 decision_wait: 10s
 policies:
 - name: errors
 type: status_code
 status_code: {status_codes: [ERROR]}
 - name: probabilistic
 type: probabilistic
 probabilistic: {sampling_percentage: 10}
 
 # Enrich with Kubernetes pod metadata
 k8sattributes:
 extract:
 metadata:
 - k8s.pod.name
 - k8s.namespace.name
 - k8s.deployment.name

exporters:
 otlp/grafana:
 endpoint: tempo.monitoring:4317
 prometheusremotewrite:
 endpoint: http://mimir.monitoring/api/v1/push
 elasticsearch:
 endpoints: [https://es.monitoring:9200]

service:
 pipelines:
 traces:
 receivers: [otlp]
 processors: [k8sattributes, tail_sampling, batch]
 exporters: [otlp/grafana]
 metrics:
 receivers: [otlp]
 processors: [batch]
 exporters: [prometheusremotewrite]
 logs:
 receivers: [otlp]
 processors: [k8sattributes, batch]
 exporters: [elasticsearch]
</code></pre></div>The collector acts as a vendor-neutral telemetry router. Change your backend from Datadog to Grafana? Update the exporter. Add a new backend for a specific team? Add an exporter. No application code changes.<h2 id="new-in-2026-profiles-and-events">New in 2026: Profiles and Events</h2>OTel is expanding beyond the three original pillars:Profiling (experimental → beta in 2026): Continuous profiling data (CPU flame graphs, memory allocation) with trace correlation. Grafana Pyroscope and Polar Signals CloudProfiler are the early implementers.Events (semantic specification, 2025): Structured event data distinct from logs—think “OrderCreated” domain events with structured fields, not free-text log lines. Pairs well with event-driven architectures.<h2 id="otel--ai-the-gen_ai-semantic-conventions">OTel + AI: The gen_ai Semantic Conventions</h2>The fastest-evolving part of OTel in 2026 is the <code>gen_ai.*</code> semantic convention namespace, standardizing telemetry for LLM interactions:<div><pre><code>with tracer.start_as_current_span("llm.chat") as span:
 span.set_attribute("gen_ai.system", "anthropic")
 span.set_attribute("gen_ai.request.model", "claude-sonnet-4")
 span.set_attribute("gen_ai.request.max_tokens", 4096)
 
 response = client.messages.create(...)
 
 span.set_attribute("gen_ai.response.model", response.model)
 span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
 span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
 span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
</code></pre></div>This standardization means LLM observability platforms (Langfuse, Arize Phoenix, Datadog LLM Observability) can all consume the same data, and you can correlate LLM performance with your service-level traces.<h2 id="the-observability-backend-landscape">The Observability Backend Landscape</h2>OTel decouples instrumentation from storage. The major stacks in 2026:Self-hosted (Grafana Stack):<ul><li>Grafana Alloy (OTel-native collector + agent)</li><li>Grafana Tempo (distributed traces)</li><li>Grafana Mimir (metrics)</li><li>Grafana Loki (logs)</li><li>Cost: Free software, significant operational investment</li></ul>Managed OSS:<ul><li>Signoz (traces + metrics + logs in one open-source platform)</li><li>Uptrace (self-hosted, Clickhouse-backed)</li></ul>Commercial:<ul><li>Datadog, New Relic, Honeycomb, Dynatrace—all accept OTLP natively</li><li>AWS CloudWatch, GCP Cloud Trace, Azure Monitor—cloud-native with OTel support</li></ul>The trend: teams with strong platform engineering capacity prefer the Grafana stack for cost control. Teams without that capacity choose commercial vendors—but they all accept OTel, so migration is possible.<h2 id="getting-started-in-2026">Getting Started in 2026</h2>The fastest way to instrument a new service:<div><pre><code># Python: zero-code auto-instrumentation
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap --action=install

OTEL_SERVICE_NAME=my-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 \
opentelemetry-instrument python app.py
</code></pre></div>For Node.js:<div><pre><code>npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node

# Set env vars and Node starts instrumented
OTEL_SERVICE_NAME=my-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 \
node --require @opentelemetry/auto-instrumentations-node/register app.js
</code></pre></div>Zero application code changes, immediate traces and metrics.<h2 id="conclusion">Conclusion</h2>OpenTelemetry has achieved what few open standards manage: genuine industry consensus. The fragmentation that made observability frustrating—different SDKs, incompatible data formats, vendor lock-in—has largely been resolved.In 2026, the conversation has shifted from “should we adopt OTel?” to “how do we get more value from our telemetry data?” That’s a healthy sign of a mature ecosystem. Whether you’re running on Kubernetes with a full Grafana stack or using a commercial APM tool, OTel is the foundation—and understanding it well is a core skill for any engineer working on distributed systems.<hr>Resources: <a href="https://opentelemetry.io/">OpenTelemetry.io</a>, <a href="https://opentelemetry.io/docs/collector/">OTel Collector</a>, <a href="https://grafana.com/docs/grafana/latest/datasources/opentelemetry/">Grafana OTel integration</a>, <a href="https://opentelemetry.io/docs/specs/semconv/gen-ai/">gen_ai semantic conventions</a> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

OpenTelemetry in 2026: The Observability Standard That Finally Won
In 2020, the observability space was fragmented: Jaeger for tracing, Prometheus for metrics, and various log shippers that didn’t talk to each other well. Every vendor had proprietary SDKs, and migrating meant rewriting instrumentation. In 2026, that story has fundamentally changed. OpenTelemetry (OTel) has won.
Not “won” in the sense that nothing else exists—but won in the sense that it’s the default, the expected baseline, the thing you get for free when you spin up a Kubernetes cluster or start a new cloud project. This post covers what that win looks like in practice and how to get the most out of OTel in 2026.
Photo by Luke Chesser on Unsplash
The Short History of Why OTel Won
OpenTelemetry was born from the merger of OpenTracing and OpenCensus in 2019. The CNCF project made a controversial bet: define a single open standard for distributed telemetry (traces, metrics, logs) that every vendor would adopt, rather than fragment the ecosystem.
It worked because vendors had a collective action problem: individual proprietary SDKs created lock-in, but that lock-in was increasingly a sales blocker rather than a moat. When Datadog, Honeycomb, Grafana, New Relic, Dynatrace, and all three major clouds committed to OTel as the primary ingestion format, the ecosystem tipped.
By 2025, the OTLP (OpenTelemetry Protocol) was the default telemetry protocol—the way HTTP became the default for web APIs. In 2026, opting out of OTel requires a deliberate decision.
The Three Pillars: Status in 2026
Tracing (GA since 2021)
Distributed tracing was OTel’s first production-ready signal. The model is mature:
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("my-service")
@app.get("/orders/{order_id}")
async def get_order(order_id: str):
    with tracer.start_as_current_span("get_order") as span:
        span.set_attribute("order.id", order_id)
        
        # Auto-instrumentation handles downstream HTTP/DB calls
        order = await db.fetch_order(order_id)
        
        span.set_attribute("order.status", order.status)
        return order
Auto-instrumentation libraries for Python, Java, Node.js, Go, and .NET handle the boilerplate—you get traces from HTTP clients, database drivers, gRPC, Redis, and more without manual span creation.
Metrics (GA since 2023, mature in 2026)
OTel metrics replaced the need for per-vendor metrics SDKs. The semantic conventions namespace (http.server.request.duration, db.client.operation.duration, etc.) means metrics from different libraries are comparable across services and organizations.
import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/metric"
)
meter := otel.GetMeterProvider().Meter("order-service")
orderCounter, _ := meter.Int64Counter(
    "orders.created",
    metric.WithDescription("Total orders created"),
    metric.WithUnit("{order}"),
)
requestDuration, _ := meter.Float64Histogram(
    "http.server.request.duration",  // OTel semantic convention name
    metric.WithDescription("HTTP request duration"),
    metric.WithUnit("s"),
)
The big win: OTel metrics work with both push (OTLP to Prometheus/Grafana Mimir) and pull (Prometheus scrape endpoint) models. You instrument once and route to any backend.
Logs (GA since 2024, widely adopted in 2026)
Logs were the last signal to reach stability, but the bridge between trace context and logs is now the killer feature:
import logging
from opentelemetry._logs import set_logger_provider
from opentelemetry.sdk._logs import LoggerProvider
from opentelemetry.sdk._logs.export import BatchLogRecordProcessor
from opentelemetry.exporter.otlp.proto.grpc._log_exporter import OTLPLogExporter
# Logs are automatically tagged with trace_id and span_id
logger = logging.getLogger("order-service")
@app.post("/orders")
async def create_order(order: OrderRequest):
    with tracer.start_as_current_span("create_order"):
        logger.info("Creating order", extra={"customer_id": order.customer_id})
        # This log line will have trace_id and span_id automatically injected
        result = await process_order(order)
        logger.info("Order created", extra={"order_id": result.id, "status": result.status})
        return result
The result: in Grafana or Datadog, you can click a trace span and immediately see the logs emitted during that span’s execution—across all services, without any manual log correlation.
The OTel Collector: The Backbone of Modern Observability
The OTel Collector is the infrastructure component that makes OTel practical at scale. It’s a standalone daemon that:
Receives telemetry (OTLP, Jaeger, Prometheus, Zipkin, Kafka, etc.)
Processes it (filtering, sampling, enrichment, transformation)
Exports it to any backend (Jaeger, Zipkin, Prometheus, Datadog, Honeycomb, Elasticsearch)
# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
  
  # Tail sampling: keep all error traces, sample 10% of success traces
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: probabilistic
        type: probabilistic
        probabilistic: {sampling_percentage: 10}
  
  # Enrich with Kubernetes pod metadata
  k8sattributes:
    extract:
      metadata:
        - k8s.pod.name
        - k8s.namespace.name
        - k8s.deployment.name
exporters:
  otlp/grafana:
    endpoint: tempo.monitoring:4317
  prometheusremotewrite:
    endpoint: http://mimir.monitoring/api/v1/push
  elasticsearch:
    endpoints: [https://es.monitoring:9200]
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [k8sattributes, tail_sampling, batch]
      exporters: [otlp/grafana]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [k8sattributes, batch]
      exporters: [elasticsearch]
The collector acts as a vendor-neutral telemetry router. Change your backend from Datadog to Grafana? Update the exporter. Add a new backend for a specific team? Add an exporter. No application code changes.
New in 2026: Profiles and Events
OTel is expanding beyond the three original pillars:
Profiling (experimental → beta in 2026): Continuous profiling data (CPU flame graphs, memory allocation) with trace correlation. Grafana Pyroscope and Polar Signals CloudProfiler are the early implementers.
Events (semantic specification, 2025): Structured event data distinct from logs—think “OrderCreated” domain events with structured fields, not free-text log lines. Pairs well with event-driven architectures.
OTel + AI: The gen_ai Semantic Conventions
The fastest-evolving part of OTel in 2026 is the gen_ai.* semantic convention namespace, standardizing telemetry for LLM interactions:
with tracer.start_as_current_span("llm.chat") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4")
    span.set_attribute("gen_ai.request.max_tokens", 4096)
    
    response = client.messages.create(...)
    
    span.set_attribute("gen_ai.response.model", response.model)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
This standardization means LLM observability platforms (Langfuse, Arize Phoenix, Datadog LLM Observability) can all consume the same data, and you can correlate LLM performance with your service-level traces.
The Observability Backend Landscape
OTel decouples instrumentation from storage. The major stacks in 2026:
Self-hosted (Grafana Stack):
Grafana Alloy (OTel-native collector + agent)
Grafana Tempo (distributed traces)
Grafana Mimir (metrics)
Grafana Loki (logs)
Cost: Free software, significant operational investment
Managed OSS:
Signoz (traces + metrics + logs in one open-source platform)
Uptrace (self-hosted, Clickhouse-backed)
Commercial:
Datadog, New Relic, Honeycomb, Dynatrace—all accept OTLP natively
AWS CloudWatch, GCP Cloud Trace, Azure Monitor—cloud-native with OTel support
The trend: teams with strong platform engineering capacity prefer the Grafana stack for cost control. Teams without that capacity choose commercial vendors—but they all accept OTel, so migration is possible.
Getting Started in 2026
The fastest way to instrument a new service:
# Python: zero-code auto-instrumentation
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap --action=install
OTEL_SERVICE_NAME=my-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 \
opentelemetry-instrument python app.py
For Node.js:
npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node
# Set env vars and Node starts instrumented
OTEL_SERVICE_NAME=my-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 \
node --require @opentelemetry/auto-instrumentations-node/register app.js
Zero application code changes, immediate traces and metrics.
Conclusion
OpenTelemetry has achieved what few open standards manage: genuine industry consensus. The fragmentation that made observability frustrating—different SDKs, incompatible data formats, vendor lock-in—has largely been resolved.
In 2026, the conversation has shifted from “should we adopt OTel?” to “how do we get more value from our telemetry data?” That’s a healthy sign of a mature ecosystem. Whether you’re running on Kubernetes with a full Grafana stack or using a commercial APM tool, OTel is the foundation—and understanding it well is a core skill for any engineer working on distributed systems.
Resources: OpenTelemetry.io, OTel Collector, Grafana OTel integration, gen_ai semantic conventions

OpenTelemetry in 2026: The Observability Standard That Finally Won

댓글