Perguntas de Entrevista sobre Prometheus 2026: Prometheus vs Grafana vs Datadog Comparados

Perguntas de entrevista sobre Prometheus aparecem em praticamente todo processo de DevOps e SRE, quase sempre seguidas de "por que não Grafana ou Datadog?". O candidato precisa explicar como o Prometheus coleta e armazena métricas, escrever PromQL correto e defender os compromissos em relação a uma plataforma gerenciada. Os entrevistadores usam esse tema para separar experiência operacional real de conhecimento de manual. O módulo de entrevista sobre Prometheus e monitoramento traz os mesmos temas em formato de perguntas de treino.

Perguntas de Entrevista sobre Prometheus em Rodadas de DevOps e SRE

Estas são as perguntas específicas de Prometheus que aparecem com mais frequência, com a resposta que um candidato seguro dá. Elas pressupõem o Prometheus 3.x: a linha estável atual é a 3.15 (setembro de 2026), com a 3.16 em release candidate.

P: Por que o Prometheus busca métricas por pull em vez de receber push?

O pull torna a saúde dos targets observável: cada scrape gera uma série up, então um target fora do ar aparece como up == 0 em vez de simplesmente sumir. O servidor controla a frequência de scrape, o que o protege de um cliente com mau comportamento, e qualquer target pode ser verificado manualmente abrindo o endpoint /metrics no navegador. O custo é que o Prometheus precisa alcançar cada target pela rede. Por isso jobs batch de curta duração dependem do Pushgateway e arquiteturas entre redes usam remote write.

P: Quais são os quatro tipos de métrica e quando um summary é a escolha errada?

Counter (só cresce e zera quando o processo reinicia), gauge (sobe e desce), histogram (observações contadas em buckets) e summary (quantis calculados no cliente). Os quantis de um summary não podem ser agregados: a média do p99 de dez pods não é o p99 do serviço. Histogramas podem ser somados entre instâncias primeiro e convertidos em quantil no servidor, e por isso são o padrão para latência.

# 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])))

Esquecer o le na cláusula by da forma clássica é o erro de PromQL mais comum em rodadas de live coding: a consulta não retorna nada aproveitável.

P: Qual a diferença entre rate(), irate() e increase()?

rate() retorna a média por segundo sobre toda a janela e trata reinicializações de counters. irate() usa apenas as duas últimas amostras da janela, então reage rápido mas é ruidoso: serve para um gráfico com zoom e não para alertas. increase() é rate() multiplicado pela duração da janela. Como o Prometheus extrapola até as bordas da janela, increase() sobre um counter inteiro pode retornar um valor não inteiro, e os entrevistadores gostam de perguntar o porquê.

P: O que é cardinalidade e como diagnosticar uma explosão de cardinalidade?

Cada combinação única de nome de métrica e valores de labels é uma série temporal separada mantida em memória. Um label como user_id, email ou um caminho de URL bruto contendo IDs multiplica a quantidade de séries até o servidor ficar sem memória. O diagnóstico começa na página de status do TSDB (/tsdb-status) ou com uma consulta:

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

A correção é feita na origem: remover ou reescrever o label com metric_relabel_configs, ou definir sample_limit no job de scrape para que um único deploy problemático não derrube o servidor.

P: Para que servem as recording rules?

Elas pré-calculam uma expressão cara a cada intervalo de avaliação e armazenam o resultado como uma nova série. Dashboards e alertas passam a consultar essa série pré-calculada, que é barata. A convenção de nomes é level:metric:operations:

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

P: O que faz a cláusula for em uma regra de alerta?

Um alerta cuja expressão se torna verdadeira passa de inactive para pending, e só chega a firing quando a condição se mantém pela duração definida em for. Isso filtra oscilações de um único scrape. keep_firing_for faz o inverso: mantém o alerta disparado por um tempo depois que a condição desaparece, o que impede que um alerta instável acione o plantão duas vezes.

P: Como deixar o Prometheus altamente disponível?

Rodam-se duas réplicas idênticas fazendo scraping dos mesmos targets, cada uma com um external label replica distinto. Ambas enviam alertas para um cluster de Alertmanager, que deduplica as notificações pelo protocolo gossip. Nas consultas, Thanos Query ou Mimir deduplicam as duas séries ignorando o label de réplica. O Prometheus em si não tem clustering: o TSDB local de um servidor não é replicado.

P: Federação ou remote write em ambientes multicluster?

A federação permite que um Prometheus global faça scraping de séries selecionadas, geralmente agregadas, no endpoint /federate do Prometheus de cada cluster. Ela atende a um conjunto pequeno de agregados. O remote write envia cada amostra para um armazenamento central como Mimir, Thanos Receive ou o backend de um fornecedor, e é a resposta padrão para consultas globais e retenção de longo prazo.

P: Como detectar um target que sumiu do service discovery?

up == 0 só dispara enquanto o target ainda é descoberto. Se o pod ou a entrada de service discovery deixou de existir, a série deixa de existir e o alerta nunca dispara. absent(up{job="api-server"}) cobre esse caso.

P: O que mudou no Prometheus 3?

O Prometheus 3.0 (novembro de 2024) trouxe uma nova interface, passou a aceitar caracteres UTF-8 em nomes de métricas e labels e adicionou um receptor OTLP embutido em /api/v1/otlp/v1/metrics, habilitado com --web.enable-otlp-receiver. Os histogramas nativos se tornaram estáveis na 3.8. Desde a 3.9, o antigo feature flag não faz mais nada e a ingestão exige scrape_native_histograms: true na configuração de scrape ou global. A 3.15 estabilizou a codificação de chunks float XOR2 e adicionou o scraping de OpenMetrics 2.0.

Arquitetura e Modelo de Dados: Como Cada Ferramenta Lida com Métricas

Depois dos fundamentos de Prometheus, os entrevistadores costumam passar para as diferenças de arquitetura entre as três ferramentas.

Prometheus adota um modelo baseado em pull. O servidor faz scraping de endpoints HTTP (normalmente /metrics) em intervalos configuráveis e armazena os dados de séries temporais em um TSDB local próprio. Cada série temporal é identificada por um nome de métrica e um conjunto de labels no formato chave-valor. A linha 3.x traz histogramas nativos estáveis, um receptor OTLP e o Remote Write 2.0 para enviar amostras a um armazenamento central.

Grafana não coleta nem armazena métricas. Ele se conecta a fontes de dados, como Prometheus, Loki, Tempo, InfluxDB, Elasticsearch e mais de 100 outras, e renderiza dashboards a partir desses dados. A Grafana Labs também mantém o Mimir (armazenamento de métricas de longo prazo), o Loki (agregação de logs) e o Tempo (distributed tracing), que junto com o Grafana formam a stack open source LGTM. O Grafana 13, anunciado na GrafanaCON em abril de 2026, deixou o Git Sync para dashboards em disponibilidade geral, ativou os dashboards dinâmicos por padrão e removeu os comandos grafana-cli e grafana-server.

Datadog opera como um SaaS baseado em push. Agentes instalados nos hosts enviam métricas, logs e traces para o backend em nuvem do Datadog. Tudo, ingestão, armazenamento, consulta, alertas e dashboards, vive dentro de uma única plataforma gerenciada. O mecanismo Watchdog sinaliza anomalias automaticamente, sem configuração manual de limiares.

# 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__

Esse YAML define o modelo de pull do Prometheus: ele descobre pods do Kubernetes via service discovery, mantém apenas os anotados com prometheus.io/scrape: "true", reescreve o endereço para a porta anotada e faz scraping de /metrics a cada 15 segundos. A segunda regra junta os dois labels de origem com ;, e é por isso que a regex casa com host:port;port.

PromQL vs Linguagem de Consulta do Datadog: Sintaxe e Recursos

As linguagens de consulta são um tema recorrente em entrevistas. Espera-se que o candidato domine fluentemente ao menos uma delas e saiba explicar os compromissos entre elas.

PromQL (Prometheus Query Language) é o padrão para consultas de métricas em todo o ecossistema Prometheus e Grafana. A linguagem oferece suporte a instant vectors, range vectors, operadores de agregação e 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

A linguagem de consulta do Datadog segue uma abordagem diferente, construída em torno de funções e escopo:

# 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)

O PromQL oferece maior poder de expressão para análises ad hoc. A linguagem do Datadog troca parte dessa flexibilidade por funções algorítmicas embutidas como anomalies() (algoritmos basic, agile, robust) e forecast() (linear, seasonal), que exigiriam ferramentas externas em uma stack baseada em Prometheus.

Estratégias de Alerta: Baseadas em Regras vs Detecção com ML

A filosofia de alerta difere de forma acentuada entre essas ferramentas, e compreender essas diferenças demonstra maturidade operacional em entrevistas.

Prometheus Alertmanager recebe os alertas gerados pelas regras que o Prometheus avalia em intervalos fixos e os roteia por meio de um pipeline configurável, com 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

Essa abordagem exige que os operadores definam limiares explícitos. A vantagem é a transparência total: todo alerta possui uma expressão auditável. A desvantagem é a chamada threshold fatigue, já que valores estáticos frequentemente precisam de ajustes sazonais.

Grafana Alerting (o sistema de alertas unificado, padrão desde o Grafana 9) avalia consultas sobre qualquer fonte de dados conectada e oferece suporte a alertas multidimensionais com notification policies.

Datadog Monitors combinam limiares estáticos com monitores de anomalia, outlier e forecast. O Watchdog sinaliza anomalias de desempenho automaticamente, sem a necessidade de criar regras manuais. Isso reduz a sobrecarga de configuração, mas ao custo de menor transparência na lógica de detecção.

Preços e Custo Total de Propriedade em 2026

O preço é um fator decisivo na seleção de ferramentas no mundo real e aparece com frequência em entrevistas de system design. Compreender as estruturas de custo demonstra consciência de negócio. Os valores do Datadog abaixo são preços de tabela com cobrança anual.

A stack open source parece mais barata no papel, mas exige tempo dedicado de engenharia para upgrades, planejamento de capacidade e configuração de alta disponibilidade. O modelo gerenciado do Datadog transfere esse esforço para o fornecedor. Para times com menos de cinco engenheiros de infraestrutura, as soluções gerenciadas costumam ter custo total menor quando o tempo de engenharia é contabilizado.

Monitoramento de Kubernetes: Profundidade de Integração Comparada

O Prometheus é o sistema de métricas padrão do ecossistema Kubernetes, o que torna esse o tema dominante em entrevistas sobre monitoramento de orquestração de contêineres.

Prometheus + Grafana integra-se nativamente ao Kubernetes por meio do Helm chart kube-prometheus-stack, que implanta Prometheus Operator, Alertmanager, node-exporter, kube-state-metrics e dashboards Grafana pré-configurados em uma única instalação:

# 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

Esse comando implanta uma stack de monitoramento de nível de produção, com armazenamento persistente e 30 dias de retenção de dados. O Prometheus Operator usa Custom Resource Definitions (ServiceMonitor, PodMonitor) para configurar os scrape targets de forma declarativa. A sobrescrita de valores de um chart dessa forma é tratada em mais detalhes no guia de entrevista sobre Helm charts.

Datadog implanta um DaemonSet de agentes e um Cluster Agent. O Cluster Agent centraliza a comunicação com o API server do Kubernetes, reduzindo a carga sobre a API. A visão Live Containers do Datadog oferece visibilidade em tempo real dos estados dos pods, e o Orchestrator Explorer mapeia as relações entre deployments, services e pods.

Para times já investidos no ecossistema Kubernetes, a abordagem nativa do Prometheus evita a introdução de uma dependência externa. Já os times que priorizam a rapidez de configuração com menor investimento operacional tendem a preferir o Datadog.

OpenTelemetry e Neutralidade de Fornecedor

O OpenTelemetry (OTel) tornou-se o padrão da indústria para instrumentação, e os entrevistadores perguntam cada vez mais sobre ele em conjunto com as comparações de ferramentas de monitoramento.

O Prometheus 3.x aceita métricas OTLP diretamente assim que --web.enable-otlp-receiver é habilitado, sem necessidade de um Collector como intermediário. O Grafana Alloy (sucessor do Grafana Agent) atua tanto como OTel Collector quanto como scraper do Prometheus. O Datadog oferece suporte à ingestão OTLP, mas recomenda os próprios agentes proprietários para "acesso completo aos recursos", o que cria uma forma de lock-in mais suave.

A adoção do OTel importa porque desacopla a instrumentação da escolha do backend. Código de aplicação instrumentado com os SDKs do OTel pode enviar telemetria para Prometheus, Grafana Cloud, Datadog ou qualquer backend compatível, sem alterações no código. Essa flexibilidade é um argumento forte em entrevistas de system design quando o tema é a estratégia de observabilidade de longo prazo.

Perguntas de Entrevista sobre Observabilidade que Comparam as Três Ferramentas

Além do Prometheus em si, estas perguntas testam se o candidato consegue raciocinar entre ferramentas. Cada resposta destaca o conceito que o entrevistador está verificando.

P: Explique a diferença entre monitoramento, observabilidade e alerta.

O monitoramento acompanha métricas predefinidas e verifica modos de falha conhecidos. A observabilidade permite investigar modos de falha desconhecidos por meio de métricas, logs e traces (os "três pilares"). O alerta dispara notificações quando as condições ultrapassam limiares definidos ou baselines de anomalia. O monitoramento responde "o sistema está saudável?"; a observabilidade responde "por que o sistema não está saudável?".

P: Quando o Prometheus seria uma má escolha para monitoramento?

O Prometheus é otimizado para confiabilidade em vez de durabilidade: ele prioriza a disponibilidade do próprio sistema de monitoramento. Cenários em que o Prometheus tem dificuldade: armazenamento de longo prazo além de 30 dias (que exige Thanos, Mimir ou Cortex), dados de faturamento por requisição que demandam 100% de precisão (a coleta por scrape pode perder amostras) e sistemas baseados em eventos que precisam de coleta via push (o Pushgateway existe, mas apenas para jobs batch no nível de serviço).

P: Como a filosofia "Big Tent" do Grafana afeta a arquitetura de observabilidade?

O Grafana se conecta a qualquer fonte de dados sem exigir migração de dados. Isso significa que os times podem consultar Prometheus, Elasticsearch, CloudWatch e Datadog a partir de um único dashboard. O compromisso é a complexidade operacional: manter múltiplos backends exige mais expertise de infraestrutura do que uma abordagem de fornecedor único. Os entrevistadores avaliam se o candidato consegue articular esse trade-off com clareza.

P: O que é a cobrança por high-watermark do Datadog e por que ela importa?

O Datadog mede a contagem de hosts a cada hora, descarta o 1% superior das horas e fatura pelo pico no percentil 99. Isso significa que picos temporários de auto-scaling (por exemplo, tráfego de Black Friday) inflam a fatura mensal mesmo após as instâncias serem encerradas. Candidatos que mencionam esse ponto demonstram experiência operacional real com gestão de custos, algo cada vez mais exigido em vagas de SRE.

P: Como uma estratégia de alerta baseada em SLO difere entre Prometheus e Datadog?

No Prometheus, o alerta por SLO usa recording rules para pré-calcular error budgets e alertas de burn rate (a abordagem multi-window e multi-burn-rate do SRE Workbook do Google). O Datadog oferece widgets e monitores de SLO embutidos que acompanham a burn rate automaticamente. Ambas as abordagens implementam o mesmo conceito, mas o Prometheus exige mais configuração manual, enquanto o Datadog fornece um fluxo gerenciado. O candidato deve citar as janelas de burn rate (1h, 6h, 3d) e as taxas de consumo do error budget em sua resposta.

Framework de Decisão: Escolhendo a Stack Certa

A escolha certa depende de três variáveis: tamanho do time, maturidade operacional e restrições de orçamento. Não existe uma resposta universalmente correta, e os entrevistadores esperam que o candidato raciocine sobre os trade-offs em vez de simplesmente declarar um vencedor.

Fontes

• Releases do Prometheus: a 3.15.0 (setembro de 2026) estabiliza a codificação de chunks XOR2, adiciona o scraping de OpenMetrics 2.0 e torna --log.level obsoleto
• Especificação dos histogramas nativos do Prometheus: estáveis desde a 3.8, scrape_native_histograms obrigatório desde a 3.9
• Novidades do Grafana 13.0: Git Sync em GA, dashboards dinâmicos por padrão, breaking changes
• Preços de tabela do Datadog: preços de infraestrutura, APM e logs usados na tabela de custos
• Funções algorítmicas do Datadog: sintaxe de anomalies() e forecast()

O Que Levar para uma Entrevista de Prometheus ou Observabilidade

• O Prometheus é o padrão para coleta de métricas em ambientes Kubernetes; pull vs push, os quatro tipos de métrica, rate() vs irate(), cardinalidade e HA precisam estar na ponta da língua
• No Prometheus 3.9 e posteriores, histogramas nativos só são ingeridos quando scrape_native_histograms: true está definido
• O Grafana é uma camada de visualização, não um banco de dados de métricas: ele se conecta a mais de 100 fontes de dados, incluindo o Prometheus, e a stack LGTM (Loki, Grafana, Tempo, Mimir) forma uma plataforma de observabilidade open source completa
• O Datadog oferece o caminho mais rápido para observabilidade full-stack com detecção de anomalias embutida, ao custo de preços mais altos e maior vendor lock-in
• A adoção do OpenTelemetry torna a escolha do backend menos permanente: a instrumentação permanece a mesma independentemente da ferramenta que armazena e consulta os dados
• Em entrevistas, demonstre a capacidade de raciocinar sobre trade-offs (custo, controle, complexidade) em vez de defender uma única ferramenta
• Para uma preparação mais ampla, o guia de perguntas essenciais de entrevista DevOps cobre os temas vizinhos que os entrevistadores encadeiam depois de monitoramento