Dashboards de on-call: o que monitorar de verdade durante plantão

1. Por que dashboards tradicionais falham durante plantões

1.1. O excesso de métricas e gráficos que geram ruído cognitivo

Dashboards tradicionais frequentemente exibem dezenas de gráficos simultâneos, cada um com múltiplas séries temporais. Durante um plantão, quando o estresse está elevado e o tempo de resposta é crítico, esse excesso de informação paralisa em vez de ajudar. Estudos de neurociência aplicada mostram que o cérebro humano consegue processar eficientemente no máximo 4 a 5 variáveis simultâneas — qualquer número superior gera ruído cognitivo e atrasa a tomada de decisão.

1.2. A diferença entre monitorar para análise e monitorar para resposta imediata

Um dashboard de análise pode conter 50 gráficos para investigação de tendências sazonais. Um dashboard de on-call precisa responder a uma pergunta específica: "O que está quebrado agora e como consertar?" A confusão entre esses dois propósitos é a principal causa de fadiga de alertas e incidentes prolongados.

1.3. O princípio de "menos é mais" no contexto de incidentes

O princípio fundamental é: cada elemento no dashboard deve justificar sua existência. Se uma métrica não ajuda a determinar a causa raiz ou a ação imediata, ela deve ser removida. Um dashboard de on-call eficaz tem no máximo 8 a 12 painéis, organizados em ordem de prioridade de leitura.

2. Os quatro pilares de um dashboard de on-call eficaz

2.1. Latência: tempos de resposta de serviços críticos e percentis (p50, p95, p99)

A latência é o primeiro indicador de degradação. Monitore os percentis, especialmente p99, que revela a experiência dos usuários mais afetados.

# Exemplo de consulta Prometheus para latência p99
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

2.2. Erros: taxas de erro por endpoint, status HTTP e logs de exceções

Erros são o segundo pilar. Monitore a taxa de erro total e por endpoint. Um aumento súbito de 5xx ou 4xx específicos pode indicar problemas localizados.

# Exemplo de consulta para taxa de erro
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100

2.3. Tráfego: volume de requisições, throughput e padrões anômalos

Mudanças abruptas no tráfego frequentemente precedem incidentes. Monitore o volume total e compare com baselines históricos.

# Exemplo de consulta para detecção de anomalia de tráfego
avg_over_time(rate(http_requests_total[5m])[1h:])  # baseline
rate(http_requests_total[5m])  # valor atual

2.4. Saturação: uso de CPU, memória, conexões de banco e filas

A saturação de recursos é a causa mais comum de degradação progressiva. Monitore os limites de capacidade e estabeleça thresholds claros.

# Exemplo de consulta para saturação de CPU
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

3. Hierarquia de informações: o que colocar em cada tela

3.1. Visão geral (primeiro painel): status dos serviços, SLOs e alertas ativos

O primeiro painel deve responder em 5 segundos: "Está tudo bem?" Use semáforos de cores (verde/amarelo/vermelho) e exiba apenas o status dos serviços críticos, SLOs atuais e alertas disparados.

3.2. Visão intermediária: métricas de dependências e recursos compartilhados

O segundo nível mostra bancos de dados, caches e filas. São os componentes que podem afetar múltiplos serviços simultaneamente.

3.3. Visão detalhada (drill-down): logs, traces e histórico recente de incidentes

O terceiro nível é para investigação aprofundada. Deve conter links diretos para logs, traces distribuídos e pós-mortems de incidentes recentes.

4. Métricas essenciais que todo plantonista precisa ver

4.1. Apdex score e burn rate de error budgets

O Apdex score (Application Performance Index) mede a satisfação do usuário em uma escala de 0 a 1. O burn rate do error budget indica a velocidade de consumo da margem de erros permitida.

# Consulta para Apdex score
(
  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) +
  sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) * 0.5
) / sum(rate(http_request_duration_seconds_count[5m]))

4.2. Tempo de recuperação de serviços (MTTR) e tempo entre falhas (MTBF)

MTTR e MTBF são indicadores de confiabilidade. Exiba a média móvel dos últimos 30 dias para identificar tendências de degradação.

4.3. Indicadores de saúde de banco de dados e caches

Para PostgreSQL: conexões ativas, deadlocks, replicação lag. Para Redis: taxa de acerto de cache, memória usada, conexões rejeitadas.

# Consulta para replicação lag no PostgreSQL
pg_replication_lag_seconds

5. Como projetar dashboards para diferentes níveis de gravidade

5.1. Dashboards de "green": monitoramento passivo e tendências

No modo "green", exiba apenas indicadores de tendência: crescimento de latência ao longo de semanas, aumento gradual de uso de recursos. Sem alertas sonoros.

5.2. Dashboards de "yellow": alertas de degradação e thresholds dinâmicos

No modo "yellow", thresholds dinâmicos baseados em desvio padrão histórico. Alerta quando uma métrica ultrapassa 2 desvios padrão da média.

5.3. Dashboards de "red": resposta a incidentes com ações recomendadas

No modo "red", o dashboard muda completamente: exibe apenas as métricas afetadas, com ações recomendadas baseadas em runbooks. Botões de ação rápida ficam visíveis.

6. Integração com ferramentas de alerta e runbooks

6.1. Como linkar alertas do Alertmanager diretamente ao gráfico relevante

Configure links nos alertas do Alertmanager que apontem para o dashboard e o intervalo de tempo específico do incidente.

# Exemplo de anotação no Alertmanager
annotations:
  dashboard: "https://grafana.example.com/d/abc?from={{ .StartsAt }}&to={{ .EndsAt }}"

6.2. Botões de ação rápida: silenciar, escalonar e abrir runbook

Cada alerta no dashboard deve ter três botões: Silenciar (acknowledge), Escalonar (para próximo nível) e Abrir Runbook (link para documentação).

6.3. Exibição de histórico de incidentes e pós-mortem no próprio dashboard

Inclua um painel que liste os últimos 10 incidentes com status, duração e link para o pós-mortem. Isso ajuda a identificar padrões recorrentes.

7. Exemplos práticos de layouts e consultas

7.1. Exemplo de dashboard para API REST com Prometheus e Grafana

Layout (4 painéis):
- Painel 1: Status geral (verde/vermelho) + SLO atual
- Painel 2: Gráfico de latência (p50, p95, p99) nas últimas 6 horas
- Painel 3: Taxa de erro por endpoint (top 5)
- Painel 4: Throughput (requisições/segundo)

# Consulta combinada para painel de status
(
  avg(rate(http_requests_total[5m])) > 100
  and
  histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) < 2.0
  and
  sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) < 0.01
)

7.2. Exemplo de dashboard para filas de mensageria (Kafka, RabbitMQ)

Layout (4 painéis):
- Painel 1: Lag de consumidores por grupo
- Painel 2: Taxa de produção vs consumo
- Painel 3: Tamanho da fila (mensagens não processadas)
- Painel 4: Erros de entrega e retentativas

# Consulta para lag de consumidores Kafka
sum(kafka_consumer_lag) by (consumer_group)

7.3. Exemplo de dashboard para banco de dados (PostgreSQL, Redis)

Layout (4 painéis):
- Painel 1: Conexões ativas vs limite máximo
- Painel 2: Tempo médio de consulta (p95)
- Painel 3: Cache hit ratio (Redis) / Buffer hit ratio (PostgreSQL)
- Painel 4: Replicação lag e deadlocks

# Consulta para cache hit ratio no Redis
rate(redis_keyspace_hits_total[5m]) / (rate(redis_keyspace_hits_total[5m]) + rate(redis_keyspace_misses_total[5m])) * 100

8. Boas práticas de manutenção e evolução contínua

8.1. Revisão periódica com a equipe de plantão para remover métricas obsoletas

Agende reuniões trimestrais com a equipe de plantão para revisar cada métrica. Pergunte: "Essa métrica já ajudou a resolver um incidente?" Se não, remova.

8.2. Testes de usabilidade: simular incidentes com o dashboard real

Realize chaos engineering com o dashboard aberto. Simule um incidente e cronometre quanto tempo leva para identificar a causa raiz usando apenas o dashboard.

8.3. Versionamento de dashboards e documentação de alterações

Mantenha os dashboards em sistemas de versionamento (Git). Cada alteração deve ter uma descrição clara do motivo e impacto esperado.

# Exemplo de entrada de changelog
## [2024-03-15] - Removido painel de latência por endpoint
- Motivo: Métrica nunca foi usada durante incidentes reais
- Impacto: Redução de 12 para 9 painéis no dashboard principal

Referências