OpenTelemetry (OTel) es un framework de código abierto y neutral respecto a proveedores para generar, recopilar y exportar telemetría: trazas, métricas y logs. Define el modelo de datos, el protocolo de transmisión (OTLP), los SDK que usan las aplicaciones y el Collector que recibe y enruta los datos. Como no tiene un backend propio, puedes enviar los mismos datos a Grafana, Prometheus, Jaeger o un proveedor comercial, y cambiar después sin volver a instrumentar tu código.

Casi todo en OpenTelemetry se configura con texto: un archivo YAML para el Collector, variables de entorno para los SDK y, cada vez más, un archivo YAML declarativo también para los SDK. Esta serie se centra en eso, para que tu configuración de telemetría se revise, se versione y sea reproducible como el resto de tu infraestructura.

Cómo funciona

Las aplicaciones se instrumentan con un SDK de OpenTelemetry (o un agente sin código que inyecta uno). El SDK crea spans, métricas y registros de log, y los exporta por OTLP, normalmente a un Collector. El Collector recibe los datos, los procesa (batching, enriquecimiento, filtrado, muestreo) y los exporta a uno o más backends.

App + SDK ──OTLP──▶ Collector (receivers → processors → exporters) ──▶ Backends

Conceptos clave

• Señales — trazas, métricas y logs. Los perfiles están surgiendo como una cuarta señal.
• API y SDK — la API es lo que llama la instrumentación, y el SDK es la implementación que muestrea, agrupa y exporta.
• OTLP — el protocolo de OpenTelemetry, sobre gRPC (puerto 4317) o HTTP (puerto 4318).
• Collector — un binario independiente construido con receivers, processors, exporters, connectors y extensions, conectados en service.pipelines.
• Resource — atributos que describen lo que produce la telemetría, como service.name y deployment.environment.name.
• Convenciones semánticas — nombres de atributos estándar para que los datos de distintos lenguajes y librerías se vean igual.
• Sampling (muestreo) — decidir qué trazas conservar, en el SDK (head sampling) o en el Collector (tail sampling).
• Instrumentación — código manual, librerías o agentes sin código que crean telemetría.

Por qué los equipos adoptan OpenTelemetry

• Sin dependencia de proveedor. Cambia de backend editando la configuración del Collector, no el código de la aplicación.
• Un pipeline para todo. El mismo Collector gestiona trazas, métricas y logs de todos los lenguajes.
• Control en el borde. Filtra, redacta, muestrea y enruta los datos antes de que salgan de tu red.
• Nombres coherentes. Las convenciones semánticas hacen portables los dashboards y las alertas.
• Configuración como código. El YAML del Collector y las variables de entorno de los SDK encajan con herramientas GitOps como Flux y Argo CD.

Primeros pasos

Ejecuta un Collector con un pequeño archivo de configuración, apunta una aplicación a él con unas cuantas variables de entorno OTEL_* y observa los datos en el exporter debug del Collector. Las guías siguientes te llevan desde ahí hasta la instrumentación sin código, el muestreo, Kubernetes y el refuerzo para producción. Se escribieron con versiones recientes del Collector (la serie 0.16x) y el esquema estable de configuración declarativa como referencia; consulta la documentación de OpenTelemetry para las versiones que instales, ya que los componentes del Collector varían en estabilidad.