Um Ano de Dashboards as Code com Grafana: O que Mudaria se Começasse Hoje

Há um ano, embarcamos na jornada de transformar nossa abordagem de observabilidade adotando o modelo de Dashboards as Code com Grafana. A decisão foi impulsionada pela necessidade de uniformizar o monitoramento de mais de 100 serviços espalhados por ambientes híbridos, entre AWS e GCP. Agora, com um ano de experiência, é hora de refletir sobre o que aprendemos e, principalmente, o que faríamos diferente se começássemos hoje.

Contexto

A diversidade de ferramentas de monitoramento que os times usavam anteriormente gerava uma grande dificuldade para o time de SRE, que não tinha uma visão unificada do ambiente. A fadiga de alertas era um problema constante, com centenas de alertas disparando semanalmente, muitos dos quais não eram acionados há meses. Resolvemos esses problemas implementando uma plataforma centralizada de observabilidade com Grafana e Prometheus, adotando uma abordagem de Dashboards as Code. Essa solução nos permitiu ter um controle de versão robusto, revisões por PR e uma implantação consistente via CI/CD.

A Decisão

Optamos pelo Grafana devido à sua neutralidade de fornecedor e capacidade de integração com qualquer fonte de métricas, além de sua linguagem de consulta poderosa. Escolhemos Dashboards as Code em vez de interfaces gráficas para garantir reprodutibilidade e evitar dashboards "flocos de neve". Além disso, mudamos de alertas baseados em limiares para alertas dirigidos por SLOs, focando em impactos de negócios em vez de sintomas técnicos. A decisão de usar o modelo de push de Prometheus foi guiada pela necessidade de uma abordagem consistente entre nossos ambientes na nuvem híbrida.

O Que Construímos

Implementamos uma instância central de Grafana com SSO via LDAP, Prometheus federado entre GCP e AWS, e usamos o Grafonnet para gerar dashboards a partir de código. Criamos um pipeline CI/CD que gerava JSONs de dashboards a partir de PRs, implantando-os no Grafana e realizando testes de fumaça. Estabelecemos um framework de SLO com alertas de taxa de queima de orçamento de erro e painéis de SLO por serviço. A introdução de rastreamento distribuído com Tempo e Jaeger permitiu a correlação de traces e logs.

Resultado

No decorrer do ano, conseguimos padronizar e controlar a versão dos dashboards para mais de 100 serviços. Reduzimos a fadiga de alertas de cerca de 200 alertas por semana para aproximadamente 30, a maioria dos quais acionáveis. O tempo médio para detectar incidentes críticos (MTTD) caiu cerca de 65%. Além disso, conseguimos que 80% dos serviços críticos tivessem SLOs definidos com acompanhamento de orçamento de erro. A criação de dashboards para novos serviços foi reduzida para menos de um dia, graças a templates e PRs.

O Que Eu Faria Diferente

Ao olhar para trás, uma das lições mais claras é a importância de definir SLOs junto às equipes de produto desde o início. Times sem SLOs bem definidos não sabem ao certo o que devem monitorar, o que pode levar a alertas irrelevantes. Além disso, investir em orçamentos de cardinalidade logo cedo teria evitado alguns problemas com o Prometheus, já que rótulos de alta cardinalidade podem ser fatais em escala. Por fim, a atribuição de custos por volume de métricas por equipe deveria ter sido priorizada desde o início, já que a infraestrutura de observabilidade não é barata.

Essas lições nos proporcionaram uma base sólida para continuar aprimorando nossa abordagem de observabilidade e garantir que estamos sempre alinhados com as necessidades de nosso negócio e equipes de desenvolvimento.