Application Real-Time Monitoring Service:Análise de logs

Por que a correlação de logs falha após alterações no XML?

Caso esse problema ocorra ao consultar logs no SLS, verifique primeiro se os logs estão sendo reportados ao SLS e se você vinculou o projeto e o Logstore corretos no console do ARMS.

Após confirmar que existem dados no SLS, solucione o problema com base nos dois cenários a seguir:

• Nenhum dos logs está correlacionado a um trace ID. Esse problema tem várias causas possíveis:

  • O agente não foi anexado com sucesso.

    Verifique isso conferindo se todas as métricas são exibidas corretamente no console do ARMS.

  • A chave principal do agente está desativada ou certos plug-ins, como o plug-in do Tomcat, estão desligados.

    Confira essa configuração na seção Agent switch settings da página Custom configurations.

  • O framework do lado do servidor não é suportado. Por exemplo, você pode estar usando um container web, framework RPC, framework de tarefas agendadas ou framework de mensagens não suportado. Para obter uma lista de frameworks suportados, consulte Java components and frameworks supported by application monitoring.

  • Você utiliza frameworks de log diferentes de Log4j, Log4j2 ou Logback, ou fez modificações profundas nesses frameworks.

  • A configuração XML do log está incorreta.

    Siga as etapas abaixo para investigar:

    • Se estiver usando a versão 4.1.6 ou posterior do agente, ative o recurso de injeção automática de trace ID. Caso os trace IDs sejam correlacionados com sucesso, isso confirma um erro na configuração XML do log.

    • Importe o ARMS SDK for Java e recupere manualmente o trace ID ao imprimir logs. Veja o código de exemplo:

      Span span = Tracer.builder().getSpan();   // This does not create a new span.
      String traceId = span.getTraceId();
      logger.warn("traceId={} this is your log message", traceId)

      Se conseguir recuperar o trace ID, isso confirma um erro na configuração XML do log.

    • Se ambos os métodos falharem, abra um ticket.

• Alguns logs não estão correlacionados a um trace ID. Isso pode ocorrer porque os logs não possuem contexto de rastreamento.

  Normalmente, os logs não têm contexto de rastreamento quando são gravados. Esse contexto geralmente está presente apenas em logs impressos nos pontos de entrada de requisições, como no código de processamento de interfaces HTTP, interfaces RPC, tarefas agendadas ou consumo de mensagens.

  Cenários de exemplo:

  • Após receber uma requisição HTTP, a aplicação executa uma consulta ao banco de dados e imprime um log. Nesse caso, existe um contexto de rastreamento e o log pode ser correlacionado com sucesso a um trace ID.

  • A aplicação recebe uma requisição HTTP, envia uma tarefa assíncrona para um pool de threads executar uma consulta ao banco de dados e depois imprime um log.

    • No agente v3.x, os logs não podem ser correlacionados a um trace ID porque o agente não suporta propagação assíncrona automática do contexto de rastreamento. A thread assíncrona não possui contexto de rastreamento.

    • No agente v4.x, os logs podem ser correlacionados a um trace ID porque o agente suporta propagação assíncrona automática do contexto de rastreamento. A thread assíncrona possui contexto de rastreamento.

  • Após a inicialização, a aplicação usa um pool de threads do JDK para executar ciclicamente consultas ao banco de dados e imprimir um log após cada consulta. Nessa situação, não há contexto de rastreamento e os logs não podem ser correlacionados a um trace ID.

  Identifique o cenário específico verificando o nome da thread que escreveu o log.

  Por exemplo:

  • Ao usar o Tomcat como container web, nomes de threads que começam com http-nio- geralmente representam threads que lidam com requisições HTTP. Logs impressos por essas threads podem ser correlacionados a um trace ID.

  • Ao usar o Dubbo como framework RPC, nomes de threads que começam com DubboServerHandler- geralmente representam threads que lidam com requisições Dubbo. Logs impressos por essas threads podem ser correlacionados a um trace ID.

  Outros frameworks apresentam comportamento semelhante. Se determinar que o problema não é causado por nenhum desses cenários, abra um ticket.

Por que os logs estão vazios no Trace Explorer?

Siga estas etapas de solução de problemas:

1. Verifique se nenhum dos logs da aplicação está correlacionado a um trace ID. Em caso afirmativo, consulte as etapas de solução de problemas em Why are logs not correlated with trace IDs after I modify the log XML configuration?. Caso contrário, prossiga para a próxima etapa.

2. Se não for possível encontrar logs para um trace ID em uma ou mais interfaces específicas, isso geralmente significa que as interfaces não geraram nenhum log.

3. Se nenhum dos cenários acima se aplicar, abra um ticket.

Por que o Logstore está vazio após a vinculação?

Configure a coleta de logs para o Logstore conforme a documentação do SLS. O ARMS não coleta logs automaticamente para o Logstore.

Por que a correlação de trace ID falha nos logs do gateway?

O agente v3.x possui um defeito conhecido na instrumentação do Spring Cloud Gateway. A atualização para o agente v4.x resolve esse problema.

Por que a correlação de trace ID falha com TraceCallable.wrap()?

Isso indica que o método está sendo usado incorretamente. Recomendamos atualizar para o agente v4.x, que lida com cenários assíncronos sem necessidade de modificação de código.

Por que a correlação de trace ID falha com injeção automática?

Esse problema geralmente ocorre em duas situações:

• Nenhum dos logs está correlacionado a um trace ID: Isso normalmente indica que a configuração não foi aplicada com sucesso ao agente. Verifique a conectividade com o servidor do Application Configuration Management (ACM) consultando a documentação Network configuration for Java application monitoring.

• Alguns logs não estão correlacionados a um trace ID: Consulte as etapas de solução de problemas em Why are logs not correlated with trace IDs after I modify the log XML configuration?.

O ARMS pode substituir o Simple Log Service (SLS)?

Não. O Application Real-Time Monitoring Service (ARMS) e o Simple Log Service (SLS) têm propósitos diferentes e se complementam, em vez de se substituírem.

• O ARMS é um product de Application Performance Monitoring (APM) focado em análise de rastreamento, monitoramento de API e análise de desempenho de aplicações. O recurso de análise de logs do ARMS consulta logs do projeto e Logstore do SLS que você vincula, utilizando o SLS como backend de armazenamento de logs. O ARMS não realiza a coleta de logs para o Logstore.

• O SLS é um service de uso geral para coleta, armazenamento e análise de logs, com suporte à ingestão de dados de múltiplas fontes.

Para usar o recurso de análise de logs do ARMS, vincule um projeto e um Logstore do SLS conforme descrito na Etapa 1: Correlacionar logs de negócios deste tópico. Em seguida, na barra de navegação superior, escolha Scenario-based Analysis > Log Analysis para consultar e analisar os logs.