Dashboards

Princípios de design, métricas-chave, dashboards operacionais vs de negócio e como construir visões úteis.

Para que servem os dashboards?

Um dashboard é uma visão consolidada de métricas que permite entender o estado de um sistema num relance. Mas nem todos os dashboards são iguais — um dashboard mal projetado pode ser tão inútil quanto não ter nenhum.

O objetivo de um bom dashboard não é mostrar a maior quantidade de dados possível, mas responder a perguntas específicas de forma rápida e clara.

Princípios de design

1. Defina a audiência

Antes de criar um dashboard, pergunte-se: quem vai usá-lo e para quê?

• Engenheiro on-call: Precisa saber rapidamente se há um problema e onde ele está.
• Tech lead: Precisa entender tendências de desempenho e capacidade.
• Product manager: Precisa de métricas de negócio e adoção.
• Executivo: Precisa de indicadores de alto nível sobre saúde e crescimento.

Cada audiência precisa de um dashboard diferente.

2. Hierarquia visual

Organize a informação da mais importante para a menos importante, de cima para baixo e da esquerda para a direita:

• Linha superior: Indicadores de estado geral (semáforos, números grandes).
• Linhas intermediárias: Gráficos de tendência das métricas principais.
• Linhas inferiores: Detalhe e métricas secundárias.

3. Menos é mais

Um dashboard com 30 painéis não é mais útil que um com 8 painéis bem escolhidos. Cada painel deve justificar sua presença respondendo a uma pergunta concreta.

Regra prática: se um painel não mudou a decisão de ninguém nos últimos 30 dias, provavelmente não precisa estar ali.

4. Contexto temporal

Sempre inclua:

• Seletor de intervalo temporal: Permitir alternar entre últimas 6 horas, 24 horas, 7 dias.
• Comparação temporal: Mostrar a mesma métrica de uma semana atrás para detectar anomalias.
• Marcadores de deploys: Linhas verticais que indicam quando um deploy foi feito.

5. Cores com significado

Use cores de forma consistente e com propósito:

• Verde: Tudo normal, dentro do SLO.
• Amarelo/Laranja: Degradação, aproximando-se do limite.
• Vermelho: Problema ativo, fora do SLO.

Evite usar muitas cores decorativas — elas distraem e diluem os sinais importantes.

Tipos de dashboards

Dashboard operacional

Projetado para a equipe de engenharia durante operações diárias e resposta a incidentes.

Conteúdo típico:

• Métricas RED por serviço (rate, errors, duration).
• Estado de dependências (bancos de dados, filas, serviços externos).
• Recursos de infraestrutura (CPU, memória, disco).
• Alertas ativos.
• Deploys recentes.

Características:

• Atualização em tempo real (refresh a cada 10-30 segundos).
• Foco nas últimas horas.
• Limites visíveis com cores de semáforo.

Dashboard de serviço

Um dashboard dedicado a um microsserviço específico. Cada equipe deveria ter um para cada serviço que mantém.

Conteúdo típico:

• Métricas RED do serviço.
• Latência por endpoint (p50, p95, p99).
• Taxa de erros por tipo de erro.
• Métricas de dependências downstream.
• Uso de recursos (CPU, memória, conexões ao DB).
• Fila de mensagens (se aplicável): tamanho, lag, throughput.

Dashboard de negócio

Projetado para stakeholders não técnicos que precisam entender o impacto no negócio.

Conteúdo típico:

• Pedidos criados por hora/dia.
• Receita processada.
• Taxa de conversão do checkout.
• Usuários ativos.
• Tempo médio para completar uma operação-chave.

Características:

• Atualização menos frequente (a cada 5-15 minutos).
• Foco em tendências diárias/semanais.
• Linguagem de negócio, não técnica.

Dashboard de SLO

Mostra o cumprimento dos Service Level Objectives da equipe.

Conteúdo típico:

• SLO atual vs objetivo (ex: 99.92% vs 99.9%).
• Error budget restante (em minutos ou porcentagem).
• Tendência do error budget nos últimos 30 dias.
• Incidentes que consumiram error budget.

Este dashboard é fundamental para tomar decisões sobre priorização: se o error budget está se esgotando, a equipe deveria priorizar estabilidade em vez de features.

Métricas-chave por tipo de componente

Para um API Gateway

• Requests por segundo (total e por rota).
• Latência por rota (p50, p95, p99).
• Taxa de erros 4xx e 5xx.
• Rate limiting ativado.
• Conexões ativas.

Para um banco de dados

• Queries por segundo.
• Latência de queries (p50, p95, p99).
• Conexões ativas vs pool máximo.
• Replicação lag (se aplicável).
• Uso de disco e crescimento.

Para uma fila de mensagens

• Mensagens publicadas por segundo.
• Mensagens consumidas por segundo.
• Consumer lag (mensagens pendentes).
• Tamanho da fila.
• Erros de processamento (dead letter queue).

Para um serviço HTTP

• Métricas RED (rate, errors, duration).
• Distribuição de status codes.
• Latência por endpoint.
• Erros por tipo (timeout, 500, 503).
• Saturação (requests na fila, threads ativas).

Antipadrões

Dashboard “wall of text”

Painéis pequenos demais com números que ninguém consegue ler. Priorize poucos painéis grandes e claros.

Dashboard “vanity metrics”

Métricas que ficam bonitas mas não são acionáveis: “total de requests desde o início dos tempos”. Mostre taxas e tendências, não acumulados.

Dashboard sem contexto

Gráficos sem limites, sem comparação temporal, sem indicação do que é “normal”. Sem contexto, um gráfico é apenas uma linha bonita.

Dashboard desatualizado

Um dashboard que não reflete a arquitetura atual é pior que não ter dashboard — gera falsa confiança. Mantenha os dashboards atualizados como parte do ciclo de desenvolvimento.

Um único dashboard para tudo

Tentar colocar métricas operacionais, de negócio e de infraestrutura num único dashboard. Cada audiência precisa de sua própria visão.

Ferramentas

Grafana

A ferramenta mais popular para dashboards de observabilidade:

• Suporta múltiplos data sources (Prometheus, Elasticsearch, CloudWatch, etc.).
• Templates e variáveis para dashboards dinâmicos.
• Alertas integrados.
• Comunidade ativa com dashboards compartilhados.

Datadog

Plataforma SaaS que integra métricas, logs, traces e dashboards:

• Dashboards out-of-the-box para tecnologias populares.
• Correlação automática entre sinais.
• Notebooks para investigação de incidentes.

Kibana

Parte do stack ELK, especializado em visualização de logs:

• Dashboards baseados em dados do Elasticsearch.
• Ideal para análise de logs e busca.
• Lens para criar visualizações sem código.

Boas práticas

Dashboard como código

Defina dashboards em código (JSON, Terraform, Jsonnet) e versione-os no Git:

• Reprodutibilidade: você pode recriar dashboards em qualquer ambiente.
• Revisão: mudanças em dashboards passam por code review.
• Histórico: você sabe quem mudou o quê e quando.

Onboarding com dashboards

Quando um novo membro entra na equipe, os dashboards deveriam fazer parte do onboarding:

• “Este é o dashboard principal do serviço X.”
• “Estes são os indicadores que olhamos primeiro quando há um incidente.”
• “Este é o dashboard de SLO da equipe.”

Iteração contínua

Os dashboards não são estáticos. Depois de cada incidente, pergunte-se:

• O dashboard me ajudou a diagnosticar o problema?
• Faltou alguma métrica que teria sido útil?
• Havia painéis que não agregam valor?

Resumo

Os dashboards são a interface humana da observabilidade. Um bom dashboard responde a perguntas específicas para uma audiência definida, usa hierarquia visual para priorizar informação e se mantém atualizado com a arquitetura. Combinando dashboards operacionais, de serviço, de negócio e de SLO, a equipe tem visibilidade completa sobre a saúde do sistema a partir de múltiplas perspectivas.