Bill shock de observabilidad: por qué tu factura de Datadog se dispara con IA (y cómo contenerla)

Hay una escena que se repite en los canales de Slack de medio mundo: alguien pega una captura de la factura de observabilidad del mes con un emoji de cara de susto. 😱 En managed services lo viví del otro lado —el del proveedor que tiene que explicarle a un cliente por qué su factura creció más rápido que su tráfico—. Y en 2026, con las cargas de IA, el problema dejó de ser una molestia de fin de mes para volverse una línea que aparece en las juntas de dirección.

Este artículo no es contra Datadog (es una gran herramienta; ya escribí sobre cómo Datadog reduce el MTTR en equipos SRE). Es sobre entender por qué la factura se dispara y qué palancas reales tienes para contenerla, con un ejemplo numérico que puedes copiar y un checklist que puedes correr esta misma semana.

¿Por qué explota la factura con IA?

Respuesta corta: porque cambió la unidad que pagas. La observabilidad se cobra, en buena medida, por la cantidad de datos que ingieres e indexas. Una petición web típica genera un puñado de spans. Una interacción con un modelo o un agente genera muchos más, porque cada llamada al LLM, cada paso de razonamiento y cada herramienta invocada se registra por separado. No es que hagas “más cosas”: es que cada cosa deja diez veces más rastro.

Lo interesante es dónde se acumula ese rastro. Un agente no responde de un tiro; entra en un bucle: piensa, llama a una herramienta, lee el resultado, vuelve a pensar, llama a otra. Cada vuelta de ese loop emite su propio span, con su prompt, su respuesta, sus tokens y su latencia. Multiplícalo por miles de usuarios concurrentes y entiendes por qué el gráfico de ingesta se pone vertical.

Las cifras que circulan en la comunidad ilustran la magnitud. Conviene tratarlas como estimaciones de terceros, no como dato duro, pero el orden de magnitud es real:

Ese salto de 2-3 spans a 40-75 por interacción viene del análisis de observabilidad de agentes de The New Stack, que además insiste en un punto que en campo se siente clarísimo: auditar un agente exige capturar cada paso intermedio, no solo la respuesta final. Esa exigencia de trazabilidad es, justamente, la que infla el volumen.

A eso súmale los reportes de crecimiento de factura que recogen otros medios. Según byteiota, las cuentas grandes reportan aumentos interanuales del orden de 30 % a 50 %, con saltos del 40 % al 200 % cuando se añade monitoreo de LLMs. Y según oneuptime, una empresa mid-market puede terminar pagando alrededor de $123.000 USD al año en observabilidad. Repito: son cifras citadas por esos medios, útiles para dimensionar, no para presumir como estadística propia. 📌

¿Cómo se ve el ahorro en números? Un ejemplo trabajado

La teoría del sampling aburre hasta que la pones en pesos. Vamos con un ejemplo ilustrativo (no es un benchmark ni una promesa de resultados: es aritmética para que veas la mecánica). Imagina un servicio que emite 50 millones de spans al día. La mayoría son trazas de peticiones que salieron bien, se repiten y nadie mira jamás.

Aplicas tail-based sampling: conservas el 100 % de las trazas con error y solo el 10 % de las trazas normales. Supón que el 2 % de tus trazas tienen error. La cuenta queda así:

Pasas de 50 millones a menos de 6 millones de spans diarios sin perder ni una sola traza con error. Si tu backend cobra por ingesta, ese recorte de volumen se traslada casi directo a la factura. Y lo importante: las señales que de verdad usas para depurar —los errores y las trazas lentas— siguen ahí completas.

El truco está en muestrear por la cola (tail-based) y no por la cabeza (head-based). El muestreo de cabeza decide al inicio de la traza, cuando todavía no sabe si va a fallar; el de cola decide al final, cuando ya vio el resultado completo. Por eso el tail-based puede quedarse con “todos los errores” y “una fracción del ruido”. Así se configura en el OpenTelemetry Collector:

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 100000
    policies:
      # 1) Conserva SIEMPRE las trazas con error
      - name: errores-siempre
        type: status_code
        status_code:
          status_codes: [ERROR]
      # 2) Conserva las trazas lentas (> 1s de latencia)
      - name: latencia-alta
        type: latency
        latency:
          threshold_ms: 1000
      # 3) Del resto (trazas normales), quédate solo con el 10 %
      - name: muestreo-base
        type: probabilistic
        probabilistic:
          sampling_percentage: 10

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling]
      exporters: [otlp/backend]

Las políticas se evalúan en orden: si una traza tiene error o es lenta, se conserva entera; solo lo que no cae en esas dos redes pasa por el muestreo probabilístico al 10 %. Ajusta el umbral de latencia y el porcentaje a tu realidad. Un detalle de campo: el decision_wait debe ser mayor que la duración de tus trazas más largas, o cortarás decisiones a medias. Si quieres el porqué de instrumentar con OTel antes de llegar a esto, lo desarrollo en OpenTelemetry y trazas en microservicios.

¿Y esto es solo de Datadog? No: es un problema de costos en la nube

Aunque el susto suele llegar con la factura de Datadog, el problema de fondo es más amplio: los costos de observabilidad en la nube crecen al mismo ritmo que tus datos, y con IA los datos crecen rápido. Cada log, cada métrica de alta cardinalidad y cada traza que envías es ingesta, almacenamiento y retención que alguien paga a fin de mes.

Por eso cada vez más equipos tratan la observabilidad como una partida de FinOps: la pregunta deja de ser “¿cuántos datos puedo mandar?” y pasa a ser “¿qué datos me dan respuestas que valgan lo que cuestan?”. En mis años operando sistemas lo vi claro: la telemetría más cara casi nunca es la que más usas para resolver un incidente —y ahí está la grasa que se recorta sin perder visibilidad.

¿Cuáles son las tres palancas que sí bajan la factura?

He visto a equipos intentar de todo, desde apagar dashboards que nadie abría hasta migraciones enteras hechas por pánico. Estas son las tres palancas que de verdad mueven la aguja:

Las tres se complementan. El muestreo baja el volumen que entra; los tiers abaratan lo que decides guardar; y OpenTelemetry es el que te deja aplicar las dos primeras sin quedar amarrado a la forma de cobrar de un solo proveedor. Si tuviera que empezar por una en un equipo con la factura desbocada, sería el sampling: es la que da el recorte más grande en menos tiempo.

Te lo digo por experiencia propia, de mucho antes de que “bill shock” fuera un término. En una época me tocó armar los reportes mensuales de servicio de un cliente, y cada mes tardaba una semana entera bajando y depurando datos a mano porque la hoja de cálculo se trababa de tanto volumen. Pagaba el costo de la telemetría en horas de mi vida, no en dólares. La moraleja es idéntica a la de hoy: el volumen siempre se cobra —antes con tu tiempo, ahora con la factura del proveedor— y la mayor parte de ese volumen nadie lo mira jamás. Junta solo lo que vas a usar. 📉

Antes de auditar la factura: ¿sabes qué tienes?

Trabajé tres meses en una empresa que ya no existe, y fueron suficientes para aprender cómo se ve el desastre. Todo era manual. La información de cada cliente vivía en Excels dispersos —uno por aquí, otro por allá, ninguno actualizado del todo, ninguna fuente única de verdad—. El monitoreo era básico y los clientes estaban molestos por razones bastante evidentes.

Lo que más me marcó no fue la falta de herramientas. Fue que nadie podía contestar una pregunta simple: ¿qué le estamos cobrando a este cliente, y por qué? Responderla exigía abrir cuatro archivos y preguntarle a dos personas, y aun así quedaba en duda.

Lo traigo al tema de la factura de observabilidad porque el patrón es idéntico. Una auditoría de costos no falla por falta de tablero: falla porque nadie sabe qué se está enviando, desde dónde, con qué retención ni quién lo pidió. La telemetría se acumula igual que esos Excels — alguien activó un log detallado para un incidente hace ocho meses, resolvió el incidente y nunca lo apagó. Nadie lo apaga, porque nadie sabe que sigue prendido.

Por eso el checklist de abajo empieza por inventariar, no por recortar. No puedes negociar lo que no sabes que estás pagando, y no puedes apagar lo que no sabes que está encendido.

¿Qué reviso en una auditoría de factura? El checklist

Cuando entro a revisar por qué una factura de observabilidad se salió de rango, sigo más o menos este recorrido. No es glamuroso, pero encuentra dinero cada vez. Úsalo como lista para tu próxima revisión mensual:

La pregunta que me hago antes de mirar el precio

Después de años implementando estas plataformas me quedé con un marco que me sirve para casi todas: cada herramienta es de verdad la mejor en una sola cosa. El resto es commodity.

Lo aplico a las dos que conozco de operarlas. De ThousandEyes mi veredicto es que sigue siendo muy buena en BGP y en visibilidad de Internet; fuera de ahí hoy la veo como una herramienta más, porque el mercado avanzó. De Splunk Core diría que correlaciona muy bien —ahí cuesta igualarlo— y también que hay opciones más baratas para lo mismo que hace.

Ninguno de esos dos juicios es un ataque. Son herramientas que conozco por haberlas usado, y precisamente por eso puedo decir dónde terminan.

El marco, entonces: el precio no se juzga contra la lista de funciones, se juzga contra aquello en lo que la herramienta es realmente mejor que las demás. Si estás pagando de más por ese terreno donde nadie la alcanza, probablemente vale. Si estás pagando de más por treinta funciones de las que usas tres, y esas tres las hace algo más barato, no estás comprando capacidad: estás comprando comodidad. Que también se puede, pero conviene saberlo.

Un cuidado al hacer este ejercicio: no metas toda una familia de productos en el mismo juicio. “Splunk” no es una cosa — el motor de logs, la capa de inteligencia de servicio y el monitoreo de usuario real son productos distintos, con precios y competidores distintos. Compara módulo contra módulo o el resultado no te va a servir para negociar nada.

La palanca oculta: la portabilidad es poder de negociación

El vendor sabe perfectamente si estás atrapado. Si re-instrumentar te cuesta seis meses, no tienes con qué negociar. Si tu telemetría habla OpenTelemetry, la conversación cambia.

Esta es la razón estratégica —más allá de lo técnico— para estandarizar con OpenTelemetry. La portabilidad no solo te da flexibilidad de arquitectura; te da flexibilidad de presupuesto. Cuando el proveedor sabe que podrías exportar tu telemetría a otro backend en semanas y no en trimestres, tu posición en la mesa de renovación es completamente distinta. Y si estás decidiendo dónde vive todo esto, el costo también entra en la ecuación de nube versus on-premise.

Vale la pena aclarar de qué hablamos cuando decimos “observabilidad”, porque no es lo mismo que monitoreo: lo desmenuzo en qué es la observabilidad. La distinción importa para el bolsillo: monitorear métricas conocidas es barato; explorar libremente lo desconocido, que es la promesa de la observabilidad, es lo que dispara el volumen. Saber cuándo necesitas cada cosa evita pagar por trazas que jamás vas a explorar.

¿Los proveedores están respondiendo a esto?

Sí, y conviene saberlo antes de negociar. En su conferencia DASH 2026, Datadog presentó un paquete de anuncios que apunta directo al problema del costo y de las cargas de IA. Según el roundup oficial de Datadog, dos piezas destacan para esta conversación: Bring Your Own Cloud (BYOC), que permite procesar y retener datos en tu propia infraestructura de nube, y la disponibilidad general del GPU Monitoring, pensado para las cargas de IA que hoy inflan la telemetría.

La cobertura de medios pone la cifra en contexto: según SiliconAngle, Datadog lanzó más de 100 features en ese evento, con un empuje fuerte hacia operaciones de IA autónomas. La lectura de producto es clara: el mercado ya reconoce que el modelo de “págame por todo lo que ingieras” no aguanta la era de los agentes, y empieza a ofrecer válvulas de escape. BYOC, en particular, es una respuesta directa a la palanca de tiers de datos que mencioné arriba. Si monitoreas GPUs, además, te va a interesar cómo se instrumenta eso con estándar abierto en observabilidad de GPUs con DCGM y OpenTelemetry.

Preguntas frecuentes

¿Datadog es más caro que otras herramientas?

El debate de “bill shock” no es exclusivo de Datadog; aparece con cualquier plataforma que cobre por volumen de datos. La causa raíz es el modelo de precios por ingesta, combinado con la explosión de telemetría que traen las cargas de IA. Las palancas (sampling, tiers, OTel) aplican con cualquier proveedor.

¿El muestreo me hace perder información importante?

Bien configurado, no. El muestreo inteligente (tail-based sampling) conserva las trazas con errores o latencia alta —justo las que te importan— y descarta el ruido repetitivo. Pierdes volumen redundante, no señales. En el ejemplo de arriba, recortas ~88 % del volumen sin soltar una sola traza con error.

¿Cuánto puedo ahorrar realmente?

Depende de tu punto de partida, así que desconfía de quien te prometa un número exacto. Lo consistente en mi experiencia es que casi siempre hay un 20-30 % de telemetría que nadie consulta: ahí está el recorte más fácil y sin riesgo.

¿Qué es exactamente un span y por qué importa para el costo?

Un span es el registro de una operación individual dentro de una traza: una consulta a base de datos, una llamada a una API, un paso de un agente. Importa porque muchos backends cobran por volumen ingerido, y los agentes de IA generan decenas de spans por interacción según The New Stack. Más spans, más factura.

✍️ Creado por Ethel Méndez — Senior Product Manager en observabilidad, con 20+ años entre NOC, managed services y producto B2B para LATAM.

Imagen destacada generada con inteligencia artificial.