Cap 1: Introducción a OpenTelemetry

El problema antes de OpenTelemetry

En 2018, si querías observabilidad en tu aplicación, tenías dos opciones:

1. Instrumentar para un vendor específico — instalar el SDK de Datadog, New Relic o Dynatrace. Migrar de vendor significaba re-instrumentar toda la aplicación.
2. OpenTracing o OpenCensus — dos estándares incompatibles que convivían sin coordinación. Las librerías no podían soportar ambos.

El resultado: vendor lock-in a nivel de instrumentación. Cambiar de proveedor de observabilidad costaba meses.

La solución: OpenTelemetry

En 2019, el CNCF fusionó OpenTracing y OpenCensus en OpenTelemetry. La propuesta de valor:

“Instrumentas una vez con OTel. Exportas a donde quieras.”

flowchart LR
    subgraph Antes
        A1[App] --> V1[Datadog SDK]
        A2[App] --> V2[New Relic SDK]
        A3[App] --> V3[Jaeger SDK]
    end

    subgraph Ahora
        B[App] --> OTel[OTel SDK]
        OTel --> D[Datadog]
        OTel --> NR[New Relic]
        OTel --> JA[Jaeger]
        OTel --> PR[Prometheus]
        OTel --> HN[Honeycomb]
    end

Los tres pilares de la observabilidad

OTel unifica tres tipos de señales bajo un mismo SDK y protocolo:

Traces (Trazas)

Registran el flujo de una request a través del sistema. Responden: “¿Qué pasó exactamente cuando el usuario hizo click en comprar?”

gantt
    title Trace: POST /checkout
    dateFormat x
    axisFormat %Lms

    section API Gateway
    Autenticar token    :0, 5
    Enrutar request     :5, 8

    section Order Service
    Validar carrito     :8, 15
    Llamar a Payment    :15, 45

    section Payment Service
    Verificar tarjeta   :15, 40
    Crear transacción   :40, 45

    section Order Service
    Guardar en DB       :45, 52
    Publicar evento     :52, 58

Metrics (Métricas)

Mediciones numéricas agregadas a lo largo del tiempo. Responden: “¿Cuántas requests por segundo recibimos? ¿Cuál es el percentil 99 de latencia?”

http.server.request.duration{method="POST", route="/checkout", status=200}
  → p50: 45ms, p95: 120ms, p99: 280ms

Logs (Registros)

Eventos discretos con contexto. Responden: “¿Qué ocurrió exactamente en el momento X?”

{
  "timestamp": "2026-04-02T10:00:00Z",
  "severity": "ERROR",
  "body": "Payment declined",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

La diferencia con logs tradicionales: están correlacionados con el trace vía trace_id y span_id.

Arquitectura de OTel

OTel tiene tres capas distintas:

graph TD
    subgraph L1[Capa 1: API]
        API[Interfaces y tipos\nstable, sin dependencias]
    end

    subgraph L2[Capa 2: SDK]
        SDK[Implementación\nconfigurable]
    end

    subgraph L3[Capa 3: Exporters]
        EXP[OTLP / Prometheus\nJaeger / Zipkin / Console]
    end

    L1 --> L2 --> L3

API — Define las interfaces (Tracer, Meter, Logger). Las librerías instrumentan contra la API. Si no hay SDK configurado, las llamadas son no-ops.

SDK — Implementación real. Gestiona sampling, batching, context propagation. Configurable y reemplazable.

Exporters — Convierten los datos al formato del backend destino.

Esta separación permite que una librería de terceros (Express, Django, grpc) use la API de OTel sin forzarte a usar ningún SDK en particular.

El protocolo: OTLP

OpenTelemetry Protocol (OTLP) es el formato de wire nativo. Soporta tres transportes:

Transporte	Puerto default	Cuándo usar
gRPC	4317	Producción, baja latencia, streaming
HTTP/Protobuf	4318	Proxies, firewalls, compatibilidad
HTTP/JSON	4318	Debugging, integrations simples

Prácticamente todos los backends modernos aceptan OTLP directamente.

Componentes del ecosistema

mindmap
  root[OTel Ecosystem]
    SDK
      Python
      Java
      Go
      Node.js
      .NET
      Rust
    Collector
      Receivers
      Processors
      Exporters
    Instrumentación
      Auto-instrumentación
      Manual
      Librerías contrib
    Protocolo
      OTLP/gRPC
      OTLP/HTTP
    Convenciones semánticas
      HTTP
      DB
      mensajería
      cloud

Estado de madurez por signal

Signal	API	SDK	Estado
Traces	Estable	Estable	Listo para producción
Metrics	Estable	Estable	Listo para producción
Logs	Estable	Stable (mayoría de lenguajes)	Listo para producción
Profiles	Desarrollo	Desarrollo	Experimental

Quién usa OTel

OTel ya es el estándar de facto. Lo usan:

• Herramientas de desarrollo: Claude Code, GitHub Copilot, VS Code
• Cloud providers: AWS, GCP, Azure — todos tienen exporters nativos
• Frameworks: Spring, Django, Express, Rails — auto-instrumentación incluida
• Backends: Datadog, New Relic, Dynatrace, Honeycomb — todos aceptan OTLP