8 min. de lectura<\/p>\n
OpenTelemetry es en 2026 el est\u00e1ndar unificado de observabilidad al que se suman proveedores cloud, proyectos de c\u00f3digo abierto y herramientas empresariales. Las tres se\u00f1ales principales (trazas, m\u00e9tricas, logs) son estables en todos los SDK de lenguajes mayoritarios. El perfilado continuo ha alcanzado el estado de Release Candidate como cuarto pilar en el primer trimestre de 2026. Para los equipos cloud-native esto significa: la pregunta ya no es si se adoptar\u00e1 OTel, sino con qu\u00e9 rapidez los stacks de observabilidad existentes migrar\u00e1n al est\u00e1ndar com\u00fan.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado<\/span>Platform Engineering 2026: Backstage y los Golden Paths<\/a> \/<\/span> FinOps en el an\u00e1lisis de madurez 2026<\/a><\/p>\n \u00bfQu\u00e9 es OpenTelemetry?<\/strong> OpenTelemetry (OTel) es un proyecto de c\u00f3digo abierto dentro de la CNCF que define est\u00e1ndares para la generaci\u00f3n, recopilaci\u00f3n y reenv\u00edo de datos de telemetr\u00eda. Incluye SDKs para pr\u00e1cticamente todos los lenguajes de programaci\u00f3n relevantes, el OpenTelemetry Protocol (OTLP) para el transporte de datos y el OpenTelemetry Collector como componente central de intermediaci\u00f3n. Su objetivo es recopilar datos de observabilidad de forma neutral respecto al proveedor, reduciendo as\u00ed el vendor lock-in.<\/p>\n El valor para los equipos en la nube reside en la unificaci\u00f3n. Antes de OTel, cada proveedor ten\u00eda su propio formato, sus propios SDKs y su propio lenguaje para trazas, m\u00e9tricas y logs. Prometheus para m\u00e9tricas, Fluentd o Fluent Bit para logs, Jaeger o Zipkin para trazas, m\u00e1s agentes propietarios de Datadog, New Relic y Dynatrace. Cada una de estas capas ten\u00eda su propia sintaxis de configuraci\u00f3n, su propia sem\u00e1ntica para etiquetas y sus propios desaf\u00edos operativos. Con OTel, estas capas convergen en un conjunto de SDKs comunes y un protocolo compartido.<\/p>\n La consecuencia pr\u00e1ctica es que un equipo instrumenta su aplicaci\u00f3n una sola vez y luego puede decidir libremente hacia d\u00f3nde fluyen los datos. Hoy Prometheus y Grafana, ma\u00f1ana Datadog, pasado ma\u00f1ana una combinaci\u00f3n. El c\u00f3digo permanece igual, porque los SDKs de OTel producen el formato OTLP gen\u00e9rico. La elecci\u00f3n del backend se convierte en una cuesti\u00f3n puramente de configuraci\u00f3n.<\/p>\n La observaci\u00f3n de que en 2026 la pregunta pasa de \u00absi OTel\u00bb a \u00abpor qu\u00e9 todav\u00eda no\u00bb se confirma en las conversaciones con equipos de plataforma y SRE. Tres factores impulsan la aceleraci\u00f3n. Primero, la madurez de los SDKs. La auto-instrumentaci\u00f3n funciona de forma estable en 2026 para los principales runtimes (JVM, CLR, Node, Go, Python). Los equipos pueden instrumentar sus aplicaciones sin modificar el c\u00f3digo mediante un sidecar o un agente, y obtienen telemetr\u00eda base significativa desde frameworks est\u00e1ndar (Spring, ASP.NET, Express, Django).<\/p>\n Segundo, la aceptaci\u00f3n por parte de los proveedores. Datadog, New Relic, Dynatrace, Splunk, Elastic y otros han aceptado OTel como formato de entrada. Para las empresas que hasta ahora depend\u00edan de agentes propietarios, esto abre una v\u00eda de migraci\u00f3n. Eso transforma la din\u00e1mica negociadora en las renovaciones de contratos: quien est\u00e1 estandarizado en OTel dispone de opciones de salida cre\u00edbles.<\/p>\n Tercero, la orientaci\u00f3n cloud-native. AWS Distro for OpenTelemetry (ADOT), Azure Monitor OpenTelemetry Exporter y Google Cloud OpenTelemetry Operations est\u00e1n listos para producci\u00f3n y los hyperscalers los desarrollan activamente. Los operadores de Kubernetes para el OTel Collector son CNCF Graduated, y la integraci\u00f3n con service meshes como Istio y Linkerd es est\u00e1ndar. Para los equipos cloud-native, OTel en 2026 es la opci\u00f3n predeterminada, no una alternativa.<\/p>\n Para los equipos que trabajan hoy con un stack de observabilidad existente, el camino de migraci\u00f3n tiene este aspecto en la pr\u00e1ctica. Primera fase: el OTel Collector se introduce como componente central de recopilaci\u00f3n. Todas las fuentes de datos existentes (endpoints de Prometheus, archivos de log, trazas de Jaeger) se conectan al Collector. El Collector sigue exportando a los backends existentes, sin que nada cambie para los consumidores.<\/p>\n Segunda fase: las nuevas aplicaciones se instrumentan de forma nativa con los SDK de OTel. Esto significa: en lugar de las bibliotecas cliente de Prometheus se integran los SDK de OTel Metrics, en lugar de los log appenders los SDK de OTel Logs, y en lugar de los clientes Jaeger los SDK de OTel Traces. Los datos fluyen a trav\u00e9s de OTLP hasta el Collector y desde all\u00ed contin\u00faan como de costumbre.<\/p>\n Tercera fase: las aplicaciones existentes se van migrando progresivamente. Aqu\u00ed ayuda la auto-instrumentaci\u00f3n, porque funciona para frameworks est\u00e1ndar sin modificar el c\u00f3digo. Las instrumentaciones personalizadas se trasladan a la sem\u00e1ntica de OTel, lo que habitualmente supone menos trabajo que un cambio completo de SDK. Los backends existentes permanecen mientras funcionen. Un cambio a otro backend de observabilidad es opcional y puede realizarse m\u00e1s adelante de forma desacoplada.<\/p>\n D\u00f3nde tropiezan las migraciones OTel<\/p>\n Qu\u00e9 caracteriza a los rollouts OTel limpios<\/p>\n La estrategia de sampling merece especial atenci\u00f3n. La captura completa de trazas resulta r\u00e1pidamente costosa en servicios de alta frecuencia, tanto en transporte como en almacenamiento. OTel admite tanto el head-based como el tail-based sampling. El head-based decide al inicio de una traza, el tail-based tras su finalizaci\u00f3n. El tail-based es m\u00e1s exigente en infraestructura, pero ofrece una selecci\u00f3n m\u00e1s precisa (por ejemplo, solo trazas de error o trazas por encima de un umbral de latencia). La decisi\u00f3n debe tomarse pronto, porque determina la arquitectura del Collector.<\/p>\n El mercado de observabilidad es uno de los bloques de infraestructura m\u00e1s costosos en 2026. Las empresas con entre 500 y 2.000 desarrolladores gastan habitualmente entre 300.000 y tres millones de euros anuales en herramientas de observabilidad. Datadog, New Relic y Dynatrace dominan el segmento premium, Grafana Cloud y Honeycomb ocupan el rango medio, y los stacks open source como Prometheus m\u00e1s Loki m\u00e1s Grafana son m\u00e1s econ\u00f3micos en operaci\u00f3n, pero m\u00e1s exigentes en personal.<\/p>\n OTel transforma este panorama porque reduce los costes de cambio. Una empresa que ha estandarizado sobre OTel puede reemplazar su backend sin tener que reconstruir la instrumentaci\u00f3n. Esto otorga poder de negociaci\u00f3n en las rondas de contratos. Al mismo tiempo, OTel no reduce autom\u00e1ticamente los costes totales. Almacenar trazas, m\u00e9tricas y logs con alta resoluci\u00f3n sigue siendo caro, independientemente del proveedor. La discusi\u00f3n sobre costes se desplaza as\u00ed hacia el sampling, la retenci\u00f3n y la agregaci\u00f3n.<\/p>\n Un desarrollo interesante es el auge de los proveedores de backend nativos en OTel. Proveedores como Honeycomb, SigNoz, Coralogix y las soluciones basadas en ClickHouse construyen sus plataformas con OTel como primera opci\u00f3n, sin agentes ni formatos propietarios. Para los equipos que toman en serio la estandarizaci\u00f3n en OTel, estos son socios naturales. Los proveedores establecidos han a\u00f1adido OTel a posteriori, mientras que los proveedores OTel-first cuentan con ventajas arquitect\u00f3nicas en la integraci\u00f3n y la profundidad del modelo de datos.<\/p>\n De las migraciones de los \u00faltimos dieciocho meses se cristalizan tres errores recurrentes. Primero: el Collector se inicia sin l\u00edmites de recursos adecuados. Esto funciona perfectamente en staging y falla en producci\u00f3n bajo picos de carga. Los fallos del Collector generan p\u00e9rdidas de datos que resultan inc\u00f3modas en los post-mortems. La soluci\u00f3n: un Collector escalable horizontalmente con Memory-Limiter y Batch-Processor desde el principio, con pol\u00edticas claras de CPU y memoria.<\/p>\n Segundo: las Semantic Conventions no se aplican. OTel ofrece atributos definidos para HTTP, bases de datos, mensajer\u00eda y otros contextos est\u00e1ndar. Los equipos que inventan sus propios nombres de etiquetas (http.request.method en lugar de http_method) fragmentan sus propias m\u00e9tricas e impiden los an\u00e1lisis entre servicios. La soluci\u00f3n: una pol\u00edtica de Semantic Conventions como parte del Definition of Done para los nuevos servicios.<\/p>\n Tercero: los logs se tratan demasiado tiempo como una capa separada. Los OTel-Logs son estables en 2026, pero muchos equipos retrasan la migraci\u00f3n porque su stack de logs existente funciona. El problema: mientras los logs corran separados de los traces y las m\u00e9tricas, faltar\u00e1 la correlaci\u00f3n mediante Trace-IDs. Las consultas Cross-Signal, uno de los principales valores de OTel, solo ser\u00e1n posibles cuando las tres se\u00f1ales pasen por el mismo Collector y residan en el mismo backend.<\/p>\n Para los arquitectos de plataforma y los responsables de Observability, hay tres decisiones importantes en los pr\u00f3ximos seis meses. Primero: compromiso con OTel como est\u00e1ndar para la nueva instrumentaci\u00f3n. Todos los servicios nuevos arrancan con OTel-SDKs, sin excepciones. Segundo: ruta de migraci\u00f3n para los servicios existentes. Auto-instrumentaci\u00f3n donde sea posible, cambio al OTel-SDK en los pr\u00f3ximos seis a doce meses, instrumentaci\u00f3n personalizada como \u00faltima oleada. Tercero: estrategia de backend para los pr\u00f3ximos tres a\u00f1os. \u00bfSe mantiene el proveedor actual, se cambia a un backend nativo de OTel o se construye un setup h\u00edbrido?<\/p>\n La decisi\u00f3n sobre el backend merece una discusi\u00f3n exhaustiva. Cambiar de un proveedor premium propietario a uno OTel-first puede reducir los costes a la mitad, pero conlleva un esfuerzo de migraci\u00f3n. Mantener el proveedor actual es c\u00f3modo, pero no aprovecha la neutralidad de proveedor de OTel. Una estrategia h\u00edbrida con un proveedor premium para los servicios cr\u00edticos y un stack open-source para las aplicaciones menos cr\u00edticas puede representar el compromiso adecuado.<\/p>\n Un aspecto que cobra cada vez m\u00e1s importancia en 2026 es la Observability de agentes de IA. OTel ha desarrollado convenciones para la telemetr\u00eda de agentes de IA que estructuran el monitoreo de pipelines de GenAI. El consumo de tokens, las latencias por modelo, los indicadores de alucinaciones y los patrones de llamadas a herramientas se convierten en m\u00e9tricas est\u00e1ndar. Los equipos que despliegan agentes de IA en producci\u00f3n deber\u00edan adoptar estas convenciones pronto para no caer en una nueva ola de fragmentaci\u00f3n.<\/p>\n Un aspecto adicional es la correlaci\u00f3n entre Observability y FinOps. Los datos de OTel proporcionan la base para asignar los costes en la nube a nivel de servicio. Con Semantic Conventions limpias (service.name, deployment.environment, k8s.namespace) es posible asignar cada instancia a su centro de costes. Quien establezca esta integraci\u00f3n pronto se ahorrar\u00e1 semanas de reporting financiero m\u00e1s adelante. La combinaci\u00f3n de m\u00e9tricas de Observability con los datos de facturaci\u00f3n de los proveedores cloud es en 2026 el siguiente paso natural en muchos equipos de plataforma.<\/p>\n Por \u00faltimo, un punto pragm\u00e1tico sobre la formaci\u00f3n. OTel es conceptualmente potente, pero la curva de aprendizaje para los equipos que antes trabajaban con un agente propietario es real. Pensar en traces, m\u00e9tricas y logs dentro de un mismo modelo, comprender las Semantic Conventions, construir arquitecturas de Collector: todo eso requiere esfuerzo. Las inversiones en talleres internos, formaciones del CNCF o asesoramiento externo se rentabilizan, porque aumentan la velocidad de migraci\u00f3n y reducen los errores que luego resultan costosos. Un bootcamp de OTel de dos d\u00edas para el equipo de plataforma y los staff engineers suele amortizarse ya en el primer trimestre en trabajo de migraci\u00f3n ahorrado, especialmente si el equipo se lleva una hoja de ruta clara.<\/p>\n Prometheus sigue siendo una soluci\u00f3n basada en scraping muy s\u00f3lida para m\u00e9tricas. El valor de OTel-Metrics reside en la combinaci\u00f3n con trazas y logs en un pipeline com\u00fan. Muchos equipos ejecutan ambas soluciones en paralelo, con OTel como alternativa push para aplicaciones y Prometheus para el scraping de infraestructura. Una sustituci\u00f3n completa no es imprescindible.<\/p>\n<\/details>\n Una pol\u00edtica de Semantic Conventions claramente definida y una decisi\u00f3n sobre la estrategia de sampling. Ambas pueden elaborarse en un taller de dos d\u00edas para el equipo de plataforma y desarrollo. Sin este trabajo previo, cada servicio genera sus propias convenciones. Las reglas de sampling surgen de forma improvisada, lo que resulta problem\u00e1tico en producci\u00f3n.<\/p>\n<\/details>\n El OTel Collector dispone de receivers para pr\u00e1cticamente todos los formatos habituales (Prometheus, Syslog, StatsD, Jaeger, Zipkin, Filelog). Las aplicaciones legadas pueden enviar sus datos en el formato existente; el Collector los transforma a OTLP y los reenv\u00eda. Esto permite una migraci\u00f3n gradual sin big bang.<\/p>\n<\/details>\n Los costes directos por volumen de datos siguen dependiendo del backend. OTel reduce los costes de los agentes propietarios (sin licencias separadas) y abre opciones de cambio que presionan a la baja los precios de mercado. Los ahorros indirectos derivados de una mayor velocidad en la resoluci\u00f3n de problemas llegan entre tres y seis meses despu\u00e9s, una vez establecidas las consultas cross-signal.<\/p>\n<\/details>\n S\u00ed, cuando el equipo opera m\u00e1s de cinco servicios o trabaja en una arquitectura de microservicios. Para monolitos individuales bastan configuraciones m\u00e1s sencillas. A partir de una complejidad media, OTel despliega todo su valor, ya que la correlaci\u00f3n entre servicios se vuelve cr\u00edtica.<\/p>\n<\/details>\n Plataformas low-code en la mediana empresa 2026<\/a>\n<\/div>\n\n
Lo que OpenTelemetry realmente ofrece en 2026<\/h2>\n
Por qu\u00e9 la adopci\u00f3n empresarial da el salto en 2026<\/h2>\n
D\u00f3nde empieza concretamente la migraci\u00f3n<\/h2>\n
\n
\n
C\u00f3mo se relacionan los costes y la estrategia de proveedores<\/h2>\n
Errores que los equipos pueden evitar en 2026<\/h2>\n
Lo que CIOs y arquitectos deber\u00edan decidir en 2026<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfVale la pena migrar de Prometheus a OTel-Metrics?<\/strong><\/summary>\n
\u00bfCu\u00e1l es la preparaci\u00f3n m\u00e1s importante antes de un despliegue de OTel?<\/strong><\/summary>\n
\u00bfC\u00f3mo gestiono las aplicaciones legadas que no soportan los SDK de OTel?<\/strong><\/summary>\n
\u00bfQu\u00e9 impacto tiene OTel en los costes cloud?<\/strong><\/summary>\n
\u00bfTiene sentido OpenTelemetry tambi\u00e9n para equipos peque\u00f1os?<\/strong><\/summary>\n
M\u00e1s de la red MBF Media<\/h2>\n