OpenTelemetry puede separar la instrumentación de las aplicaciones del backend de monitorización. Eso reduce un tipo de dependencia de un proveedor—pero también da a tu equipo un canal (pipeline) de telemetría que operar.
Lo costoso de cambiar de herramienta de monitorización suele estar dentro de las aplicaciones
Una organización quiere cambiar de plataforma de observabilidad. El nuevo backend puede almacenar trazas, métricas y registros (logs), pero decenas de servicios usan los agentes, las bibliotecas, los nombres de campo y los exportadores del proveedor anterior.
Lo difícil no es crear una cuenta nueva. Es cambiar el código de las aplicaciones, la configuración de despliegue y las convenciones operativas en cada uno de los servicios.
OpenTelemetry actúa precisamente sobre esa frontera. Ofrece a las aplicaciones una forma neutral respecto al proveedor de generar, describir, recopilar y exportar telemetría. Las aplicaciones pueden emitir señales estándar hacia un OpenTelemetry Collector, y el Collector puede procesar esas señales y enrutarlas a uno o varios backends.
Por eso importa ser dueño del canal de telemetría: la decisión sobre adónde van los datos puede salir de cada aplicación y pasar a una capa de plataforma controlada.
Pero OpenTelemetry no proporciona una plataforma de observabilidad completa. No almacena los datos, no ejecuta tus consultas, no construye paneles ni gestiona alertas. Esas responsabilidades siguen correspondiendo a otros sistemas.
Qué estandariza realmente OpenTelemetry
La telemetría es la evidencia que produce un sistema en ejecución:
- las trazas siguen una solicitud a través de los servicios;
- las métricas miden valores a lo largo del tiempo;
- los registros anotan eventos y detalles;
- los perfiles, todavía menos maduros en OpenTelemetry, describen en qué gastan recursos los programas.
OpenTelemetry proporciona API y SDK para crear estos datos, convenciones semánticas para nombrar la información común, el OpenTelemetry Protocol (OTLP) para transportarlos y un Collector para recibirlos, procesarlos y exportarlos.
El Collector funciona como un canal programable. Puede agrupar datos en lotes, añadir información de recursos, eliminar campos sensibles, muestrear trazas, traducir formatos y enviar señales distintas a destinos distintos.
Qué significa «ser dueño del canal»
Ser dueño no significa necesariamente operar tú mismo cada componente. Significa conservar el control sobre el contrato entre las aplicaciones y los proveedores de observabilidad.
| Capa | Con un diseño centrado en OpenTelemetry | Nivel de portabilidad |
|---|---|---|
| Instrumentación de aplicaciones | API y SDK de OpenTelemetry e instrumentación automática | Relativamente alto |
| Nomenclatura de señales | Convenciones semánticas estándar más reglas de la organización | Alto si se siguen las convenciones |
| Transporte | OTLP u otros formatos abiertos compatibles | Relativamente alto |
| Procesamiento y enrutamiento | Configuración y procesadores del Collector | Portable hasta que se introducen componentes específicos de un proveedor |
| Almacenamiento | Backend de código abierto o comercial elegido | Específico del backend |
| Lenguaje de consulta | Definido por el backend | Normalmente bajo |
| Paneles y alertas | Construidos en el backend o en otra capa de visualización | A menudo bajo |
| Retención y control de costos | Decisiones de backend y de arquitectura | Específico del backend |
Por tanto, OpenTelemetry reduce la dependencia de la instrumentación. No garantiza que los paneles, las consultas, las alertas o los datos históricos puedan trasladarse sin esfuerzo.
Aun así, tiene valor. Sustituir paneles es incómodo; volver a instrumentar cientos de servicios manteniendo estable la producción suele ser mucho más difícil.
El Collector crea un punto de control útil
Sin un Collector, cada aplicación puede enviar telemetría directamente a un backend. Eso puede ser aceptable para un experimento pequeño. A gran escala, dispersa por toda la infraestructura la configuración de endpoints, las credenciales, las reglas de muestreo y los exportadores del proveedor.
Un Collector ofrece un único lugar para:
- cambiar de destino sin recompilar cada aplicación;
- agrupar en lotes y comprimir los datos antes de exportarlos;
- eliminar secretos o información personal;
- enriquecer las señales con metadatos de entorno y de responsable;
- muestrear trazas de gran volumen;
- enviar datos de seguridad o de fiabilidad a sistemas separados;
- mantener una exportación doble temporal durante una migración.
También se convierte en infraestructura de producción. Si el Collector está sobrecargado, mal configurado o no disponible, la telemetría puede retrasarse o perderse justo cuando un incidente la hace más valiosa.
Los estándares abiertos no eliminan el trabajo operativo
El argumento comercial más fuerte de OpenTelemetry es librarse de la dependencia de un proveedor. La verdad incómoda es que la portabilidad hay que diseñarla y mantenerla.
Los equipos pueden volver a crear dependencia si:
- usan una distribución del Collector específica de un proveedor sin entender lo que añade;
- dependen en gran medida de procesadores o exportadores propietarios;
- nombran los atributos de forma incoherente entre equipos;
- vuelcan todo el conocimiento operativo en el lenguaje de consulta de un solo backend;
- no conservan ninguna ruta probada hacia un segundo destino;
- dan por hecho que el SDK de cada lenguaje y cada señal tienen la misma madurez.
El propio Collector necesita planificación de capacidad, actualizaciones, una configuración segura y monitorización. Los entornos más grandes suelen usar collectors cerca de las cargas de trabajo y una capa de gateway para el procesamiento y la exportación centralizados. Un único Collector global puede convertirse en un cuello de botella y en un dominio de fallo.
OpenTelemetry y Prometheus no son competidores
Prometheus se usa ampliamente para recopilar, almacenar y consultar métricas de series temporales y para alimentar alertas. OpenTelemetry cubre una capa más amplia de instrumentación y transporte que abarca trazas, métricas y registros.
Una organización puede seguir usando Prometheus mientras adopta bibliotecas, convenciones semánticas y Collectors de OpenTelemetry. Las dos tecnologías pueden complementarse. Sustituir un despliegue de Prometheus que funciona no es un requisito previo para orientarse a OpenTelemetry.
La mejor pregunta es dónde la estandarización elimina trabajo duplicado. Para un equipo, puede ser el trazado distribuido. Para otro, unos metadatos de servicio coherentes en varias nubes.
Cuándo compensa la capa adicional de OpenTelemetry
Aporta más valor cuando:
- muchos servicios usan lenguajes o frameworks distintos;
- varios equipos necesitan convenciones de telemetría coherentes;
- las cargas de trabajo se reparten entre nubes, clústeres o sistemas locales (on-premises);
- la organización quiere tener la opción de enrutar datos a más de un backend;
- el filtrado o la ocultación de datos debe hacerse antes de la exportación;
- el costo de la telemetría exige controles centralizados de muestreo y enrutamiento;
- cambiar de backend obligaría, de otro modo, a modificar las aplicaciones.
Puede ser innecesario al principio cuando una sola aplicación pequeña usa un único backend, la integración nativa del proveedor es suficiente y nadie está preparado para operar otro componente. Añadir un Collector porque está de moda crea infraestructura sin resolver ningún problema actual.
Una secuencia práctica de adopción
1. Elige un recorrido de servicio
Empieza por una solicitud que atraviese unos cuantos servicios importantes. Define qué debería poder averiguar un operador cuando esa solicitud sea lenta o falle.
2. Establece la nomenclatura y los responsables
Usa las convenciones semánticas de OpenTelemetry donde sean aplicables. Añade un conjunto pequeño y gobernado de atributos de la organización, como el responsable del servicio, el entorno y la versión de despliegue. Evita valores sin límite o sensibles.
3. Instrumenta antes de centralizarlo todo
Genera trazas y métricas útiles en un grupo de servicios. Confirma que el contexto se propaga a través de las fronteras. No instales una gran flota de Collectors antes de comprobar que los datos emitidos responden a preguntas operativas.
4. Introduce el Collector de forma deliberada
Úsalo para resolver una necesidad real: ocultación de datos, agrupación en lotes, enrutamiento, enriquecimiento o independencia del backend. Supervisa su cola, los datos rechazados, los fallos de exportación, la memoria y los spans descartados.
5. Prueba la portabilidad
Exporta temporalmente un conjunto controlado de señales a un segundo destino compatible. Anota qué atributos, consultas, paneles y alertas no se trasladan. Una portabilidad que nunca se ha probado no es más que una suposición.
¿Conocer, usar o dominar?
Conocer: los desarrolladores deberían entender las trazas, las métricas y los registros, y saber que OpenTelemetry es un marco de instrumentación y transporte—no un backend de monitorización.
Usar: los desarrolladores, los SRE y los ingenieros de plataforma deberían instrumentar servicios, propagar el contexto, configurar collectors e investigar la telemetría que falta o que sobra.
Dominar: los responsables de la plataforma de observabilidad deberían diseñar la topología de collectors, la gobernanza semántica, el muestreo, la ocultación de datos, el enrutamiento a varios backends, la capacidad y la gestión de fallos.
¿Qué deberías hacer a continuación?
Elige un servicio importante y responde a tres preguntas:
- ¿Su instrumentación está ligada directamente a un proveedor?
- ¿Podría cambiar el destino sin volver a desplegar la aplicación?
- Si el canal de telemetría fallara, ¿alguien lo sabría antes de un incidente?
Si la primera respuesta es sí y las dos siguientes son no, OpenTelemetry puede resolver un problema real de arquitectura. Si no eres capaz de identificar ese problema, no despliegues todavía otra capa de plataforma.
Ser dueño del canal de telemetría no consiste en evitar a todos los proveedores. Consiste en decidir dónde es aceptable depender de un proveedor—y en impedir que esa dependencia se extienda a todas las aplicaciones sin que nadie lo vea.
Referencias y lecturas adicionales
- What is OpenTelemetry? — proyecto OpenTelemetry. Define su papel en la generación, recopilación y exportación de telemetría y aclara que no es un backend. Consultado en septiembre de 2026.
- OpenTelemetry documentation — proyecto OpenTelemetry. Documentación actual sobre conceptos, SDK por lenguaje, el Collector y orientaciones de despliegue. Consultado en septiembre de 2026.
- OpenTelemetry Collector deployment — proyecto OpenTelemetry. Orientaciones para desplegar collectors junto a las cargas de trabajo y como gateways. Consultado en septiembre de 2026.
- OpenTelemetry Collector anti-patterns — proyecto OpenTelemetry, 1 de marzo de 2024. Advertencias prácticas sobre topología, monitorización, distribuciones y actualizaciones; el propio artículo recomienda volver a comprobar los detalles más antiguos. Consultado en septiembre de 2026.
- CNCF announces OpenTelemetry graduation — CNCF, 21 de mayo de 2026. Recoge la graduación del proyecto y la evaluación de su preparación para producción. Consultado en septiembre de 2026.