OpenTelemetry tiene muchas partes, y la mayor parte de la confusión viene de mezclarlas. Esta guía las separa: qué se ejecuta dentro de tu aplicación, qué se ejecuta a su lado y dónde se configura cada una. Una vez que el mapa está claro, el resto de la serie consiste sobre todo en rellenar YAML.

El problema que resuelve

Antes de OpenTelemetry, cada proveedor de monitorización distribuía su propio agente y su propio formato de datos. Cambiar de proveedor significaba volver a instrumentar cada servicio, y ejecutar dos herramientas significaba ejecutar dos agentes. OpenTelemetry separa las dos preocupaciones: la instrumentación produce datos estándar una vez, y un pipeline decide adónde van.

Las piezas

Pieza	Qué es	Dónde se ejecuta
API	Las interfaces que llama el código de instrumentación (iniciar un span, registrar una métrica)	En tu aplicación
SDK	La implementación detrás de la API: muestreo, batching, exportación	En tu aplicación
Instrumentación	Código que crea telemetría para librerías (HTTP, bases de datos)	En tu aplicación, mediante librerías o un agente sin código
OTLP	El protocolo de transmisión de telemetría, sobre gRPC o HTTP	Entre componentes
Collector	Un servicio independiente que recibe, procesa y exporta telemetría	Junto a las aplicaciones, por nodo o como gateway central
Convenciones semánticas	Nombres estándar para atributos, como http.request.method	En todas partes

Las aplicaciones pueden exportar directamente a un backend, pero poner un Collector en medio es la recomendación habitual, porque te permite cambiar el procesamiento y los destinos sin volver a desplegar las aplicaciones.

Tres capas de configuración

1. El SDK de la aplicación, configurado con variables de entorno OTEL_* o, cada vez más, un archivo YAML declarativo al que apunta OTEL_CONFIG_FILE. Controla el nombre del servicio, los atributos de recurso, el sampler y adónde exportar.
2. El Collector, configurado con un archivo YAML. Controla qué se recibe, cómo se transforman los datos y adónde van.
3. El pegamento de la plataforma: archivos de Docker Compose, valores de Helm o recursos de Kubernetes del OpenTelemetry Operator, que despliegan el Collector e inyectan configuración en las aplicaciones.

Todo lo de estas capas es texto, así que puede vivir en Git.

El flujo de datos en una imagen

┌────────────┐  OTLP   ┌─────────────────────────────┐        ┌───────────┐
│ App + SDK  │────────▶│ Collector                   │───────▶│ Trazas    │
│ (variables │ 4317/   │ receivers → processors →    │───────▶│ Métricas  │
│  de entorno│ 4318    │ exporters (config.yaml)     │───────▶│ Logs      │
│  o YAML)   │         │                             │        │           │
└────────────┘         └─────────────────────────────┘        └───────────┘

Las señales de un vistazo

• Las trazas registran el recorrido de una petición por los servicios como spans. Responden a “¿dónde se fue el tiempo?”
• Las métricas son mediciones numéricas a lo largo del tiempo, como recuentos de peticiones e histogramas de latencia. Responden a “¿cuál es la tendencia del sistema?”
• Los logs son registros con marca de tiempo. OpenTelemetry puede correlacionarlos con trazas, de modo que una línea de log enlaza con el span que la produjo.

Cada señal tiene su propio pipeline en el Collector y su propio provider en un SDK.

Estabilidad: lee antes de adoptar

OpenTelemetry es grande y sus partes maduran a velocidades distintas. El protocolo OTLP y las APIs de trazas y métricas son estables. Los componentes del Collector tienen sus propios niveles de estabilidad, y muchos componentes de contrib siguen en beta o alpha. El esquema de configuración declarativa del SDK alcanzó una versión estable en 2026, pero las implementaciones de los SDK se están poniendo al día de forma desigual, con Java y algunos otros a la cabeza. Cuando elijas un componente o una función, comprueba su estabilidad en la documentación y fija versiones.

Un camino sugerido por esta serie

1. Ejecuta un Collector y envíale datos (Docker Compose).
2. Aprende el modelo de configuración del Collector.
3. Configura los SDK con variables de entorno y, donde se soporte, un archivo declarativo.
4. Añade instrumentación sin código a una aplicación.
5. Prepara el Collector para producción: batching, límites de memoria, reintentos, muestreo.
6. Despliégalo en Kubernetes con Helm o el Operator.
7. Recopila logs y métricas de infraestructura, envía a backends de forma segura y soluciona problemas.

Como referencia, consulta la documentación de OpenTelemetry.