Bloomberg impulsa observabilidad con OpenTelemetry

Bloomberg acaba de comprometerse en grande con OpenTelemetry: 30 a 45 ingenieros trabajando durante abril-junio 2026 en contribuciones directas al framework open source de observabilidad. El anuncio (hecho por CNCF el 31 de marzo) suma a Bloomberg como socio estratégico en la consolidación de OpenTelemetry como estándar global de observabilidad.

OpenTelemetry es un framework open source respaldado por CNCF que proporciona SDKs, APIs y herramientas para instrumentar aplicaciones y recolectar señales de observabilidad (trazas, métricas y logs) de forma vendor-agnostic, permitiendo enviarlas a cualquier backend de observabilidad sin cambios de código.

¿Qué es OpenTelemetry y por qué es crítico para DevOps?

Imaginá que tenés una arquitectura de microservicios: 15 servicios Python/Go/Node, cada uno corriendo en Kubernetes. Un cliente reporta que los pedidos tardan 30 segundos. ¿Dónde está el problema? ¿En API Gateway, en el servicio de pagos, en la base de datos? Sin observabilidad unificada, estás a ciegas.

Eso era el panorama hace cinco años. Los equipos usaban Prometheus para métricas, Jaeger para trazas distribuidas, ELK Stack para logs, y armar todo eso en un solo lugar era un quilombo — plataformas incompatibles, APIs diferentes, vendors que no hablaban entre sí (es un golazo). OpenTelemetry vino a romper eso.

OpenTelemetry no es un backend. Es una capa de instrumentación agnóstica que dice: “Vos instrumentá tu código una sola vez con nuestros SDKs, nosotros nos encargamos de transformar esos datos al formato que tu backend necesite.” Podés cambiar de Datadog a Grafana sin tocar una línea de código de producción.

¿Y la escala? Según la documentación oficial, OpenTelemetry ya está soportado en más de 15 lenguajes de programación. En el ecosistema cloud-native, si no estás instrumentando con OpenTelemetry, estás quedando atrás.

Bloomberg amplía su compromiso con software libre: el partnership con CNCF

Bloomberg es una empresa que viene banca fuerte el open source. Desde 2019 con su FOSS Fund, desde el 2020 con Memray (su profiler Python), contribuyendo a pandas, NVIDIA AI Infrastructure. No es caridad — es estrategia empresarial: los estándares abiertos que adoptás hoy controlan tu costo de infraestructura mañana. En privacidad en plataformas de desarrollo profundizamos sobre esto.

El anuncio del 31 de marzo es la jugada más grande que han hecho en observabilidad. Según el comunicado oficial, Bloomberg destinará 30 a 45 ingenieros entre abril y junio 2026, más 7 mentores/maintainers dedicados. No es una pasantía de verano — es un programa de mentorship estructurado con office hours, sesiones síncronas y soporte asincrónico.

¿Qué gana Bloomberg? Influencia en el estándar que van a usar todos sus competidores en observabilidad. ¿Qué gana la comunidad? Momentum. Cuando una empresa como Bloomberg apuesta ingenieros a tiempo completo, todo el ecosistema acelera.

Detalles del programa de contribución: qué hará Bloomberg en OpenTelemetry

Los 30-45 ingenieros van a tocar varias áreas:

• Instrumentación automática: mejorar zero-code instrumentation para que vos no tengas que tocar nada en tu código productivo.
• SDKs: expander las librerías para lenguajes emergentes donde OpenTelemetry aún tiene gaps (Rust, COBOL, Kotlin).
• Collector components: procesadores, exporters y receptores nuevos.
• Semantic conventions: estandarizar nombres de atributos y eventos (ahora cada backend los llama distinto).
• Documentación y ejemplos: traducir la documentación (todavía falta mucho español), armar tutorials, hands-on labs.

El programa funciona en bloques de 2 horas/semana por participante, remoto. No es para trabajar en OpenTelemetry “cuando tengas tiempo” — es asignación dedicada, con mentores de OpenTelemetry guiando el camino.

Esto es importante porque lleva a que la gente que trabajó en OpenTelemetry por tres meses va a escribir código mejor documentado, va a entender las debilidades del proyecto, y cuando vuelva a Bloomberg, va a empezar a instrumentar todo con OpenTelemetry. Multiplicador de adopción.

Los 3 pilares de la observabilidad: trazas, métricas y logs unificados

OpenTelemetry organiza la observabilidad en tres tipos de señales. Cada una responde una pregunta diferente.

Métricas: ¿Qué está pasando ahora mismo? CPU, memoria, latencia p99, errores por segundo. Son números que generás en intervalos (cada 30 segundos, cada minuto). Prometheus es el rey de las métricas. Relacionado: herramientas de IA para developers.

Trazas distribuidas: ¿Qué camino hizo mi request desde que llegó hasta que volvió? Ponele que un pedido tocó API Gateway → servicio de pagos → base de datos → cache → email. Una traza te muestra cada hop, cuánto tardó, dónde se rompió. Jaeger es el backend más famoso.

Logs: ¿Qué dijeron mis aplicaciones mientras procesaban eso? Eventos estructurados: “usuario 42 intentó login”, “query SQL tardó 5 segundos”, “fallo de conexión a RabbitMQ”. Son datos semiestructurados que ELK Stack, Loki, Datadog ingieren.

Antes tenías tres pilas separadas: recolectás métricas aquí, trazas allá, logs en otro lado. Armar un dashboard donde todo converja era un caos. OpenTelemetry dice: todos van por el mismo SDKs, mismo formato estándar, mismo Collector. Vos elegís a dónde enviarlo.

OpenTelemetry vs Prometheus vs Jaeger: cuándo usar cada uno

El workflow típico ahora es: OpenTelemetry instrumenta tu app, exporta métricas a Prometheus (almacenamiento + alerting), exporta trazas a Jaeger (visualización de flows distribuidos), exporta logs a Loki o Grafana Cloud. OpenTelemetry es el puente, no el almacén.

Cómo empezar: instrumentación de aplicaciones Python, Node.js y Java

El setup básico toma 15 minutos si usás zero-code instrumentation.

Python:

• Instalás pip install opentelemetry-distro
• Ejecutás opentelemetry-bootstrap -a install (instrumenta automáticamente Flask, Django, requests, SQLAlchemy)
• Corrés tu app con opentelemetry-instrument python tu_app.py
• Ya está generando trazas, métricas y logs — sin tocar una línea

Node.js:

• npm install @opentelemetry/api @opentelemetry/sdk-node
• Cargás el SDK antes que cualquier otra cosa en tu index.js
• OpenTelemetry instrumenta Express, Fastify, HTTP automáticamente

Java:

• Descargás el Java agent JAR de OpenTelemetry
• Corrés java -javaagent:opentelemetry-javaagent.jar -jar tu_app.jar
• Instrumentación automática para Spring, Hibernate, JDBC, HTTP

La magia de zero-code es que no toqués la aplicación — OpenTelemetry intercepta en tiempo de ejecución. Obvio que después podés hacer instrumentación manual (anotar funciones críticas, contexto custom), pero para empezar, funciona. Complementá con ecosistemas de desarrollo empresarial.

Por qué el open source matters: el modelo de mentorship que Bloomberg replica

Bloomberg testeó este modelo con CNCF y pandas + NumFOCUS hace años. La fórmula es sencilla pero potente: ingenieros dedicados + mentores del proyecto + tiempo estructurado = aceleración explosiva de features, fixes y documentación.

¿Qué pasó con pandas después de que Bloomberg metió ingenieros? Se aceleró todo. Fue de “proyecto mantenido por voluntarios con burnout” a “proyecto con roadmap claro, features implementadas, documentación seria”. Lo mismo le va a pasar a OpenTelemetry.

El beneficio secundario (que Bloomberg sabe bien) es el control. En lugar de depender de un vendor propietario para observabilidad — Datadog, New Relic, Elastic — Bloomberg contribuyó a un estándar abierto que no controla nadie. Eso te da poder: podés cambiar de backend sin reescribir. El código es tuyo, no de Datadog.

Para empresas en Latinoamérica como donweb, que usan infraestructura cloud, esto es especialmente relevante. OpenTelemetry no tiene sobreprecios por volumen, no hay vendor lock-in, podés hostearlo donde quieras.

Errores comunes al implementar OpenTelemetry

1. Usar OpenTelemetry sin elegir un backend de almacenamiento

OpenTelemetry recolecta señales pero no las almacena. Si no configurás un exportador (Prometheus, Jaeger, Grafana Cloud, Datadog), tus datos se pierden en el aire. Resultado: no sabés por qué está lento todo.

2. Sobre-instrumentar y llenar de ruido el observabilidad

Es fácil hacer que cada función genere una traza, cada variable se loguee. Fin resultado: millones de eventos basura, costos de almacenamiento que se disparan, dashboards ilegibles. Menos es más — instrumentá lo que importa (APIs externas, queries de BD, puntos de decisión críticos).

3. No estandarizar semantic conventions dentro del equipo

Acordate que los desarrolladores en el equipo van a instrumentar de formas diferentes si no hay guidelines. Uno dice “http_status”, otro dice “http.status.code”, otro “status”. Después no podés hacer queries cruzadas. Definí conventions antes de empezar. Tema relacionado: tecnologías generativas modernas.

4. Ignorar la sobrecarga de performance

Zero-code instrumentation es cómoda pero tiene un costo (CPU, memoria, latencia de red para exportar). En aplicaciones críticas, medí siempre antes y después. Algunos equipos reportan overhead de 2-5% en latencia p99 — aceptable, pero no ignorable.

Preguntas Frecuentes

¿Qué es OpenTelemetry y para qué sirve?

OpenTelemetry es un framework abierto que instrumenta aplicaciones para recolectar trazas, métricas y logs de forma vendor-agnostic. Te permite saber qué está pasando en tus sistemas distribuidos sin quedarte atado a un proveedor como Datadog o New Relic. Instalas el SDK una vez, luego exportas a cualquier backend.

¿Por qué Bloomberg invierte 30-45 ingenieros en OpenTelemetry?

Bloomberg necesita un estándar de observabilidad que no controle ningún vendor. Si contribuye a OpenTelemetry, asegura que el estándar evolucione hacia lo que Bloomberg necesita, y además influye en el ecosistema global. Es estrategia empresarial: invertir en el software que todo el mundo va a usar.

¿Cuál es la diferencia entre OpenTelemetry, Prometheus y Jaeger?

OpenTelemetry es cómo instrumentas (el SDK). Prometheus es cómo almacenas métricas. Jaeger es cómo ves trazas distribuidas. Son capas diferentes: OpenTelemetry → Prometheus/Jaeger → dashboard. OpenTelemetry no reemplaza a Prometheus ni Jaeger, trabaja con ellos.

¿Cuáles son los 3 pilares de la observabilidad moderna?

Métricas (¿qué está pasando ahora?), trazas (¿qué camino hizo mi request?), logs (¿qué dijeron las aplicaciones?). OpenTelemetry unifica la recolección de los tres. Antes los manejabas con sistemas separados; ahora con un SDK.

¿Cómo empiezo con OpenTelemetry si tengo una aplicación legacy?

Usá zero-code instrumentation primero (solo instalá el SDK, no toques el código). OpenTelemetry va a interceptar automáticamente en tiempo de ejecución. Si después necesitás más detalle, añadís instrumentación manual puntuales donde importa, pero sin reescribir todo.

Conclusión

El anuncio de Bloomberg sobre OpenTelemetry no es una noticia más de open source. Es un punto de inflexión. Cuando una empresa de escala global apuesta 30-45 ingenieros a consolidar un estándar abierto, toda la industria se mueve.

OpenTelemetry ya estaba ganando tracción, pero ahora entra en modo aceleración. Los próximos 90 días van a definir el futuro de cómo observamos sistemas distribuidos. Si tu equipo aún no está familiarizado con OpenTelemetry, abril 2026 es el momento para dejar de postergarlo.

La ventaja no es solo técnica (es agnóstico, es vendor-neutral, es gratis). Es también de control: instrumentás una vez, exportas a cualquier lado, no quedás atrapado. Eso es lo que Bloomberg vio, y por eso apuesta. Vos también podés apostar por lo mismo.

Fuentes

• CNCF Blog – Sustaining OpenTelemetry: Moving from Dependency Management to Stewardship
• Bloomberg – Sustaining OpenTelemetry: Moving from Dependency Management to Stewardship
• CNCF – OpenTelemetry Project
• OpenTelemetry – ¿Qué es OpenTelemetry?
• Elastic – ¿Qué es observabilidad?