Prometheus vs Grafana vs Datadog en 2026: comparativa de monitoreo y preguntas de entrevista DevOps

En casi toda entrevista de DevOps o SRE surge tarde o temprano la pregunta por la diferencia entre Prometheus, Grafana y Datadog. Quien no solo conoce estas tres herramientas de forma superficial, sino que puede explicar con fundamento su arquitectura, sus fortalezas y sus concesiones, se distingue con claridad del resto de los candidatos. Este artículo contrasta las diferencias centrales, analiza los respectivos lenguajes de consulta y enfoques de alertado, y prepara para las preguntas de entrevista más habituales sobre monitoreo.

Arquitectura y modelo de datos: cómo maneja cada herramienta las métricas

Las diferencias arquitectónicas entre estas tres herramientas son fundamentales, y los entrevistadores indagan con frecuencia en este tema para medir la profundidad del conocimiento técnico del candidato.

Prometheus se basa en un modelo de tipo pull. El servidor consulta endpoints HTTP (por lo general /metrics) en intervalos configurables y almacena los datos de series temporales en una TSDB local propia. Cada serie temporal se identifica mediante un nombre de métrica y un conjunto de etiquetas clave-valor. Prometheus 3.0, publicado en noviembre de 2024, alcanzó con la versión 3.8 el estado estable de los histogramas nativos, incorporó la ingestión OTLP de forma nativa y sumó Remote Write 2.0 para mejorar la federación entre clústeres.

Grafana no recolecta ni almacena métricas por sí misma. En cambio, se conecta a fuentes de datos -- entre ellas Prometheus, Loki, Tempo, InfluxDB, Elasticsearch y más de 100 adicionales -- y renderiza dashboards a partir de esos datos. Grafana Labs mantiene además Mimir (almacenamiento de métricas a largo plazo), Loki (agregación de logs) y Tempo (trazas distribuidas). En conjunto, estos componentes forman el llamado stack LGTM, una plataforma de observabilidad de código abierto completa. La versión 13, aparecida en mayo de 2026, introdujo herramientas de observability-as-code, Git Sync para dashboards y SQL Expressions para consultas entre fuentes.

Datadog funciona como un servicio SaaS de tipo push. Los agentes instalados en los hosts envían métricas, logs y trazas al backend en la nube. Todas las funciones -- ingestión, almacenamiento, consulta, alertado y dashboards -- residen dentro de una única plataforma administrada. El motor de ML Watchdog realiza la detección de anomalías de forma automática, sin necesidad de definir umbrales manualmente.

La siguiente configuración de Prometheus ilustra el modelo pull a partir de una integración con Kubernetes:

# prometheus.yml - Pull-based scrape configuration
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'api-server'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        target_label: __address__
        regex: (.+)
        replacement: ${1}:${2}

Este YAML define el modelo pull: los pods de Kubernetes se descubren automáticamente mediante service discovery y sus endpoints /metrics se consultan cada 15 segundos. Las reglas relabel_configs controlan qué pods se scrapean y en qué puerto están disponibles las métricas. Datadog, en contraste, solo requiere instalar un agente como DaemonSet, ya que la configuración se realiza de forma centralizada desde la interfaz web.

PromQL frente al lenguaje de consulta de Datadog

Los lenguajes de consulta son uno de los temas técnicos más frecuentes en entrevistas de monitoreo. Se espera que el candidato domine con fluidez al menos uno y sepa explicar las concesiones entre ambos.

PromQL (Prometheus Query Language) es el estándar en todo el ecosistema de Prometheus y Grafana. El lenguaje admite instant vectors, range vectors, operadores de agregación y recording rules. Su capacidad expresiva permite análisis ad hoc complejos, aunque exige una curva de aprendizaje considerable.

# Request rate per service over 5 minutes
rate(http_requests_total{job="api-server"}[5m])

# 99th percentile latency using native histograms
histogram_quantile(0.99, rate(http_request_duration_seconds[5m]))

# Error rate as percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

# Predict disk full in 4 hours using linear regression
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0

La función rate() calcula la tasa media de cambio de un counter dentro de una ventana temporal. En las entrevistas se pregunta con regularidad por la diferencia entre rate() (tasa suavizada sobre toda la ventana) e irate() (tasa instantánea basada en los dos últimos puntos de datos). La función predict_linear(), por su parte, permite anticipar mediante regresión lineal cuándo se agotará un recurso, un escenario típico de capacity planning.

El lenguaje de consulta de Datadog adopta un enfoque distinto, construido en torno a llamadas a funciones y scoping:

# Equivalent request rate in Datadog
sum:http.requests{service:api-server}.as_rate()

# Anomaly detection (Watchdog ML - no equivalent in PromQL)
anomaly(avg:system.cpu.user{service:api-server}, 'agile', 3)

# Forecast query
forecast(avg:system.disk.free{host:web-01}, 'linear', 1)

La diferencia central radica en el alcance funcional: PromQL ofrece mayor expresividad para operaciones matemáticas y análisis ad hoc. El lenguaje de Datadog cede parte de esa flexibilidad a cambio de funciones de ML integradas como anomaly() y forecast(), que en un stack de Prometheus requerirían herramientas externas adicionales. En la entrevista, quien explica con precisión la semántica de rate() en PromQL y a la vez conoce los límites de ambos lenguajes demuestra experiencia práctica real.

Estrategias de alertado: basadas en reglas frente a detección con ML

La filosofía de alertado difiere de forma marcada entre las herramientas, y comprender estas diferencias transmite madurez operativa en una entrevista.

Prometheus Alertmanager evalúa reglas en intervalos fijos y enruta las alertas a través de una pipeline configurable con grouping, silencing e inhibition:

# alert-rules.yml - Prometheus alerting rules
groups:
  - name: api-server-alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5..",job="api-server"}[5m]))
          / sum(rate(http_requests_total{job="api-server"}[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "API error rate above 5% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/high-error-rate"

      - alert: PodMemoryPressure
        expr: |
          container_memory_working_set_bytes{namespace="production"}
          / container_spec_memory_limit_bytes{namespace="production"} > 0.9
        for: 10m
        labels:
          severity: warning

Este enfoque exige definir umbrales de forma explícita. La ventaja es la transparencia total: cada alerta cuenta con una expresión revisable que puede auditarse en code reviews. La desventaja es la llamada threshold fatigue -- los valores estáticos suelen requerir ajustes ante patrones estacionales y el crecimiento de la infraestructura, algo que se vuelve cada vez más costoso al gestionar cientos de servicios.

Grafana Alerting, unificado desde Grafana 12+, evalúa consultas sobre cualquier fuente de datos conectada y admite alertas multidimensionales con notification policies. Desde la versión 13 las definiciones de alerta pueden versionarse como código y gestionarse mediante Git Sync, lo que simplifica de forma notable los flujos de trabajo de infrastructure-as-code.

Datadog Monitors combina umbrales estáticos con monitores de anomalía, outlier y forecast impulsados por ML. Watchdog detecta anomalías de rendimiento de forma automática, sin necesidad de crear reglas manuales. Esto reduce de manera considerable la carga de configuración, aunque a costa de una menor transparencia en la lógica de detección. En sectores regulados como las finanzas o la salud esto puede resultar problemático, ya que los auditores esperan reglas de alertado documentadas y trazables.

Costos y costo total de propiedad (TCO) en 2026

El precio es un factor decisivo en la elección real de herramientas y aparece con frecuencia en entrevistas de system design. Comprender las estructuras de costos demuestra conciencia de negocio.

| Dimensión | Prometheus + Grafana | Datadog | |-----------|---------------------|--------| | Licencia | Gratis (AGPL / Apache 2.0) | 15-31 USD/host/mes (anual) | | Almacenamiento de métricas | Autogestionado (Mimir/Thanos) | Incluido, precio según retención | | Gestión de logs | Loki (self-hosted) | 0,10 USD/GB ingerido + indexación | | APM / Trazas | Tempo (self-hosted) | 31 USD/host/mes | | Costo de infraestructura | Cómputo + almacenamiento del stack | Ninguno (SaaS) | | Carga operativa | Alta (upgrades, escalado, HA) | Mínima | | Costo anual típico (50 hosts) | 20.000-60.000 USD (infra + ingeniería) | 50.000-150.000 USD | | Riesgo de vendor lock-in | Bajo (OpenTelemetry, PromQL) | Mayor (lenguaje de consulta propietario) |

Sobre el papel, el stack de código abierto parece más económico, pero requiere tiempo de ingeniería dedicado a mantenimiento, upgrades, planificación de capacidad y configuración de alta disponibilidad. El modelo administrado de Datadog traslada esa carga al proveedor. La experiencia indica que, para equipos con menos de cinco ingenieros de infraestructura, las soluciones administradas suelen tener un costo total menor una vez que se contabiliza el tiempo de ingeniería.

Un aspecto que a menudo se pasa por alto es la facturación high-watermark de Datadog: la cantidad de hosts se mide cada hora, se descarta el 1 % superior de las horas y se factura según el pico del percentil 99. Los picos temporales de auto-scaling -- por ejemplo, durante el tráfico de Black Friday -- inflan la factura mensual incluso después de que las instancias ya hayan sido terminadas.

Monitoreo de Kubernetes: profundidad de integración comparada

Más del 80 % de los clústeres de Kubernetes utilizan Prometheus para la recolección de métricas, lo que convierte a este tema en prácticamente ineludible en entrevistas sobre orquestación de contenedores.

Prometheus + Grafana se integra de forma nativa mediante el Helm chart kube-prometheus-stack. Este chart despliega Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics y dashboards de Grafana preconfigurados en una única instalación:

# Deploy full monitoring stack on Kubernetes
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

Este comando despliega un stack de monitoreo listo para producción, con almacenamiento persistente y una retención de datos de 30 días. El Prometheus Operator emplea Custom Resource Definitions (ServiceMonitor, PodMonitor) para configurar los scrape targets de forma declarativa. Así, los equipos pueden crear por sí mismos configuraciones de monitoreo para sus servicios sin necesitar acceso a la configuración central de Prometheus, una ventaja organizativa considerable en empresas grandes.

Datadog despliega un DaemonSet de agentes y un Cluster Agent. El Cluster Agent centraliza la comunicación con el API server de Kubernetes y reduce así la carga sobre la API. La vista Live Containers ofrece visibilidad en tiempo real del estado de los pods, y el Orchestrator Explorer mapea las relaciones entre deployments, services y pods. La puesta en marcha es más sencilla, aunque genera una dependencia de un servicio SaaS externo.

Para los equipos ya afianzados en el ecosistema de Kubernetes, el enfoque nativo de Prometheus evita introducir una dependencia externa. Los equipos que priorizan una configuración rápida con menor inversión operativa se inclinan más bien por Datadog o Grafana Cloud.

OpenTelemetry y neutralidad de proveedor

OpenTelemetry (OTel) se ha consolidado como el estándar de la industria para la instrumentación de aplicaciones. En las entrevistas se pregunta cada vez más por el papel de OTel en el contexto de las comparativas de monitoreo.

Prometheus 3.0+ acepta métricas OTLP de forma nativa, sin necesidad de un Collector como capa intermedia. Grafana Alloy, sucesor de Grafana Agent, funciona a la vez como OTel Collector y como scraper de Prometheus. Datadog admite la ingestión OTLP, pero recomienda sus agentes propietarios para acceder al "conjunto completo de funciones", una forma de vendor lock-in blando.

La relevancia estratégica de OTel radica en desacoplar la instrumentación de la elección de backend. El código de aplicación instrumentado con SDK de OTel puede enviar telemetría a Prometheus, Grafana Cloud, Datadog o cualquier otro backend compatible sin cambios en el código. Esta flexibilidad es un argumento sólido en entrevistas de system design, sobre todo al discutir estrategias de observabilidad a largo plazo. Quien sabe explicar por qué es preferible OTLP frente a las integraciones propietarias demuestra visión arquitectónica.

Preguntas de entrevista DevOps sobre monitoreo y observabilidad

Las siguientes preguntas aparecen con regularidad en entrevistas de DevOps y SRE. Cada respuesta destaca los conceptos que los entrevistadores buscan evaluar.

P: ¿Qué diferencia hay entre monitoreo, observabilidad y alertado?

El monitoreo sigue métricas predefinidas y verifica modos de fallo conocidos. La observabilidad permite investigar modos de fallo desconocidos a través de métricas, logs y trazas (los "tres pilares"). El alertado dispara notificaciones cuando las condiciones superan umbrales definidos o líneas base de anomalía. El monitoreo responde a la pregunta "¿el sistema está sano?", mientras que la observabilidad responde a "¿por qué el sistema no está sano?".

P: ¿En qué escenarios Prometheus no sería una buena elección?

Prometheus está optimizado para la fiabilidad por encima de la durabilidad: prioriza la disponibilidad del propio sistema de monitoreo. Escenarios en los que Prometheus llega a sus límites: almacenamiento a largo plazo más allá de 30 días (requiere Thanos, Mimir o Cortex), datos de facturación por petición que exigen una precisión del 100 % (Prometheus puede descartar muestras bajo carga) y sistemas basados en eventos que necesitan recolección de tipo push (aunque el pushgateway existe como solución alternativa).

P: ¿Cómo influye la filosofía "Big Tent" de Grafana en la arquitectura de observabilidad?

Grafana se conecta a cualquier fuente de datos sin exigir una migración de datos. Esto significa que un equipo puede consultar Prometheus, Elasticsearch, CloudWatch y Datadog desde un único dashboard. La concesión reside en la complejidad operativa: mantener varios backends exige más experiencia en infraestructura que un enfoque de un solo proveedor. Los entrevistadores evalúan si el candidato es capaz de articular esta concesión con claridad.

P: ¿Qué es la facturación high-watermark de Datadog y por qué importa?

Datadog mide la cantidad de hosts cada hora, descarta el 1 % superior de las horas y factura según el pico del percentil 99. Esto implica que los picos temporales de auto-scaling (por ejemplo, el tráfico de Black Friday) inflan la factura mensual incluso después de que las instancias hayan sido terminadas. Quien menciona este detalle demuestra experiencia operativa real en gestión de costos, algo que los roles de SRE exigen cada vez más.

P: ¿Cómo se diferenciaría una estrategia de alertado basada en SLO entre Prometheus y Datadog?

En Prometheus, el alertado basado en SLO utiliza recording rules para precalcular error budgets y alertas de burn rate (el enfoque multi-window, multi-burn-rate del libro de SRE de Google). Datadog ofrece widgets y monitores de SLO integrados que siguen la burn rate de forma automática. Ambos enfoques implementan el mismo concepto, pero Prometheus requiere más configuración manual, mientras que Datadog proporciona un flujo de trabajo administrado. En una buena respuesta conviene nombrar de forma concreta las ventanas de burn rate (1h, 6h, 3d) y las tasas de consumo del error budget.

Para una preparación más profunda en temas de monitoreo, el módulo de entrevista sobre Prometheus y monitoreo cubre escenarios adicionales con explicaciones detalladas.

Marco de decisión: cómo elegir el stack adecuado

| Escenario | Stack recomendado | Justificación | |----------|------------------|----------| | Startup con menos de 10 ingenieros | Datadog o Grafana Cloud | Minimizar la carga operativa | | Organización grande con equipo de plataforma | Prometheus + Grafana + Loki | Control total, menor costo unitario a escala | | Multi-cloud / híbrido | Prometheus + Grafana | Neutral respecto al proveedor, consistente entre entornos | | Sector con fuerte cumplimiento (finanzas, salud) | Prometheus + Grafana self-hosted | Los datos permanecen dentro de la organización | | Escalado rápido, crecimiento impredecible | Grafana Cloud (Mimir administrado) | Escala sin gestión de infraestructura | | Necesidad de detección de anomalías con ML | Datadog | Watchdog no requiere configuración |

La elección correcta depende de tres variables: el tamaño del equipo, la madurez operativa y las restricciones de presupuesto. No existe una respuesta universalmente correcta, y los entrevistadores esperan que el candidato razone sobre las concesiones en lugar de proclamar un ganador.

Conclusión

• Prometheus es el estándar de facto para la recolección de métricas en entornos Kubernetes; la versión 3.x aporta en 2026 soporte OTLP nativo e histogramas nativos estables
• Grafana es una capa de visualización, no una base de datos de métricas -- se conecta a más de 100 fuentes de datos, incluida Prometheus, y el stack LGTM (Loki, Grafana, Tempo, Mimir) forma una plataforma de observabilidad de código abierto completa
• Datadog ofrece el camino más rápido hacia la observabilidad full-stack con alertado impulsado por ML, a costa de un precio más alto y un mayor vendor lock-in
• La adopción de OpenTelemetry desacopla la instrumentación de la elección de backend y vuelve menos definitiva la decisión por una herramienta concreta
• La gestión de la cardinalidad es un aspecto operativo crítico en entornos Prometheus y un tema recurrente en entrevistas
• En las entrevistas, conviene demostrar la capacidad de razonar sobre las concesiones (costo, control, complejidad) en lugar de defender una única herramienta como solución universal
• Para una preparación práctica, resulta útil el módulo de preguntas de entrevista DevOps y profundizar en temas adyacentes como los conceptos de pipelines CI/CD