A ilusão de contratar APM proprietário antes de organizar os próprios logs no Rails

Toda vez que o assunto da observabilidade surge em conversas de arquitetura, a discussão se polariza rápido demais em dois extremos que considero problemáticos. De um lado, defende-se a contratação imediata de serviços como New Relic ou Datadog sob a justificativa de que equipes enxutas não podem gastar tempo mantendo ferramentas internas, e que a fatura mensal se paga pela comodidade de ter dashboards prontos no primeiro minuto. Do outro lado, engenheiros mais puristas pregam a montagem de uma infraestrutura completa de OpenTelemetry, com Prometheus, Loki, Tempo e Grafana rodando em contêineres dedicados, prometendo soberania total sobre as métricas sem pagar licença de software.

Eu discordo das duas abordagens quando o contexto é uma aplicação web monolítica rodando em servidores próprios. A primeira alternativa cria uma dependência financeira perigosa, em que qualquer pico de tráfego ou descuido no volume de logs gera faturas que competem com o custo da própria folha de pagamento. A segunda cria um monstro operacional que consome mais memória, disco e horas de manutenção do que o próprio sistema que ela deveria monitorar. Manter um cluster distribuído de rastreamento para inspecionar um monólito em Ruby on Rails é trocar um problema de visibilidade por um emprego em tempo integral de operador de observabilidade.

O objetivo real de qualquer sistema de monitoramento em produção não é gerar gráficos bonitos para exibir em televisores de escritório. O objetivo prático resume-se a responder três perguntas com rapidez no instante em que o alarme toca: o que quebrou, qual alteração provocou a falha e qual cliente foi impactado. Nenhuma dessas respostas exige agentes proprietários pesados rodando dentro da máquina virtual ou bibliotecas terceiras sequestrando a execução dos métodos no runtime da linguagem.

O ruído caro dos rastreadores automáticos

A promessa comercial dos grandes agentes de monitoramento baseia-se na instrumentação automática. Você instala uma gem, define uma variável de ambiente com a chave da conta e o agente intercepta chamadas de banco de dados, renderizações de templates e requisições HTTP externas. Parece conveniente, mas essa comodidade cobra pedágio duplo. Além do valor cobrado por host ou por volume de dados ingeridos, esses agentes injetam sobrecarga de latência e alocação de objetos em cada ciclo de requisição.

Quando você opera um servidor próprio com recursos definidos, cada megabyte de memória ocupado por um coletor de telemetria proprietário deixa de servir como cache do PostgreSQL ou como processo trabalhador do Puma. Pior do que o consumo de recursos é o excesso de dados irrelevantes gerados por essa abordagem. Telas cheias de gráficos de percentis e dispersão de chamadas SQL são inúteis quando o serviço está retornando erro 500 porque uma chave de configuração expirou ou uma migração de banco travou tabelas.

A instrumentação automática incentiva a equipe a ignorar a qualidade dos próprios logs. Cria-se o hábito preguiçoso de confiar que o painel externo vai apontar a linha exata do problema, enquanto o arquivo de log local da aplicação continua sendo um amontoado caótico de texto desestruturado, sem identificador de requisição e sem contexto de execução.

A base mínima que realmente resolve incidentes

Para descobrir o que quebrou sem gastar centenas de dólares todo mês, a aplicação precisa apenas de disciplina na geração dos dados que já existem nativamente no framework. No caso do Rails, o próprio mecanismo de notificações internas entrega métricas detalhadas sobre o tempo gasto em banco de dados, visualizações e controladores, sem exigir bibliotecas invasivas.

O primeiro elemento dessa estrutura é o log estruturado em formato legível por máquinas. Em vez de despejar linhas soltas de texto plano no disco, a aplicação deve emitir eventos em formato JSON diretamente na saída padrão do processo. Cada linha de log precisa carregar obrigatoriamente três campos contextuais: o identificador único da requisição gerado na borda, o identificador da conta ou usuário autenticado e a versão exata do código que está executando aquele processo.

Com essa tripla de informações em cada registro, o diagnóstico de qualquer incidente se torna direto. Se um cliente relata uma falha, você filtra o log pelo identificador dele ou pela chave da requisição que foi devolvida no cabeçalho HTTP da resposta. O rastreamento de ponta a ponta deixa de ser uma arquitetura complexa de spans distribuídos e passa a ser uma busca textual em arquivos locais organizados pelo próprio sistema operacional.

O segundo elemento é o tratamento centralizado de exceções não capturadas. Você precisa de uma ferramenta focada exclusivamente em agrupar erros, capturar o stack trace completo e registrar os parâmetros sanitizados da requisição que causou o problema. Existem alternativas leves que você pode hospedar no próprio servidor ou contratar por valores previsíveis que cobram apenas por evento processado, sem taxar a quantidade de servidores ou o número de processadores da máquina.

O terceiro elemento consiste em métricas básicas do sistema operacional e da aplicação. Um exportador simples de métricas de nó, combinado com a leitura de contadores do banco de dados e da fila de processos em segundo plano, entrega visibilidade suficiente para antecipar esgotamento de recursos. Não há necessidade de reter anos de histórico granular por segundo; trinta dias de métricas agregadas atendem a quase totalidade das investigações pós-incidente.

A decisão entre armazenar localmente ou centralizar

Existe uma controvérsia legítima sobre onde manter esses registros quando a infraestrutura cresce além de um único servidor. Uma corrente defende que todos os nós devem enviar logs imediatamente para um repositório centralizado, garantindo que nada se perca se uma máquina for destruída. Outra corrente prefere manter tudo localmente usando utilitários nativos do sistema operacional, argumentando que a rede não deve ser sobrecarregada com tráfego de depuração.

Eu adoto uma linha intermediária. Durante a operação normal, o próprio registrador do sistema operacional, como o journald, gerencia a rotação de arquivos e o consumo máximo de disco no servidor local com eficiência comprovada por décadas. Ele não consome memória desnecessária e lida com compressão de blocos sem intervenção manual.

Para permitir buscas rápidas sem precisar conectar em cada máquina individualmente, basta um agente de coleta extremamente leve que leia esses registros locais e encaminhe apenas os eventos de nível de aviso ou erro para um armazenamento simples de série temporal ou de texto. Os registros detalhados de depuração permanecem na máquina de origem, com retenção curta de poucos dias, disponíveis caso uma investigação minuciosa exija inspeção cirúrgica.

Essa separação impede que a conta de ingestão de dados exploda e mantém o servidor focado no seu trabalho principal, que é responder requisições de clientes com rapidez e estabilidade.

Operar sem intermediários caros

Assumir o controle dos próprios dados de diagnóstico exige que a equipe compreenda o ciclo de vida de uma requisição e os limites físicos da máquina onde o código roda. Terceirizar essa compreensão para um agente de monitoramento proprietário gera uma sensação enganosa de segurança que costuma desmoronar no momento em que o orçamento aperta ou quando o serviço externo enfrenta instabilidade no meio de uma crise na sua aplicação.

Se você tem logs estruturados com contexto de execução, alertas configurados para taxas anômalas de erro e um coletor focado em registrar exceções reais, você já tem tudo o que precisa para operar em produção com tranquilidade. O restante costuma ser sofisticação técnica desnecessária vendida como salvação para problemas que uma boa arquitetura de software resolve com simplicidade.