Uma exceção não é uma linha de log

A sua aplicação levantou um NoMethodError em produção. O que acontece depois depende inteiramente de qual ferramenta recebe isso.

No agregador de logs, vira um evento com um backtrace num campo, no meio de um milhão de outras linhas. Alguém encontra quando vai procurar, o que acontece depois de uma pessoa reclamar, o que é depois de aquilo estar acontecendo há três dias.

Rastreamento de erros é a ferramenta para essa lacuna. Ela recebe exceções, agrupa as idênticas, conta, diz quais são novas e avisa alguém na primeira vez que cada uma acontece.

flowchart TB
  E["Exceção levantada"] --> L["Agregador de logs: um evento entre milhões"]
  E --> S["Rastreador de erros: agrupado, contado, ordenado"]
  L --> F["encontrado quando alguém procura"]
  S --> N["avisado na primeira vez que acontece"]
  S --> C["é nova? está pior? quantas pessoas?"]

O que o agrupamento compra

Um bug produz uma exceção por ocorrência. Se um job em segundo plano falha mil vezes durante a noite, um agregador de logs tem mil eventos e um rastreador de erros tem um problema com contagem de 1.000.

Essa é a diferença inteira, e ela muda o que você consegue perguntar:

• Isso é novo, ou vem acontecendo há um mês?
• Quantas pessoas distintas bateram nisso?
• Começou no deploy de terça?
• Está piorando?

Nada disso é respondível a partir de um fluxo de eventos individuais sem uma agregação que você teria que construir. Rastreamento de erros é essa agregação, com uma opinião no formato do Rails junto.

Onde ele se encaixa

Esta é a quarta ferramenta de observabilidade desta série, e as fronteiras importam mais que as ferramentas:

As sobreposições são reais e não são desperdício. A sua métrica de taxa de erro diz que 2% das requisições falham; o rastreador diz que aquelas falhas são três bugs distintos, um dos quais é novo desde hoje de manhã. A métrica alerta, o rastreador diz o que consertar.

O que chega junto com uma exceção

Um rastreador de erros captura muito mais que a exceção em si, e esse contexto é a maior parte do valor dele:

• A exceção e o backtrace, com os quadros da sua aplicação distinguidos dos quadros de gems.
• A requisição: URL, método, parâmetros, cabeçalhos.
• A pessoa, se você disser quem ela é.
• A release, para um problema poder ser ligado a um deploy.
• Breadcrumbs: a trilha de eventos que levou até a falha, como consultas rodadas, requisições feitas e linhas de log escritas.

Os breadcrumbs são a parte que surpreende na primeira vez. Um NoMethodError em nil não diz nada sozinho; o mesmo erro com as últimas cinco consultas e os parâmetros que o produziram normalmente basta para reproduzir sem perguntar nada a ninguém.

O que este curso cobre

1. Uma exceção não é uma linha de log (esta aula).
2. Instalando e configurando o Sentry.
3. Agrupamento, impressões digitais e ruído.
4. Contexto: tornando um erro reproduzível.
5. Triagem: o que fazer com mil problemas.
6. Resposta a incidentes.
7. Juntando tudo: rastreamento de erros para esta aplicação.

Os exemplos usam Sentry porque é a escolha comum para Rails e porque a configuração dele nomeia os conceitos com clareza. Tudo transfere: as ferramentas diferem em interface e preço, não no que fazem.

Pontos-chave

• Um rastreador de erros agrupa exceções idênticas num problema contado; um agregador de logs as mantém como eventos separados.
• O agrupamento é o que torna respondíveis "isso é novo?", "está pior?" e "quantas pessoas?".
• Métricas alertam que algo está errado; o rastreamento de erros diz quais bugs distintos estão por trás.
• O contexto capturado (requisição, pessoa, release e breadcrumbs) normalmente é o que torna um erro reproduzível.