Divisão de limites de logs, indicadores e rastreamento

A primeira reação de muitas equipes ao tentar complementar a observabilidade é “conectar logs, indicadores e rastreamento”.

Esta frase parece correta, mas o verdadeiro problema é o próximo passo: todas as três coisas estão conectadas, mas os limites não estão determinados, então cada método é limpar o traseiro dos outros dois.

Os resultados geralmente são muito familiares: os rótulos dos indicadores explodem, a amostragem do rastreamento aumenta totalmente, o volume de log dobra a cada mês, os alarmes ainda são imprecisos e a solução de problemas ainda depende do grep humano. Não faltam ferramentas, mas o sistema não se tornou realmente mais observável.

Minha opinião é: **Os limites dos registros, indicadores e rastreamento não devem ser traçados pela “aparência dos dados”, mas pela “qual decisão tomar a seguir”. **

• O indicador responde: se deve ser tratado imediatamente e se o alcance do impacto é grande;
• Rastreando respostas: Em qual seção do link o problema provavelmente está preso?
• O log responde: O que exatamente aconteceu naquele trecho de código daquela solicitação.

Os três estão em uma relação de custos crescentes de tomada de decisão. O indicador é o mais barato e adequado para monitoramento contínuo do mercado; O rastreamento é mais caro e adequado para estreitar o alcance; a tora é a mais pesada e adequada para a restauração final da cena.

Se o log for responsável por alarmar, o Tracing for responsável pela auditoria e os indicadores forem responsáveis ​​por cada usuário, cada pedido e cada dimensão SQL, o sistema certamente conseguirá rodar, mas o preço será muito honesto em armazenamento, consulta, amostragem, controle de cardinalidade e solução de problemas humanos.

A verdadeira primeira decisão devem ser os indicadores.

Quando há uma falha na linha, o primeiro passo geralmente é “julgar se vale a pena lidar com ela imediatamente”.

Esta etapa é mais adequada para indicadores. Superficialmente, parece que o indicador é mais avançado, mas na verdade está mais próximo dele e é o mais barato.

Um bom sistema de indicadores deve responder às seguintes questões em dezenas de segundos:

• A taxa de erro está aumentando ou é apenas um ruído ocasional?
• A variação do atraso é global ou concentrada em uma determinada interface?
• O impacto ocorre em uma máquina, em uma sala de informática ou em toda a cadeia de chamadas;
• O problema simplesmente aconteceu ou já dura meia hora?

Esses problemas fazem essencialmente a mesma coisa: **Usar agregação de informações de baixo custo em troca de julgamentos de ações de alto valor. **

Portanto, o princípio de concepção mais importante dos indicadores é “eles também podem apoiar a tomada de decisões após a agregação”.

Muitas equipes obtêm indicadores ruins ao usar campos de alta cardinalidade que não deveriam ser incluídos nos indicadores, como user_id, order_id, trace_id, URLs completos e mensagens de erro dinâmicas. Isto é muito satisfatório no curto prazo e parece que tudo pode ser feito; no médio prazo, a expansão do armazenamento, a lentidão das consultas e as dimensões dos alarmes começarão a ficar fora de controle; o resultado a longo prazo geralmente é que a própria equipe tem medo de usar a plataforma de indicadores.

Os indicadores são adequados para expressar tendências e distribuições em dimensões estáveis, como nomes de interfaces, códigos de status, salas de computadores, serviços dependentes e ocorrências de cache. O valor destas dimensões não é “restaurar uma solicitação específica”, mas ajudar a determinar rapidamente se o problema ocorre em clusters.

Uma vez que a pergunta que você deseja fazer é “Qual pedido falhou?”, não é mais uma pergunta que o indicador deva responder sozinho.

O valor do Tracing está em encurtar o caminho de posicionamento

O rastreamento costuma ser mal interpretado como “registro mais avançado do que registro”. Isso irá consumi-lo diretamente.

O que o Tracing é realmente bom é descrever o caminho e o relacionamento demorado de uma solicitação entre serviços e componentes. É naturalmente adequado para responder a perguntas como esta:

• A lentidão é causada pelo gateway, aplicação, banco de dados ou dependências externas?
• Uma nova tentativa, cujo salto é amplificado;
• Se o P99 de uma determinada interface for tão alto, isso está relacionado a um determinado serviço downstream?
• Uma solicitação anormal começa a se desviar do caminho normal após passar por quais serviços.

Em outras palavras, **Tracing fornece uma estrutura de link, não uma cena completa. **

Portanto, o que ele mais deve carregar são informações de caminho, tempo de estágio principal e um pequeno número de tags que podem ajudar na filtragem, em vez de preencher completamente objetos de negócios nele, e muito menos transformar cada variável local em um atributo span.

Já vi muitas equipes tentarem torná-lo uma fonte unificada de verdade assim que iniciam o rastreamento: o texto SQL original deve ser interrompido, a entrada do usuário deve ser suspensa, o corpo completo da resposta deve ser suspenso e todos os parâmetros de nova tentativa devem ser suspensos. O resultado final é:

• O tamanho do intervalo aumenta rapidamente e a taxa de amostragem é forçada a diminuir;
• Ao consultar o link, o ruído é muito maior que o sinal;
• Quando efetivamente chegamos ao local do acidente, o pedido da chave não foi deixado por causa da amostragem;
• A governança de dados confidenciais começa a se tornar um novo custo de manutenção.

O momento mais valioso para o rastreamento é quando você pode usar um link para determinar rapidamente qual serviço, intervalo e seção de log devem ser visualizados no próximo salto.

Se for tão pesado que não possa ser retido globalmente de forma estável, ou for tão pesado que consultá-lo mesmo que seja doloroso, então a fronteira foi ultrapassada.

O log não é o segundo sistema de indicadores, é o material final de coleta de evidências

O log é o mais fácil de julgar mal porque parece que pode conter qualquer coisa.

Na verdade, o tronco está mais próximo da cena. Como a ramificação foi realizada, a aparência dos parâmetros, quantas vezes ela foi tentada novamente, qual caminho de downgrade foi atingido e por que um resultado aparentemente bem-sucedido, mas semanticamente incorreto, foi retornado desta vez, muitas vezes só pode ser visto nos logs.

Mas precisamente por ter a maior entropia de informação, é o menos adequado para “observação global contínua”.

Usar logs como principal fonte de monitoramento tem três consequências comuns.

Primeiro, o custo da consulta é alto. **Sempre, são tiradas conclusões temporárias dos fatos originais, que são lentos e têm pouca estabilidade.

Em segundo lugar, o som é extremamente barulhento. ** Quando o volume de logs for grande, a equipe naturalmente reduzirá a impressão; uma vez reduzida a impressão, as principais filiais muitas vezes carecem de provas; no final, todos irão alternar entre “muito para ver” e “muito pouco para ver”.

Terceiro, pode induzir maus hábitos de engenharia. ** Muitos desenvolvedores criam uma camada extra de registro quando encontram um problema e, como resultado, o sistema fica mais barulhento. O que realmente precisa ser complementado são logs de eventos com limites claros, logs de erros com contexto e IDs de solicitação que podem ser associados, em vez de mais “inserir métodos”, “deixar métodos”, “iniciar processamento” e “processamento concluído”.

O local mais apropriado para o log é usar indicadores para determinar “há realmente um problema aqui” e usar o rastreamento para saber “o problema provavelmente está aqui” e, em seguida, usá-lo para restaurar uma solicitação específica.

Em outras palavras, os registros devem servir ao propósito de investigação forense, não de patrulhamento.

Uma simples divisão de trabalho é mais eficaz do que “todos os três itens”

A abordagem que recomendo é simples: defina primeiro a sequência de solução de problemas e depois defina os limites da coleção.

Uma solução de problemas online pode ser dividida em três etapas.

1. Primeiro utilizar indicadores para determinar se existem problemas sistémicos;
2. Em seguida, use o rastreamento para convergir o problema para o estágio de serviço e link;
3. Por fim, use o log para explicar por que a solicitação foi assim.

Se o design incorporado não puder suportar esta sequência, geralmente é porque as responsabilidades foram atribuídas de forma errada.

O que se segue é uma forma relativamente contida de escrever:

func CreateOrder(ctx context.Context, req CreateOrderReq) error {
  start := time.Now()
  defer metrics.OrderCreateLatency.Observe(time.Since(start).Seconds())

  ctx, span := tracer.Start(ctx, "order.create")
  defer span.End()
  span.SetAttributes(
    attribute.String("payment_provider", req.Provider),
    attribute.Bool("has_coupon", req.CouponID != ""),
  )

  err := service.Create(ctx, req)
  if err != nil {
    metrics.OrderCreateErrors.WithLabelValues(classify(err)).Inc()
    logger.Error("create order failed",
      "request_id", requestid.FromContext(ctx),
      "provider", req.Provider,
      "err", err,
    )
    return err
  }
  return nil
}

Existem três limites aqui que são intencionalmente restringidos.

• O indicador retém apenas dimensões que ainda têm valor de decisão após agregação, como erros de classificação;
• O rastreamento trava apenas alguns atributos que podem ajudar a filtrar caminhos, em vez de todo o corpo da solicitação;
• O log registra apenas o contexto principal no caminho com falha e tem garantia de associação ao link por meio de request_id.

Este design não é sofisticado, mas resolve um problema muito real: após a ocorrência de um acidente, a equipe pode abordar a resposta do baixo ao alto custo, em vez de mergulhar nos dados mais caros desde o início. **

Um mal-entendido comum: entender “observabilidade unificada” como “agregar todos os dados”

Agora, muitas plataformas falam em observação unificada. Não há nada de errado com isto em si, o problema reside na forma como é implementado.

Algumas equipes entendem a unificação como “todos os dados entram em uma plataforma, todos os campos estão conectados entre si e é melhor resolver todos os problemas com uma consulta”. Esta ideia é tentadora porque parece eliminar os limites da ferramenta; mas na engenharia, muitas vezes elimina limites de custos.

A direção correta para a unificação é conectá-los com baixo atrito.

Por exemplo:

• Os alarmes indicadores podem saltar diretamente para serviços e janelas de tempo relevantes;
• o rastreamento pode encontrar o log correspondente de acordo com request_id ou código de erro;
• Os logs podem trazer contexto de rastreamento em vez de funcionarem de forma independente.

Isso se chama China Unicom, não de uso misto.

O perigo real é que todas as questões só possam ser respondidas pela camada mais pesada de dados.

Contra-exemplos e limites: nem todos os sistemas requerem um conjunto completo de três peças

Admita também que em algumas cenas os limites não precisam ser contados tão completamente.

Para ferramentas internas de baixo QPS, scripts em lote independentes e tarefas offline muito estáveis, os logs podem ser suficientes; para serviços com links de solicitação curtos e dependências simples, os benefícios do rastreamento podem não ser tão altos quanto o esperado; para determinados cenários de auditoria sujeitos a restrições de conformidade, você não deve esperar que o rastreamento ou os logs comuns do aplicativo sirvam como registros formais de auditoria.

Portanto, este artigo está dizendo: **Contanto que você decida fazer três coisas, não deixe que elas se substituam. **

Quanto mais complexo o sistema, mais responsabilidades precisam ser reduzidas. Caso contrário, o que será eliminado hoje será o limite do design, e o que será adicionado amanhã será a conta da plataforma, o tempo de solução de problemas e a carga cognitiva da equipe.

Resumo

A coisa mais assustadora sobre a observabilidade é que cada camada quer responder a todas as perguntas.

Os indicadores devem permitir que você decida se deve agir o mais rápido possível, o rastreamento deve permitir que você decida onde procurar primeiro o mais rápido possível e os registros devem informar o que aconteceu o mais rápido possível.

Se a ordem dessas três ações for confusa, não importa quão completas elas sejam, isso apenas irá enterrar ainda mais o custo da solução de problemas.