Observabilidade: Os Três Pilares

• Definir os três pilares da observabilidade precisamente: logs, métricas e traces, e enunciar o que cada um consegue responder que os outros dois não conseguem.
• Nomear a origem real e de profissional do achado (a escrita de Cindy Sridharan) honestamente, em vez de apresentá-lo como teoria acadêmica resolvida.
• Percorrer um incidente de produção real que só um dos três pilares consegue de fato explicar, e identificar qual e por quê.
• Conectar os três pilares a dois exemplos aplicados já publicados e concretos em duas escalas diferentes: o endpoint de saúde de um serviço único, e a infraestrutura de tracing de um sistema distribuído.

deployment-strategies-blue-green-and-canary terminou com uma dependência explícita que este conceito agora resolve diretamente: um lançamento canary só é significativo se um sinal real e confiável existe comparando o comportamento da nova versão contra o da antiga sob condições ao vivo. A observabilidade é a disciplina de construir exatamente esse sinal, generalizado além dos lançamentos canary para a pergunta mais ampla e constante que todo sistema de produção eventualmente enfrenta: algo está errado, ou pode estar, e a única forma de descobrir é olhando dados que o próprio sistema produz sobre o seu próprio comportamento, já que não há outra forma de inspecionar um sistema distribuído, ao vivo e em execução diretamente.

A própria escrita de Cindy Sridharan, primeiro como um post de blog amplamente lido e depois expandido num ebook curto da O'Reilly, popularizou o enquadramento que este conceito usa, e vale nomear essa origem honestamente: como o conceito SOLID de software-construction e o próprio conceito de Integração Contínua desta disciplina, este é material genuinamente originado de profissional, não teoria acadêmica clássica vestida de algo mais antigo.

Os três pilares, precisamente

text
LOGS:     Registros discretos e com timestamp de eventos individuais,
          cada um carregando um payload de conteúdo (o que aconteceu,
          quais dados estavam envolvidos). Bom para: entender a
          sequência e o detalhe precisos de um evento específico, depois
          de você já suspeitar aproximadamente onde olhar.

MÉTRICAS: Medições numéricas agregadas por entre intervalos de tempo
          (taxa de requisição, taxa de erro, percentis de latência, uso
          de CPU). Bom para: ver uma tendência ou uma violação de
          limiar por todo o sistema ou serviço, de forma barata,
          mesmo quando você ainda não tem ideia de onde olhar.

TRACES:   O caminho causal de UMA requisição à medida que ela flui por
          todo serviço, função ou componente que ela tocou, de ponta
          a ponta. Bom para: entender ONDE, numa cadeia de chamadas
          distribuída, o tempo foi de fato gasto ou uma falha de fato
          ocorreu, quando uma única linha de log ou uma única métrica
          agregada não conseguem mostrar o caminho inteiro.

Nenhum dos três é um superconjunto estrito dos outros; cada um responde um formato genuinamente diferente de pergunta, e um incidente real frequentemente exige mover-se entre todos os três, numa ordem específica e natural.

Por que eles trabalham juntos, numa ordem específica

Uma métrica é geralmente o que primeiro revela que algo está errado de todo, já que ela é barata de computar e checar continuamente, mesmo antes de alguém suspeitar de um problema específico. Uma vez que uma métrica sinaliza uma anomalia real (um pico de taxa de erro, um percentil de latência cruzando um limiar), um trace é o que estreita onde num caminho de requisição distribuída a anomalia está de fato ocorrendo, já que uma métrica sozinha diz que algo está lento ou falhando mas não qual serviço ou chamada específica é responsável. Uma vez que um trace estreita a busca a um serviço ou componente específico, um log é o que revela o detalhe preciso do que de fato aconteceu naquele ponto, a entrada específica, a mensagem de erro específica, os dados específicos envolvidos.

Dois exemplos aplicados em duas escalas diferentes

Esta disciplina deliberadamente não constrói o seu próprio exemplo de ferramental de observabilidade do zero; dois tratamentos aplicados, reais e já publicados, existem neste currículo em duas escalas genuinamente diferentes, e este conceito fundamenta os três pilares em ambos diretamente em vez de duplicar qualquer um. Na escala de um serviço único, spring-boot-actuator-endpoints (spring-concepts) expõe exatamente uma superfície de métricas-e-checagem-de-saúde (um endpoint /actuator/health, um endpoint /actuator/metrics) diretamente embutida numa aplicação Spring Boot em execução, o pilar de métricas tornado concreto para um serviço. Na escala de um sistema distribuído abrangendo muitos serviços, distributed-tracing-and-observability e metrics-monitoring-and-alerting-system (system-design-concepts) cobrem o pilar de traces e um sistema completo de métricas-e-alerta respectivamente, aplicados exatamente às cadeias de chamadas de múltiplos serviços que o próprio endpoint de saúde de um serviço único não consegue ver através.

Exemplo 1: um incidente que só um trace consegue de fato explicar

Uma métrica mostra que a latência p99 do endpoint de checkout geral dobrou ao longo da última hora. Os logs do próprio serviço de checkout não mostram nada de incomum, nenhum erro, nenhuma entrada de log individual lenta. Só um trace revela a causa de fato: o próprio serviço de checkout é rápido, mas ele agora faz uma chamada a jusante a um serviço de inventário que se tornou lento, e essa latência a jusante é o que está aparecendo na métrica geral do endpoint de checkout, invisível tanto aos próprios logs do serviço de checkout (que nunca viram um erro, só uma resposta lenta de outra pessoa) quanto a uma métrica com escopo só ao serviço de checkout isoladamente. A habilidade do trace de mostrar o caminho causal completo e entre serviços é o único dos três pilares que revela onde o problema de fato vive.

Exemplo 2: um incidente que só logs conseguem de fato explicar

Uma métrica mostra que a taxa de falha de um job de fundo específico subiu de perto-de-zero para 2%. Um trace confirma que as falhas estão ocorrendo dentro de um único passo específico do job, mas não mostra nada sobre por que esse passo está falhando, só que está. Só os logs daquele passo específico revelam o detalhe de fato: uma pequena porcentagem de registros de entrada contém um campo de data malformado num formato que o parser não trata, um nível de detalhe específico e concreto que nem a métrica agregada nem a visão de caminho-causal do trace foram jamais projetados para carregar.

Exemplo 3: um incidente que só uma métrica consegue pegar a tempo

Um vazamento de memória lento e gradual num serviço faz com que ele reinicie sob pressão de memória aproximadamente uma vez a cada três dias, cada reinício breve o bastante que usuários individuais raramente notam e nenhuma linha de log específica jamais enuncia "vazamento de memória detectado" (o próprio vazamento não produz nenhum erro, só uso de memória subindo gradualmente). Só uma métrica, rastreando o uso de memória ao longo do tempo e revelando uma tendência lenta e constante para cima por entre cada ciclo de reinício, pega este padrão de todo; nenhum trace ou entrada de log único, cada um com escopo a uma requisição ou um evento, poderia jamais revelar uma tendência que só se torna visível quando agregada e vista por entre dias.

• "Logs, sendo os mais detalhados, são o pilar mais importante e os outros dois são extras opcionais." O Exemplo 3 mostra um problema de produção real e genuíno (um vazamento de memória lento) que os logs não conseguem pegar de todo, já que nenhum evento ou linha de log único jamais enuncia o problema diretamente; uma tendência visível só no agregado, ao longo do tempo, é exatamente para o que uma métrica serve.
• "Uma vez que você tem tracing distribuído, você não precisa mais de métricas." O Exemplo 1 mostra que um trace estreita onde um problema está ocorrendo uma vez que você já suspeita que algo está errado; uma métrica é geralmente o que revela que algo está errado em primeiro lugar, de forma barata e contínua, antes de um trace específico sequer ser aberto para investigar.
• "Observabilidade é um assunto acadêmico resolvido com uma única definição formal canônica." A própria fonte honesta deste conceito (a escrita de profissional de Sridharan, não um artigo acadêmico revisado por pares) reflete o estado real e atual do campo: o enquadramento de três-pilares é real e amplamente adotado na indústria, mas é material genuinamente originado de profissional, a mesma fonte honesta que esta disciplina já aplicou à Integração Contínua e que software-construction já aplicou ao SOLID.

A própria escrita de profissional de Cindy Sridharan popularizou o enquadramento agora padrão da observabilidade como três tipos de dados complementares: logs (eventos discretos e com timestamp carregando detalhe), métricas (medições numéricas agregadas revelando tendências e limiares de forma barata) e traces (o caminho causal de uma requisição por todo serviço que ela tocou). Os três trabalham juntos numa ordem natural durante um incidente real, uma métrica geralmente revela que algo está errado primeiro, um trace estreita onde numa cadeia de chamadas distribuída, e um log revela o detalhe preciso do que de fato aconteceu ali, e nenhum pilar único é um substituto para os outros dois, como os três exemplos resolvidos cada um mostra para um modo de falha diferente e genuíno que só um pilar poderia de fato pegar. Esta disciplina fundamenta o enquadramento em dois tratamentos aplicados e já publicados em duas escalas diferentes, spring-boot-actuator-endpoints para a própria superfície de saúde e métricas de um serviço único, e distributed-tracing-and-observability mais metrics-monitoring-and-alerting-system para um sistema distribuído completo de múltiplos serviços, em vez de construir um terceiro tratamento redundante de qualquer um.