Preguntas de entrevista sobre Prometheus 2026: Prometheus vs Grafana vs Datadog comparados

Las preguntas de entrevista sobre Prometheus aparecen en casi todo proceso de DevOps y SRE, y suelen terminar en "¿por qué no Grafana o Datadog?". El candidato tiene que explicar cómo Prometheus recolecta y almacena métricas, escribir PromQL correcto y defender las concesiones frente a una plataforma administrada. Los entrevistadores usan este tema para distinguir la experiencia operativa real del conocimiento de manual. El módulo de entrevista sobre Prometheus y monitoreo reúne los mismos temas en forma de preguntas de práctica.

Preguntas de entrevista sobre Prometheus en rondas de DevOps y SRE

Estas son las preguntas específicas de Prometheus que aparecen con más frecuencia, junto con la respuesta que da un candidato con experiencia. Asumen Prometheus 3.x: la línea estable actual es la 3.15 (septiembre de 2026), con la 3.16 en release candidate.

P: ¿Por qué Prometheus obtiene las métricas por pull en lugar de recibir push?

El pull hace observable la salud de los targets: cada scrape genera una serie up, así que un target caído aparece como up == 0 en lugar de quedar en silencio. El servidor controla la frecuencia de scrape, lo que lo protege de un cliente que se comporta mal, y un target se puede revisar a mano abriendo su endpoint /metrics en el navegador. El costo es que Prometheus debe alcanzar cada target por la red. Por eso los jobs batch de corta duración necesitan el Pushgateway y las arquitecturas entre redes usan remote write.

P: ¿Cuáles son los cuatro tipos de métricas y cuándo un summary es la elección equivocada?

Counter (solo crece y se reinicia al reiniciar el proceso), gauge (sube y baja), histogram (observaciones contadas en buckets) y summary (cuantiles calculados en el cliente). Los cuantiles de un summary no se pueden agregar: promediar el p99 de diez pods no da el p99 del servicio. Los histogramas, en cambio, se suman primero entre instancias y se convierten en cuantil en el servidor, por eso son la opción por defecto para la latencia.

# Classic histogram: aggregate the buckets, keep the le label
histogram_quantile(0.99,
  sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

# Native histogram: no _bucket suffix, no le label
histogram_quantile(0.99,
  sum by (job) (rate(http_request_duration_seconds[5m])))

Olvidar le en la cláusula by de la forma clásica es el error de PromQL más común en rondas de live coding: la consulta no devuelve nada utilizable.

P: ¿Qué diferencia hay entre rate(), irate() e increase()?

rate() devuelve el promedio por segundo sobre toda la ventana y maneja los reinicios de counters. irate() usa solo las dos últimas muestras de la ventana: reacciona rápido pero es ruidoso, lo que sirve para un gráfico con zoom y no para alertar. increase() es rate() multiplicado por la duración de la ventana. Como Prometheus extrapola hasta los bordes de la ventana, increase() sobre un counter entero puede devolver un valor no entero, y a los entrevistadores les gusta preguntar por qué.

P: ¿Qué es la cardinalidad y cómo se diagnostica una explosión de cardinalidad?

Cada combinación única de nombre de métrica y valores de etiquetas es una serie temporal distinta que se mantiene en memoria. Una etiqueta como user_id, email o una ruta de URL cruda con IDs multiplica la cantidad de series hasta que el servidor se queda sin memoria. El diagnóstico empieza en la página de estado de la TSDB (/tsdb-status) o con una consulta:

# Top 10 metric names by number of series
topk(10, count by (__name__) ({__name__=~".+"}))

La corrección se hace en el origen: eliminar o reescribir la etiqueta con metric_relabel_configs, o definir sample_limit en el job de scrape para que un solo despliegue defectuoso no tumbe el servidor.

P: ¿Para qué sirven las recording rules?

Precalculan una expresión costosa en cada intervalo de evaluación y guardan el resultado como una nueva serie. Los dashboards y las alertas consultan después esa serie precalculada, que es barata. La convención de nombres es level:metric:operations:

groups:
  - name: api-recording-rules
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

P: ¿Qué hace la cláusula for en una regla de alerta?

Una alerta cuya expresión se vuelve verdadera pasa de inactive a pending, y solo llega a firing cuando la condición se mantiene durante el tiempo indicado en for. Así se filtran los picos de un solo scrape. keep_firing_for hace lo contrario: mantiene la alerta activa un tiempo después de que la condición desaparece, lo que evita que una alerta intermitente notifique dos veces.

P: ¿Cómo se logra alta disponibilidad con Prometheus?

Se ejecutan dos réplicas idénticas que scrapean los mismos targets, cada una con una external label replica distinta. Ambas envían alertas a un clúster de Alertmanager, que deduplica las notificaciones mediante su protocolo gossip. Para las consultas, Thanos Query o Mimir deduplican las dos series ignorando la etiqueta de réplica. Prometheus en sí no tiene clustering: la TSDB local de un servidor no se replica.

P: ¿Federación o remote write en arquitecturas multiclúster?

La federación permite que un Prometheus global scrapee series seleccionadas, por lo general agregadas, desde el endpoint /federate del Prometheus de cada clúster. Sirve para un conjunto pequeño de agregados. Remote write envía cada muestra a un almacenamiento central como Mimir, Thanos Receive o el backend de un proveedor, y es la respuesta estándar para consultas globales y retención a largo plazo.

P: ¿Cómo se detecta un target que desapareció del service discovery?

up == 0 solo se dispara mientras el target sigue descubierto. Si el pod o la entrada de service discovery ya no existe, la serie deja de existir y la alerta nunca se dispara. absent(up{job="api-server"}) cubre ese caso.

P: ¿Qué cambió en Prometheus 3?

Prometheus 3.0 (noviembre de 2024) trajo una nueva interfaz, permitió caracteres UTF-8 en nombres de métricas y etiquetas, y agregó un receptor OTLP integrado en /api/v1/otlp/v1/metrics, que se activa con --web.enable-otlp-receiver. Los histogramas nativos pasaron a estables en la 3.8. Desde la 3.9, el antiguo feature flag no hace nada y la ingestión requiere scrape_native_histograms: true en la configuración de scrape o global. La 3.15 estabilizó la codificación de chunks flotantes XOR2 y agregó el scrape de OpenMetrics 2.0.

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

Una vez cubiertos los fundamentos de Prometheus, los entrevistadores suelen pasar a las diferencias de arquitectura entre las tres herramientas.

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. La línea 3.x suma histogramas nativos estables, un receptor OTLP y Remote Write 2.0 para enviar muestras a un almacenamiento central.

Grafana no recolecta ni almacena métricas por sí misma. 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), que junto con Grafana forman el stack de código abierto LGTM. Grafana 13, anunciada en GrafanaCON en abril de 2026, dejó Git Sync para dashboards en disponibilidad general, activó los dashboards dinámicos por defecto y eliminó los comandos grafana-cli y grafana-server.

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 de Datadog. Todas las funciones, ingestión, almacenamiento, consulta, alertado y dashboards, residen dentro de una única plataforma administrada. El motor Watchdog marca anomalías de forma automática, sin configurar umbrales manualmente.

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

scrape_configs:
  - job_name: 'api-server'
    scrape_native_histograms: true
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

Este YAML define el modelo pull de Prometheus: descubre pods de Kubernetes mediante service discovery, conserva solo los que tienen la anotación prometheus.io/scrape: "true", reescribe la dirección hacia el puerto anotado y scrapea /metrics cada 15 segundos. La segunda regla une las dos etiquetas de origen con ;, por eso la regex coincide con host:port;port.

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.

# 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

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 (no built-in PromQL equivalent)
anomalies(avg:system.cpu.user{service:api-server}, 'agile', 3)

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

PromQL ofrece mayor expresividad para el análisis ad hoc. El lenguaje de Datadog cede parte de esa flexibilidad a cambio de funciones algorítmicas integradas como anomalies() (algoritmos basic, agile, robust) y forecast() (linear, seasonal), que en un stack de Prometheus requerirían herramientas externas.

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 recibe las alertas de las reglas que Prometheus evalúa en intervalos fijos y luego las enruta 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. La desventaja es la llamada threshold fatigue, ya que los valores estáticos suelen requerir ajustes estacionales.

Grafana Alerting (el sistema de alertado unificado, predeterminado desde Grafana 9) evalúa consultas sobre cualquier fuente de datos conectada y admite alertas multidimensionales con notification policies.

Datadog Monitors combina umbrales estáticos con monitores de anomalía, outlier y forecast. Watchdog detecta anomalías de rendimiento de forma automática, sin necesidad de crear reglas manuales. Esto reduce la carga de configuración, a costa de una menor transparencia en la lógica de detección.

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. Las cifras de Datadog que siguen son precios de lista con facturación anual.

Sobre el papel, el stack de código abierto parece más económico, pero requiere tiempo de ingeniería dedicado a upgrades, planificación de capacidad y configuración de alta disponibilidad. El modelo administrado de Datadog traslada esa carga al proveedor. 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.

Monitoreo de Kubernetes: profundidad de integración comparada

Prometheus es el sistema de métricas por defecto del ecosistema de Kubernetes, lo que lo convierte en el tema dominante de las entrevistas sobre monitoreo de 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. La sobrescritura de valores de un chart de esta manera se trata en detalle en la guía de entrevista sobre Helm charts.

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.

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.

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.x acepta métricas OTLP directamente una vez que se activa --web.enable-otlp-receiver, por lo que ya no se necesita un Collector como intermediario. 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 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.

Preguntas de entrevista sobre observabilidad que comparan las tres herramientas

Más allá de Prometheus, estas preguntas evalúan si el candidato sabe razonar entre herramientas. Cada respuesta destaca el concepto que el entrevistador busca comprobar.

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 % (la recolección por scrape puede perder muestras) y sistemas basados en eventos que necesitan recolección de tipo push (el Pushgateway existe, pero solo para jobs batch a nivel de servicio).

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 SRE Workbook 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.

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

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.

Fuentes

• Releases de Prometheus: la 3.15.0 (septiembre de 2026) estabiliza la codificación de chunks XOR2, agrega el scrape de OpenMetrics 2.0 y marca --log.level como obsoleto
• Especificación de histogramas nativos de Prometheus: estables desde la 3.8, scrape_native_histograms obligatorio desde la 3.9
• Novedades de Grafana 13.0: Git Sync en GA, dashboards dinámicos por defecto, breaking changes
• Precios de lista de Datadog: precios de infraestructura, APM y logs usados en la tabla de costos
• Funciones algorítmicas de Datadog: sintaxis de anomalies() y forecast()

Lo que hay que recordar para una entrevista de Prometheus u observabilidad

• Prometheus es el estándar para la recolección de métricas en entornos Kubernetes; pull frente a push, los cuatro tipos de métricas, rate() frente a irate(), la cardinalidad y la HA deben conocerse a fondo
• En Prometheus 3.9 y posteriores, los histogramas nativos solo se ingieren si se define scrape_native_histograms: true
• 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 detección de anomalías integrada, a costa de un precio más alto y un mayor vendor lock-in
• La adopción de OpenTelemetry vuelve menos definitiva la elección de backend: la instrumentación sigue igual sin importar qué herramienta almacena y consulta los datos
• En las entrevistas, conviene demostrar la capacidad de razonar sobre las concesiones (costo, control, complejidad) en lugar de defender una única herramienta
• Para una preparación más amplia, la guía de preguntas esenciales de entrevista DevOps cubre los temas adyacentes que los entrevistadores encadenan después del monitoreo