Cómo reducir tu factura de Datadog con OpenTelemetry

La factura que crece sola#

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 el clásico “yo lo advertí”. Si tu factura creció mucho más que tu infraestructura desde que empezaste, no eres un caso raro.

El patrón suele ser 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 la factura y descubres que observar tu infraestructura cuesta una fracción incómoda de lo que cuesta la infraestructura misma.

Esto 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 serie de métrica, por sesión) y eso crea un impuesto al crecimiento que golpea con fuerza a los equipos de tamaño medio. Esta guía explica de dónde sale el gasto y cómo usar OpenTelemetry para recuperar el control sin perder visibilidad.

Documentación: Datadog · Pricing ↗

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

Datadog no cobra una mensualidad simple. Factura por separado cada producto y cada dimensión, y esas dimensiones crecen a la vez cuando creces:

• Infraestructura: por host monitoreado.
• APM: por host con trazas, más el volumen de spans ingeridos e indexados por encima de lo incluido en el plan.
• Logs: se cobra la ingesta por GB y, aparte, la indexación por eventos según el periodo de retención. Un mismo log puede pagar dos veces.
• Métricas custom: cada combinación única de nombre de métrica y valores de tags cuenta como una métrica facturable. Un histograma o una distribución generan por defecto varias series por combinación. Por eso instrumentar con Prometheus u OpenTelemetry sin controlar etiquetas puede generar miles de series por servicio.
• RUM y otros productos: por sesiones o por volumen, según el producto.

El resultado es una factura que crece de forma super-lineal: añadir un servicio no solo añade un host, añade spans, logs y, sobre todo, nuevas combinaciones de tags. En la mayoría de los equipos, APM y logs son las líneas más pesadas, y esa observación define la estrategia: empieza por donde se concentra el gasto en tu propia factura. Los precios cambian con frecuencia, así que consulta siempre la página oficial de precios y el detalle de uso de tu cuenta.

Documentación: Datadog · Pricing ↗ · Datadog · Facturación de métricas custom ↗ · Datadog · Facturación de APM ↗ · Datadog · Índices de logs y filtros de exclusión ↗

La IA infla la telemetría#

Hay una variable nueva que está rompiendo presupuestos: las cargas de trabajo con IA. Una sola petición de inferencia puede producir trazas de varios pasos (recuperación de contexto, llamadas al modelo, herramientas, reintentos), atributos de alta cardinalidad como identificadores de modelo o de prompt, conteos de tokens que conviene rastrear por costo y métricas de evaluación nuevas.

Cada una de esas cosas es una dimensión más que tu plataforma de observabilidad puede cobrarte: más spans por petición, más series por cada tag nuevo, más GB de logs con prompts y respuestas. Si añades monitoreo de LLMs sin decidir antes qué atributos necesitas de verdad y con qué muestreo, la factura lo reflejará rápido.

La regla que aplica aquí es la misma que en el resto de la guía: si tu observabilidad cuesta más que el valor de lo que te permite decidir, algo se rompió. Define qué preguntas quieres responder sobre tus cargas de IA y recoge solo la telemetría que las responde.

Documentación: Datadog · Facturación de métricas custom ↗ · OpenTelemetry · Muestreo ↗

La salida no es tirar Datadog: es un modelo híbrido#

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 funciona es un modelo híbrido. Conservas Datadog para lo que de verdad aprovechas (típicamente la experiencia de APM, dashboards y alertas en flujos críticos) y mueves el volumen de bajo valor a backends más baratos, como Grafana Loki para logs, Grafana Tempo o Jaeger para trazas, y Grafana Mimir o VictoriaMetrics para métricas.

La pieza que lo hace posible es OpenTelemetry. Es un estándar abierto e independiente del proveedor para generar, recoger y exportar trazas, métricas y logs. Instrumentas una sola vez con sus SDK y su protocolo OTLP, y el OpenTelemetry Collector decide después a dónde va cada señal. Cambiar de destino es cambiar la configuración del colector, no el código de la aplicación.

Los logs suelen ser lo primero que se mueve, por dos razones: suelen estar entre las líneas más caras de la factura y, emitidos vía OpenTelemetry, son los más fáciles de redirigir. Loki acepta OTLP de forma nativa, así que basta con apuntar un exporter a su endpoint. Mantén el trace_id como campo del log para poder correlacionarlo con las trazas.

Documentación: OpenTelemetry · Qué es OpenTelemetry ↗ · OpenTelemetry · Configuración del Collector ↗ · Grafana Loki · Ingesta de logs con OpenTelemetry ↗

Un colector que decide a dónde va cada señal#

El siguiente ejemplo muestra un OpenTelemetry Collector (distribución contrib) que envía todas las trazas a Tempo, solo una muestra de las de producción a Datadog, las métricas de aplicación a Mimir y los logs, sin DEBUG, a Loki.

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 20
  batch: {}
  # No pagues en Datadog los spans de staging (siguen yendo a Tempo)
  filter/no-staging:
    error_mode: ignore
    trace_conditions:
      - resource.attributes["deployment.environment.name"] == "staging"
  # Envía a Datadog solo una muestra de los spans de producción
  probabilistic_sampler:
    sampling_percentage: 20
  # Descarta logs DEBUG antes de enviarlos a cualquier destino
  filter/no-debug:
    error_mode: ignore
    log_conditions:
      - log.severity_number < SEVERITY_NUMBER_INFO

connectors:
  # Calcula las métricas de APM (hits, errores, latencia) con el 100 % de las trazas
  datadog/connector: {}

exporters:
  datadog:
    api:
      site: datadoghq.com
      key: ${env:DD_API_KEY}
  otlp/tempo:
    endpoint: tempo:4317
    tls: { insecure: true }
  otlphttp/loki:
    endpoint: http://loki:3100/otlp
  otlphttp/mimir:
    endpoint: http://mimir:8080/otlp

service:
  pipelines:
    traces/all:              # todas las trazas, sin muestrear, a Tempo
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]
    traces/datadog-in:       # producción hacia el connector (sin muestreo)
      receivers: [otlp]
      processors: [memory_limiter, filter/no-staging]
      exporters: [datadog/connector]
    traces/datadog-out:      # muestra hacia Datadog
      receivers: [datadog/connector]
      processors: [probabilistic_sampler]
      exporters: [datadog]
    metrics/apm-stats:
      receivers: [datadog/connector]
      exporters: [datadog]
    metrics:                 # métricas de aplicación a Mimir
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/mimir]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, filter/no-debug, batch]
      exporters: [otlphttp/loki]

Tres detalles marcan la diferencia entre ahorrar y romper la observabilidad:

• Calcula las métricas de APM antes de muestrear. Si muestreas las trazas antes de que Datadog las vea, las tasas de peticiones, errores y latencias de APM se calculan sobre una fracción del tráfico. El Datadog Connector resuelve esto: recibe el 100 % de las trazas, calcula esas estadísticas y reenvía después la muestra.
• Filtra por atributos de recurso estándar. La convención semántica actual es deployment.environment.name; si tus servicios todavía emiten deployment.environment, ajusta la condición.
• Protege el propio colector. El memory_limiter debe ir primero en cada pipeline para que un pico de telemetría no tumbe el colector.

El muestreo probabilístico es simple, pero no distingue trazas interesantes. Si necesitas conservar siempre las trazas con error o las más lentas, usa tail sampling, que decide cuando la traza está completa; a cambio, exige que todos los spans de una traza lleguen a la misma instancia del colector.

Documentación: OpenTelemetry · Configuración del Collector ↗ · Datadog · OpenTelemetry Collector y Datadog Exporter ↗ · OpenTelemetry Collector Contrib · Datadog Connector ↗ · OpenTelemetry Collector Contrib · Filter processor ↗ · OpenTelemetry Collector Contrib · Tail sampling processor ↗ · OpenTelemetry · Muestreo ↗ · Grafana Tempo · Documentación ↗ · Grafana Mimir · Configurar el OpenTelemetry Collector ↗

Plan de acción: qué mover y en qué orden#

No migres por entusiasmo; migra por retorno. Ataca primero lo que tiene costo alto y esfuerzo bajo, y deja para el final lo que exige más trabajo o donde la herramienta cara realmente brilla.

• Mapea tus dimensiones facturables. Abre el detalle de uso de tu cuenta de Datadog y clasifica cada línea: hosts, spans ingeridos e indexados, GB de logs ingeridos, eventos indexados, métricas custom, sesiones de RUM. Identifica cuáles crecen más rápido que tu infraestructura.
• Aplica primero las palancas que no requieren migrar. Filtros de exclusión en los índices de logs, controles de ingesta de APM y Metrics without Limits para decidir qué tags se indexan pueden recortar gasto sin mover nada de sitio.
• Deriva los logs de baja prioridad. Logs de debug, health checks y ruido de desarrollo no necesitan indexarse en Datadog. Envíalos a Loki manteniendo el trace_id para la correlación.
• Controla la cardinalidad de las métricas. Cada etiqueta de alta cardinalidad (IDs de usuario, de petición, URLs completas) multiplica las series. Elimínala en el colector o redirige esas métricas a Mimir o VictoriaMetrics.
• Muestrea trazas. No necesitas el 100 % de los spans para entender la salud de un servicio, siempre que las métricas de APM se calculen antes de muestrear.
• Mantén las trazas críticas en Datadog hasta validar la alternativa. Deja los flujos de pago y los servicios core en Datadog mientras compruebas que Tempo o Jaeger cubren el resto con la experiencia que tu equipo necesita.

Empezar por logs y cardinalidad suele recuperar la mayor parte del ahorro con el menor riesgo, y muchas veces nadie nota la diferencia en los dashboards.

Documentación: Datadog · Detalle de uso (Plan and Usage) ↗ · Datadog · Índices de logs y filtros de exclusión ↗ · Datadog · Controles de ingesta de APM ↗ · Datadog · Metrics without Limits ↗ · VictoriaMetrics · Integración con OpenTelemetry ↗

Todo en Datadog vs. stack híbrido con OpenTelemetry#

El stack abierto no es gratis: mueve el gasto de licencias a infraestructura y horas de ingeniería. La decisión correcta depende de cuánto pagas hoy por volumen de bajo valor y de si tu equipo puede operar esos componentes, o pagar su versión gestionada.

Documentación: Datadog · Facturación de métricas custom ↗ · Grafana Loki · Ingesta de logs con OpenTelemetry ↗ · Grafana Tempo · Documentación ↗ · Grafana Mimir · Configurar el OpenTelemetry Collector ↗

Cuándo sí quedarte en Datadog#

Seamos justos: hay casos donde una factura alta está justificada. Si eres una organización grande, 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 es trabajo de ingeniería real y continuo.

Donde el cálculo cambia es en el mid-market: un equipo mediano con unas decenas de microservicios en Kubernetes rara vez necesita pagar precio completo por cada log de debug, cada span de staging y cada combinación de tags. En ese caso, el ecosistema abierto sobre OpenTelemetry está maduro para producción, y la pregunta deja de ser “¿puedo?” para convertirse en “¿qué muevo primero?”.

Documentación: OpenTelemetry · Qué es OpenTelemetry ↗

El resumen en una línea#

Instrumenta con OpenTelemetry para no quedar atado a ningún proveedor. Usa primero las palancas de Datadog que no requieren migrar, mueve los logs de bajo valor, controla cardinalidad y muestreo en el colector, 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.