Cómo reducir tu factura de Datadog con OpenTelemetry

Cada trimestre se repite la misma escena en algún canal de Slack: alguien comparte la última factura de Datadog y el hilo se llena de incredulidad, humor negro y ese mensaje de "yo lo advertí". Si tu factura se duplicó desde que la contrataste, no eres un caso raro. Eres la norma.

El patrón es casi siempre idéntico. Empiezas con APM para un puñado de servicios. Después agregas logs, porque correlacionar trazas con líneas de log es útil. Luego se cuelan las métricas custom. Alguien activa RUM. Y un día abres el PDF y descubres que estás gastando más en observar tu infraestructura que en la infraestructura misma.

Este no es un ataque a Datadog. Su producto es bueno de verdad y su interfaz sigue siendo de las mejores del mercado. El problema es estructural: su modelo de precios cobra por dimensión —por host, por GB, por span, por sesión— y eso crea un impuesto al crecimiento que golpea con fuerza a los equipos de tamaño medio.

1. Por qué se dispara: el precio se multiplica, no se suma

Datadog no te cobra una mensualidad simple. Cobra por separado cada dimensión de observabilidad, y esos cargos se multiplican entre sí a medida que creces. Los números públicos de referencia dan una idea:

• Monitoreo de infraestructura desde $15 por host/mes.
• APM desde $31 por host/mes, más un cargo por spans adicionales.
• Logs que cobran dos veces: alrededor de $0.10 por GB ingerido y otro tanto por millón de eventos indexados.
• Métricas custom que se disparan en cuanto instrumentas con Prometheus u OpenTelemetry y generas miles de series por servicio.

El resultado es una factura que escala de forma super-lineal: crece más rápido que tu propia infraestructura. Así se ve un desglose realista para una organización mediana de ~150 hosts:

Figura 1 — APM y logs se llevan la mitad de la factura. Cifras de referencia del sector.

Fíjate en ese dato: las dos franjas más caras —APM y logs— se llevan la mitad del gasto. Esa observación es la que define toda tu estrategia de salida.

2. 2026 lo empeora: la IA infla la telemetría

Hay una variable nueva que está rompiendo presupuestos. Las cargas de trabajo con IA generan entre 10 y 50 veces más telemetría que un servicio tradicional, y los equipos quedan ciegos cuando añaden monitoreo de LLMs: se reportan aumentos del 40% al 200% en la factura.

Tiene lógica. Una sola petición de inferencia produce miles de tokens que hay que rastrear por costo, vectores de embeddings de alta dimensión que no encajan en sistemas de logs tradicionales, árboles de trazas multi-paso por el razonamiento encadenado, y métricas de evaluación nuevas como tasas de alucinación. Cada una de esas cosas es una dimensión más que tu plataforma de observabilidad va a cobrarte.

Si tu observabilidad cuesta más que la infraestructura que observa, algo se rompió. Y la IA solo está ensanchando esa grieta.

3. La salida no es botar Datadog

Aquí está el matiz que la mayoría de los hilos de Slack pasan por alto: el objetivo no es migrar todo de golpe a otra herramienta. El objetivo es dejar de ser rehén de un modelo de precios que te castiga por crecer.

La jugada que de verdad funciona en 2026 es un modelo híbrido. Conservas Datadog para las una o dos cosas que hace mejor que nadie —típicamente las trazas de APM— y mueves todo lo demás a alternativas más baratas. La pieza que hace esto posible es OpenTelemetry: estandariza la capa de datos, así que instrumentas una sola vez y decides después a dónde mandas cada señal.

Los logs suelen ser lo primero que se migra, por dos razones: son el ítem más caro de la factura y, al estar emitidos vía OTel, son los más fáciles de redirigir. Cambias el endpoint OTLP y tu telemetría fluye a otro destino, sin tocar el código de la aplicación.

Figura 2 — Instrumentas una vez con OpenTelemetry; el colector decide el destino de cada señal.

4. Plan de acción: qué migrar y en qué orden

No migres por entusiasmo, migra por retorno. La regla es simple: ataca primero lo que tiene costo alto y esfuerzo bajo, y deja para el final lo que tiene esfuerzo alto o donde la herramienta cara realmente brilla. Este es el orden que funciona para la mayoría de los equipos:

Figura 3 — El orden va por la relación entre lo que ahorras y lo que cuesta migrarlo, no por el tamaño del gasto.

Empezar por logs suele recuperar el mayor porcentaje con el menor riesgo. Junto al ruteo, hay dos palancas que reducen el volumen antes de que llegue a cualquier destino: muestreo de trazas (no necesitas el 100% de los spans para entender la salud de un servicio) y control de cardinalidad en las métricas (cada etiqueta de alta cardinalidad multiplica series). Ambas se configuran en el colector de OpenTelemetry y, muchas veces, recortan factura sin que nadie note la diferencia en los dashboards.

5. Cuándo SÍ quedarte en Datadog

Seamos justos: hay casos donde la factura alta está justificada. Si eres una empresa de 500 personas, con requisitos de compliance complejos y decenas de integraciones que un equipo pequeño no quiere operar, pagar por una plataforma pulida y unificada tiene todo el sentido. Operar tu propio stack de observabilidad no es gratis: es trabajo de ingeniería real y continuo.

Donde el cálculo cambia es en el mid-market: un equipo de 30 personas corriendo 20 microservicios en Kubernetes casi nunca necesita gastar seis cifras al año en monitoreo. Si ese eres tú, el stack abierto sobre OpenTelemetry ya está maduro para producción, y la pregunta no es "¿puedo?", sino "¿por qué no empecé antes?".

El resumen en una línea

Instrumenta con OpenTelemetry para no quedar atado a ningún proveedor. Mueve los logs primero, controla cardinalidad y muestreo, y conserva en Datadog solo lo que de verdad no puedes replicar. El objetivo no es ahorrar por ahorrar: es recuperar el control de una factura que hoy crece sola.

2. OpenTelemetry como palanca de costes, no solo de instrumentación

Saber que APM y logs dominan la factura no sirve de mucho si no tienes una forma limpia de sacarlos sin romper la observabilidad. Ahí es donde OpenTelemetry cambia las reglas del juego: al desacoplar la instrumentación del backend, decides por canal y por servicio qué datos siguen yendo a Datadog y cuáles se desvían a una alternativa más económica.

La clave no es abandonar Datadog. Es usarlo de forma más precisa —para lo que hace mejor: dashboards, alertas y la interfaz de APM en flujos críticos— mientras descargas el volumen alto de trazas y métricas custom a backends como Grafana Tempo, Loki o VictoriaMetrics. OpenTelemetry es el enrutador que hace posible ese stack híbrido sin duplicar instrumentación.

1. 1Mapea tus dimensiones facturablesAbre Usage en Datadog y clasifica cada línea: hosts, spans, GB de logs, series de métricas custom, sesiones de RUM. Identifica cuáles crecen más rápido que tu infraestructura.
2. 2Empieza por métricas custom de alta cardinalidadSon el coste silencioso. Si usas exporters de Prometheus u OpenTelemetry sin filtrar, probablemente generes miles de series por servicio. Redirige esos datos a VictoriaMetrics o Mimir.
3. 3Deriva logs de baja prioridad a LokiLogs de debug, health checks y traces de desarrollo no necesitan indexación en Datadog. Envíalos a Grafana Loki manteniendo el trace ID como campo para correlación manual.
4. 4Mantén trazas críticas en Datadog hasta validar el stack alternativoNo migres todo a la vez. Deja los flujos de pago y servicios core en Datadog mientras validas que Grafana Tempo o Jaeger cubren el resto con la latencia que tu equipo necesita.

exporters:
  datadog:
    endpoint: "https://trace.agent.datadoghq.com"
    api:
      key: ${DD_API_KEY}
  prometheus:
    endpoint: "0.0.0.0:8889"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, filter/staging]
      exporters: [datadog]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

processors:
  filter/staging:
    traces:
      span:
        - 'attributes["deployment.environment"] == "staging"'