O que o time perdeu
O New Relic foi desligado por custo, e junto com ele foram embora as telas que o time de desenvolvimento usava para achar gargalos: endpoints e operações de banco ordenados por tempo total consumido, tempo médio de resposta e throughput.
O SigNoz já estava em produção e recebia os traces, mas a interface nativa só ordenava por volume. Para o time, era um passo para trás. Os gargalos mais caros muitas vezes são endpoints com pouco tráfego e muito tempo gasto, e esses somem numa ordenação por volume.
Provar antes de construir
Antes de criar um único painel, passei por uma fase de análise só de leitura: inventário do ambiente, configuração do coletor OpenTelemetry, instrumentação e schema do banco de traces, num total de 12 verificações.
Com consultas manuais, comparei os números com as telas antigas do New Relic. O top 5 de endpoints saiu idêntico e na mesma ordem, com 27,19% do tempo no SigNoz contra 26,24% no New Relic no primeiro deles. Confirmei que não havia amostragem em nenhum ponto do pipeline, então os números eram exatos. E nenhum span de entrada estava sem rota, o que era melhor que o New Relic, que agrupava parte do tráfego num rótulo genérico. Também medi a retenção real dos traces, que definiu a janela máxima honesta para os painéis.
A fonte que parecia óbvia
A análise mudou o desenho. O caminho natural seria usar as métricas de APM já prontas, mas elas estavam quebradas (conto abaixo), então os painéis passaram a consultar os traces diretamente.
Na visão de banco, o agente de instrumentação nomeava as consultas só pelo nome do banco: mais de um milhão de chamadas e 53% do tempo de banco caíam num único rótulo, sem a tabela. Extraí a tabela do texto da consulta, e a visão passou a bater com a do New Relic. O que não dava para identificar ficou num painel próprio, declarado, em vez de escondido.
Entregar painel por painel
Construí e publiquei pela API um dashboard com nove painéis cobrindo as seis visões pedidas, versionado em JSON. Cada painel foi validado de ponta a ponta com a API de consultas antes de publicar. O rollback era simplesmente apagar o dashboard, sem efeito colateral: nenhuma aplicação, coletor ou retenção foi alterada.
O que ninguém tinha pedido
As métricas de APM estavam colapsadas. O processador que gera as métricas de latência e taxa por operação tem um limite de 2.048 operações por serviço, e os spans internos do ORM, com cerca de 900 nomes diferentes, estouravam esse limite. Resultado: 100% das séries tinham perdido a dimensão de endpoint. Medi que, filtrando esses spans, sobravam 44% de folga dentro do limite atual, e abri a correção com validação em staging antes de produção.
Encontrei também defeitos de instrumentação que distorciam os números, e os neutralizei com filtros nos painéis antes de passá-los ao time de desenvolvimento. Quatro serviços tinham spans de entrada duplicados, e a página nativa mostrava o dobro do throughput real. Uma biblioteca de acesso ao banco gerava um span paralelo ao do driver, contando o tempo de banco duas vezes. E a espera por conexão no pool aparecia no topo do "tempo de banco" sem ser consulta. Por fim, um ponto cego: o cache não tinha instrumentação nenhuma, e o New Relic mostrava milhares de chamadas por minuto nele.
O que mudou
As seis visões de APM voltaram a existir, em produção, com paridade comprovada e sem o custo da ferramenta desligada. O dashboard logo mostrou o argumento do pedido: endpoints com tráfego baixíssimo consumindo boa parte do tempo da aplicação. E o time ganhou números mais confiáveis do que tinha antes.
O que eu levo disso
Numa migração de observabilidade, o primeiro entregável é a prova de paridade, e não o dashboard. Se os números novos não batem com os antigos, o time para de confiar na ferramenta, e um painel bonito com números errados é pior que nenhum. Medir antes de construir mudou o próprio desenho: a fonte que parecia óbvia estava quebrada havia dias.