Los usuarios de software autoalojado o productos SaaS solicitan cada vez con más frecuencia enviar registros, trazas y métricas a una pila de observabilidad de su elección, ya sea para cumplir con regulaciones, controlar costos o centralizar datos. Cuando un producto los encierra en sus paneles integrados o limita las exportaciones a proveedores específicos, genera fricciones innecesarias. Un enfoque OTel‑native evita esto diseñando el producto para enviar telemetría a cualquier endpoint compatible con OpenTelemetry a través del protocolo estándar OpenTelemetry (OTLP), brindando a los usuarios la libertad de seleccionar su backend preferido sin necesidad de adaptadores personalizados para cada sistema.
Esta imagen respalda la introducción del enfoque OTel‑native, mostrando cómo OTLP permite a los usuarios seleccionar cualquier backend de observabilidad sin necesidad de adaptadores personalizados.
Una historia sólida de exportación OTel‑native se basa en cuatro propiedades clave: neutralidad de proveedores (los usuarios pueden apuntar a cualquier colector o backend compatible con OTel), ausencia de desarrollo personalizado profundo (los usuarios integran mediante SDKs estándar de OTel y OTLP), preservación de contexto rico (metadatos, marcas de tiempo y correlaciones de trazas/spans se mantienen), y cumplimiento de las Convenciones Semánticas para que los datos permanezcan estandarizados e interpretables entre backends. OpenTelemetry define cuatro tipos de señales: registros (registros de eventos y de aplicación), trazas (trazas distribuidas y spans), métricas (contadores, indicadores, histogramas) y perfiles (muestras de uso de recursos, actualmente en alfa público). Según quién ejecuta el sistema que produce la telemetría, la implementación varía: para software autoalojado, el producto se instrumenta con OpenTelemetry y expone banderas de configuración para un endpoint OTLP (por ejemplo, mediante variables de entorno o un archivo de configuración), como se observa en Kuma y Keycloak; para plataformas en la nube, el proveedor ofrece una función como «Telemetry Drains» o «Observability Destinations» que recopila telemetría de las cargas de trabajo de los usuarios y servicios de primera parte y la reenvía a un endpoint OTLP definido por el cliente, ejemplificado por Cloudflare Workers y Heroku.
La exportación basada en push mediante OTLP es preferible frente a las APIs tradicionales de sondeo porque entrega datos casi en tiempo real, evita imponer cargas operativas a los usuarios para crear y mantener canalizaciones de sondeo, y preserva automáticamente las relaciones contextuales, como vincular registros de logs con IDs de trace superiores. Aunque este modelo funciona bien para registros, trazas y métricas, algunas implementaciones aún presentan lagunas: Cloudflare Workers aún no admite la exportación de métricas, y la exportación de logs de Keycloak sigue en vista preliminar y está desactivada por defecto. Estas limitaciones demuestran que lograr un soporte completo OTel‑native para todas las señales requiere trabajo continuo, pero el patrón esencial brinda una base a prueba de futuro y neutral para proveedores que funciona con cualquier pila de observabilidad que los usuarios elijan.