SENTINEL Tecnologia
Observabilidade17 de março de 20268 min

Grafana + Prometheus: observabilidade que previne incidentes

Dashboard best practices, alerting rules, SLOs e métricas RED/USE para construir observabilidade que realmente previne incidentes.

GrafanaPrometheusObservabilidadeSRE

Monitoramento reativo — esperar o alerta de que algo quebrou — é o padrão mínimo. Observabilidade de verdade previne incidentes antes que eles aconteçam. Grafana + Prometheus são a stack mais adotada no ecossistema open-source para isso.

Por que Prometheus + Grafana

Prometheus é um banco de dados de séries temporais otimizado para métricas de infraestrutura e aplicação. Grafana é a plataforma de visualização que transforma essas métricas em dashboards acionáveis.

Juntos, oferecem: coleta via pull model, linguagem de consulta poderosa (PromQL), alerting nativo e dashboards interativos.

Métricas que importam: RED e USE

Método RED (para serviços)

  • Rate: requests por segundo
  • Errors: taxa de erros por endpoint
  • Duration: latência (P50, P95, P99)
  • Método USE (para infraestrutura)

  • Utilization: % de uso de CPU, memória, disco
  • Saturation: queue depth, load average
  • Errors: erros de hardware, network drops
  • ```promql

    # Taxa de erros HTTP 5xx nos últimos 5 minutos

    sum(rate(http_requests_total{status=~"5.."}[5m]))

    /

    sum(rate(http_requests_total[5m])) * 100

    ```

    Dashboard best practices

    1. Um dashboard por serviço: dashboards genéricos com 50 painéis são inúteis. Cada serviço deve ter seu dashboard focado.

    2. Hierarquia de dashboards: Overview > Serviço > Debug. O operador navega do geral para o específico durante um incidente.

    3. Variáveis de template: use variáveis para namespace, environment e pod. Evite dashboards duplicados.

    ```json

    {

    "templating": {

    "list": [

    {

    "name": "namespace",

    "type": "query",

    "query": "label_values(kube_pod_info, namespace)"

    }

    ]

    }

    }

    ```

    4. Anotações de deploy: marque deploys nos dashboards para correlacionar mudanças com degradação de performance.

    Alerting rules efetivas

    Regras de alerta mal configuradas geram alert fatigue — a equipe começa a ignorar todos os alertas.

    ```yaml

    groups:

  • name: slo-alerts
  • rules:

  • alert: HighErrorRate
  • expr: |

    sum(rate(http_requests_total{status=~"5.."}[5m]))

    /

    sum(rate(http_requests_total[5m])) > 0.01

    for: 5m

    labels:

    severity: critical

    annotations:

    summary: "Taxa de erros acima de 1% por 5 minutos"

    runbook_url: "https://wiki.empresa.com/runbooks/high-error-rate"

    ```

    Dicas para alerting:

  • Use `for` para evitar false positives (mínimo 2-5 minutos)
  • Defina severidades claras: info, warning, critical, page
  • Cada alerta deve ter um runbook associado
  • Revise alertas trimestralmente — remova os que nunca foram acionados
  • SLOs (Service Level Objectives)

    SLOs transformam métricas técnicas em compromissos de negócio. Defina error budget e monitore o burn rate.

    ```promql

    # Error budget burn rate (SLO 99.9%)

    1 - (

    sum(rate(http_requests_total{status!~"5.."}[1h]))

    /

    sum(rate(http_requests_total[1h]))

    ) > 0.001

    ```

    Conclusão

    Observabilidade com Grafana + Prometheus não é instalar e esquecer. Exige métricas bem definidas, dashboards focados, alertas inteligentes e SLOs alinhados com o negócio. O investimento se paga na primeira vez que você detecta um problema antes do cliente reportar.

    Precisa de ajuda com Observabilidade?

    Consultoria especializada com resultados mensuraveis. Fale com um especialista sem compromisso.

    Artigos relacionados

    Receba insights de TI no seu email

    Artigos praticos sobre Cloud, FinOps, IA e estrategia de TI. Sem spam.

    Ganhe o guia "Checklist de Otimizacao Cloud" ao se inscrever

    Cancele a qualquer momento.