Dashboards (Grafana, Kibana)

Dashboards são representações visuais agregadas de telemetria, organizadas para responder perguntas operacionais em segundos, sem consultas manuais. Em produção, eles cumprem três papéis distintos: a triagem rápida durante incidentes, o acompanhamento contínuo da saúde dos serviços e a comunicação do comportamento do sistema para públicos fora da engenharia. Grafana e Kibana dominam esse espaço com propostas diferentes: o Grafana é o visualizador universal, capaz de consultar Prometheus, Loki, Elasticsearch, CloudWatch e dezenas de outras fontes em um mesmo painel, enquanto o Kibana é a camada de exploração do stack ELK, otimizada para busca e análise de documentos de log. Um dashboard bem construído conta a história do serviço em uma única tela; um mal construído vira mosaico de gráficos decorativos que ninguém consulta. A construção de dashboards, portanto, é trabalho de design informacional, e não apenas de configurar visualizações.

O problema que os dashboards resolvem

Durante um incidente, o time precisa passar de "algo está errado" para "onde e o quê" em menos de um minuto, e esse caminho não pode depender de escrever consultas na hora. O dashboard padroniza esse caminho, colocando os sinais certos em ordem de prioridade e com as agregações corretas já calculadas. No dia a dia, ele substitui reuniões de status por uma leitura comum dos números, reduzindo discussões subjetivas sobre desempenho. Ele também registra a memória histórica do serviço, permitindo comparar o comportamento atual com semanas anteriores e identificar tendências de capacidade antes que virem incidentes. O problema oposto, excesso de dashboards sem dono e sem propósito, é igualmente real e exige governança explícita.

Essa governança costuma assumir a forma de um catálogo interno, com painéis obrigatoriamente vinculados a um serviço e a um time responsável. Painéis órfãos, sem dono registrado, são tratados como candidatas à remoção na próxima revisão, o mesmo critério aplicado a qualquer recurso de produção que ninguém mantém.

Hierarquia de dashboards

A prática consolidada organiza os painéis em três níveis, cada um com um público e uma granularidade. O primeiro nível é o painel executivo ou de visão geral, que mostra a saúde de todos os serviços em uma tela única, com mapas de status e SLOs, usado por liderança e como ponto de partida de qualquer triagem. O segundo nível é o painel por serviço, com os golden signals de cada serviço, seus SLOs, dependências críticas e eventos de deploy; esse é o painel do dono do serviço e o mais usado em incidentes. O terceiro nível é o painel de detalhe por componente, com foco em um banco específico, uma fila, um consumidor ou uma rotina de job, usado em investigações profundas. A navegação deve fluir do geral para o específico com links diretos entre painéis, carregando variáveis de contexto, como nome do serviço, para que o investigador não reconfigure filtros a cada salto.

Golden signals

Os golden signals, popularizados pelo livro de engenharia de confiabilidade do Google, definem o conjunto mínimo de sinais que todo painel de serviço deve exibir. São quatro: latência, com distribuição de quantis e não apenas média; tráfego, como requisições por segundo ou mensagens consumidas; erros, com taxa de falha explícita e por tipo; e saturação, medindo o quanto do recurso está comprometido, como utilização de CPU, profundidade de fila e conexões de banco. O painel por serviço deve abrir com esses quatro sinais, e apenas depois expor detalhamentos. O exemplo de consulta abaixo ilustra o padrão de cada sinal em PromQL.

# Latência: p95 e p99 por rota, a partir de histograma
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

# Tráfego: requisições por segundo agregadas por rota
sum(rate(http_requests_total[5m])) by (route)

# Erros: proporção de respostas 5xx sobre o total, por rota
sum(rate(http_requests_total{status=~"5.."}[5m])) by (route)
  / sum(rate(http_requests_total[5m])) by (route)

# Saturação: profundidade da fila do consumidor
max(kafka_consumergroup_lag{group="pagamentos"})

A escolha da janela temporal de agregação acompanha o uso do painel: janelas de cinco minutos servem para triagem, janelas de uma hora servem para tendência, e painéis executivos tendem a usar janelas maiores com resolução reduzida.

Aplicação prática: o painel no incidente

Em um incidente real, o painel de serviço é a primeira parada e precisa responder três perguntas em ordem: o que degradou, desde quando e o que mudou junto. A faixa de SLOs responde à gravidade, mostrando se o error budget está sendo queimado em ritmo de incidente. Os golden signals localizam o sintoma, diferenciando por exemplo um problema de saturação de banco de um aumento de erros após um deploy. As anotações de release respondem à terceira pergunta ao exibir exatamente qual versão entrou em produção minutos antes da degradação. Times treinados seguem esse roteiro de leitura sempre na mesma ordem, o que reduz o tempo até a primeira hipótese acionável e evita a dispersão típica de sessões de triagem coletiva.

Variáveis de template e reuso

Variáveis de template são o mecanismo que transforma um painel único em um painel parametrizável, capaz de servir todos os ambientes e serviços sem duplicação. Uma variável de data source permite trocar entre clusters, uma variável de ambiente alterna produção e staging, e uma variável de serviço popula filtros de todas as consultas. O modelo JSON do Grafana abaixo demonstra a definição típica.

{
  "templating": {
    "list": [
      {
        "name": "ambiente",
        "type": "custom",
        "query": "producao,staging",
        "current": { "text": "producao", "value": "producao" }
      },
      {
        "name": "servico",
        "type": "query",
        "datasource": "Prometheus",
        "query": "label_values(http_requests_total, job)",
        "refresh": 2,
        "includeAll": true
      }
    ]
  },
  "panels": [
    {
      "title": "Taxa de erro do serviço selecionado",
      "type": "timeseries",
      "targets": [
        {
          "expr": "sum(rate(http_requests_total{job=\"$servico\", status=~\"5..\"}[5m])) / sum(rate(http_requests_total{job=\"$servico\"}[5m]))"
        }
      ]
    }
  ]
}

Cada variável usada nas consultas elimina uma cópia do painel, e a convenção comum é manter um painel de serviço genérico versionado em repositório, provisionado automaticamente via Grizzly ou por provisionamento nativo do Grafana, em vez de painéis criados à mão na interface.

Golden dashboards padronizados

Golden dashboards são templates de painel padronizados pela organização, com layout, nomes de métricas e convenções visuais definidos centralmente e preenchidos automaticamente para cada serviço novo. O objetivo é uniformidade: qualquer engenheiro abre o painel de qualquer serviço e encontra os mesmos quatro sinais nas mesmas posições, o que reduz drasticamente o custo cognitivo em incidentes que atravessam fronteiras de times. O padrão costuma incluir a linha superior com SLOs e error budget, a segunda faixa com os golden signals, a faixa de dependências críticas e a faixa inferior com eventos de deploy e releases. Bibliotecas internas de instrumentação complementam o padrão garantindo que as métricas com nomes acordados existam, o que faz o template funcionar para qualquer serviço sem ajuste manual.

A adoção desse padrão também simplifica a integração de novos serviços: ao expor as métricas acordadas, o serviço ganha automaticamente um painel completo, criado pelo pipeline de provisionamento. O esforço de observabilidade deixa de depender da disciplina individual de cada time e passa a ser propriedade da plataforma.

Grafana versus Kibana

As duas ferramentas frequentemente coexistem, e a comparação abaixo orienta a divisão de responsabilidades.

A divisão saudável em muitos ambientes usa o Grafana como porta única de visualização operacional, incluindo painéis que consultam Elasticsearch por trás, e o Kibana como ferramenta de exploração ad hoc para analistas que precisam varrer documentos sem agregação definida de antemão.

A escolha também tem dimensão de licenciamento e custo. O Grafana open source mantém licença AGPL com produtos gerenciados oferecidos pela própria empresa, e o Kibana seguiu trajetória semelhante, com variantes de licença que influenciam a decisão em ambientes corporativos, especialmente quando serviços gerenciados de terceiros precisam redistribuir o software.

Anti-padrões

Alguns padrões ruins aparecem com regularidade e convertem o investimento em dashboards em desperdício.

• O dashboard que ninguém olha, criado em um projeto, sem dono e sem vínculo com incidentes, decaindo até mostrar consultas quebradas por meses.
• O mosaico de gráficos, com dezenas de séries por tela e cores inconsistentes, onde nada se destaca e nenhum diagnóstico é possível em menos de um minuto.
• O painel de médias, que exibe latência média e esconde os outliers que motivam reclamações de usuários.
• Painéis duplicados por ambiente, criados por cópia manual e divergindo silenciosamente quando alguém ajusta um e esquece o outro.
• Gráficos sem unidade explícita, onde milissegundos e segundos, ou bytes e megabytes, convivem sem rotulagem e induzem leitura errada.
• Painéis sem links para o tracing, obrigando o investigador a buscar manualmente o contexto quando o gráfico aponta o sintoma.

Boas práticas

As práticas abaixo resumem o que mantém a camada de visualização útil ao longo do tempo.

• Adote a hierarquia em três níveis, com links de navegação carregando variáveis de contexto entre visão geral, serviço e componente.
• Padronize golden dashboards provisionados por código, com os quatro golden signals e o estado do error budget no topo de todo painel de serviço.
• Prefira quantis a médias, rotule unidades em todos os eixos e limite cada gráfico ao número de séries que a leitura rápida suporta.
• Marque deploys e eventos de configuração como anotações nos painéis, porque a sobreposição de releases com degradações é o primeiro filtro de qualquer investigação.
• Revise o acervo trimestralmente, removendo painéis sem uso comprovado e atualizando aqueles cujas consultas quebraram com mudanças de métricas.
• Trate o painel como código, com revisão de mudanças visuais e de consultas no mesmo fluxo de pull request aplicado a qualquer alteração de produção.