Durante muito tempo, o meu setup de monitorização era uma tabela numa base de dados. Logs escritos no SQL Server, uma query guardada algures, e muito SELECT * FROM Logs WHERE Level = 'Error' ORDER BY Timestamp DESC sempre que algo corria mal.
Não tenho orgulho disso. Mas funcionava suficientemente bem para que continuasse a fazê-lo durante mais tempo do que devia.
Os problemas eram óbvios em retrospetiva. Só olhavas para os logs quando algo rebentava. Não havia noção de tendência, nenhuma forma de ver que as taxas de erro tinham estado a subir lentamente durante três horas antes de chegar o ticket de suporte. Estavas sempre a reagir, nunca a observar. E consultar uma tabela de base de dados para entender um sistema em produção é simplesmente errado, de uma forma difícil de articular até experimentares algo melhor.
A Primeira Vez que Abri o Grafana
Configurei o Grafana a sério pela primeira vez num projeto que tinha problemas de performance que ninguém conseguia identificar. Os tempos de resposta eram lentos, mas não de forma catastrófica. Os utilizadores queixavam-se, mas os logs não mostravam nada obviamente partido.
Numa hora a ter o Prometheus a fazer scraping à nossa API .NET e o Grafana a mostrar o histograma de latência, o problema estava visível. Um endpoint específico estava a atingir P95 à volta de 4 segundos. Tudo o resto estava bem. A tabela de base de dados nunca me teria mostrado isso, porque ninguém teria pensado em procurar especificamente por isso.
Foi nesse momento que deixei de tratar a observabilidade como algo que se acrescenta quando as coisas correm mal.
Porque Não Usar o Que o Azure Oferece?
O Application Insights é a escolha óbvia se estás no Azure. Já está lá, integra com .NET em cerca de cinco minutos, e a Microsoft continua a melhorá-lo. Já o usei em vários projetos e é genuinamente bom.
Mas prende-te ao Azure. Cada métrica, cada trace, cada dashboard vive dentro do portal Azure. Se o projeto mudar de cloud, rebuilds tudo. Se quiseres combinar dados de serviços a correr noutro lado, não podes. Os teus dashboards, as tuas regras de alerta, o conhecimento institucional sobre como é o estado normal — tudo fica bloqueado dentro do ecossistema de um único fornecedor.
O Grafana não se importa de onde vêm os dados. Fala com Prometheus, Loki, Azure Monitor, CloudWatch, Elasticsearch, PostgreSQL, e mais uma dúzia de fontes ao mesmo tempo. Podes corrê-lo em qualquer lado. O JSON do teu dashboard é apenas um ficheiro que podes versionar e levar contigo. Essa portabilidade importa mais do que a maioria das pessoas percebe, até precisarem mesmo dela.
Como é a Boa Observabilidade na Prática
A diferença entre consultar logs numa base de dados e observar um dashboard Grafana em tempo real é mais ou menos a diferença entre ler o jornal de ontem e olhar pela janela.
Quando algo corre mal agora, abro o dashboard primeiro. O painel de taxa de erros diz-me se é generalizado ou isolado. O painel de latência diz-me se começou de repente ou se tem estado a degradar. O marcador de deployment (o Grafana permite anotar séries temporais com eventos) diz-me se uma release está correlacionada. A maior parte das vezes já sei o que está a acontecer antes de ter aberto um único ficheiro de log.
Os logs ainda existem. Ainda são úteis para detalhar pedidos individuais. Mas são o último passo, não o primeiro.
Também Muda a Forma Como Escreves Código
Quando tens dashboards que realmente observas, começas a pensar em métricas enquanto escreves código. Não de forma pesada ou sobre-engenheirada. Mais como: "Vou querer saber com que frequência este job falha, por isso vou adicionar um contador." Demora trinta segundos e compensa na primeira vez que algo corre mal às 2 da manhã e não tens de fazer deploy de um hotfix só para adicionar visibilidade.
Esse ciclo de feedback — código, observar, compreender, melhorar — é o que as boas ferramentas devem permitir. Uma tabela de logs numa base de dados quebra o ciclo porque verificá-la tem fricção. O Grafana remove essa fricção.
A Mudança Valeu a Pena
Não acho que a abordagem de base de dados como armazenamento de logs seja vergonhosa. É algo razoável para usar no início de um projeto quando há uma centena de outras coisas para resolver. Mas ficar lá demasiado tempo é um erro que cometi e não voltaria a cometer.
O Grafana com Prometheus não é complicado de configurar. Corre bem em Docker localmente. Corre bem em Kubernetes em produção. Não custa nada em self-hosted, ou muito pouco numa oferta gerida. E dá-te um nível de compreensão dos teus sistemas em execução que simplesmente não consegues obter de outra forma.
Se ainda estás a usar uma tabela de logs, reserva uma tarde. Não voltas atrás.
