Application Real-Time Monitoring Service:Configurações personalizadas para aplicações Java

Pré-requisitos

Certifique-se de ter instalado um probe para a sua aplicação. Para obter instruções, consulte Overview of Application Monitoring Integration.

Procedimento

1. Acesse o console do ARMS. No painel de navegação à esquerda, escolha Application Monitoring > Application List.

2. Na página Application List, selecione a região na barra de navegação superior e clique no nome da aplicação.

   Nota

   Os ícones na coluna Language têm os seguintes significados:

   • : uma aplicação Java conectada ao Application Monitoring.

   • : uma aplicação Golang conectada ao Application Monitoring.

   • : uma aplicação Python conectada ao Application Monitoring.

   • -: uma aplicação conectada ao Managed Service for OpenTelemetry.

3. Na barra de navegação superior, escolha Application Configuration > Custom Configurations.

4. Defina os parâmetros de configuração personalizada e clique em Save.

Configurações de amostragem

Na seção Sampling Settings, configure políticas de amostragem, a taxa de amostragem e as características de interfaces sempre amostradas para rastreamentos. Também ative ou desative a amostragem de baixo tráfego. Para mais informações, consulte Select a trace sampling mode (agent V3.2.8 or later).

Configurações de chaves do agente

Na seção Agent Switch Settings, ative ou desative o monitoramento da aplicação e alterne chaves individuais do agente.

Esta seção lista todas as chaves do agente disponíveis em uma grade. ative ou desative o monitoramento para frameworks e recursos específicos conforme necessário.

Configurações de análise de threads

Na seção Thread profiling settings, ative ou desative a chave principal para análise de threads.

Configuração de associação de logs da aplicação

Na seção Application log association configuration, configure informações de source de log para injetar automaticamente TraceId e SpanId. Para mais informações, consulte Log analysis.

• Injeção automática de TraceId e SpanId: Quando ativado, o agente injeta automaticamente o TraceId e o SpanId em seus logs sem alterar a configuração de log.

  Efeito:

  # log4j
  2024.04.12 17:14:18 WARN  log4j-11 c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a simple trace log
  17:14:18 WARN [log4j-ThreadPool-11] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a log with exception
  java.lang.RuntimeException: null
  	at com.example.demo2.TraceIdLogWorker.doWork(TraceIdLogWorker.java:49)
  	at org.apache.arms.java.util.concurrent.ExecutorServiceInterceptor.call(ExecutorServiceInterceptor.java:71)
  	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
  
  # log4j2
  17:14 [Thread.ResolverScan-1] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} This is a log with exception
  java.lang.RuntimeException: null
  	at com.example.demo2.TraceIdLogWorker.doWork(TraceIdLogWorker.java:49)
  	at org.apache.arms.arthas.resolver.DefaultArtifactResolverChain$DefaultTask.execute(DefaultArtifactResolverChain.java:115)
  
  # logback
  17:14:18 WARN [logback-ThreadPool-1] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a simple trace log
  17:14:18 WARN [logback-ThreadPool-1] c.e.d2.TraceIdLogWorker {traceId=8b51c17d03cfd6db4a68d8e8da04fc85, spanId=ea4bfd29b6d36039} [TraceId] This is a log with exception
  java.lang.RuntimeException: null
  	at com.example.demo2.TraceIdLogWorker.doWork(TraceIdLogWorker.java:49)

• Adicionar TraceId ao MDC do log: Por padrão, o agente V4.x e versões posteriores não suportam a obtenção do TraceId usando org.slf4j.MDC.get("EagleEye-TraceID"). Para usar este método, ative esta chave.

Configurações de convergência de URL

Na seção URL Convergence Settings, ative ou desative a convergência de url e configure o limiar e as regras de convergência. A convergência de url agrupa uma série de urls semelhantes e as exibe como uma única entrada. Por exemplo, agrupa urls que começam com /service/demo/. O limiar de convergência é o número mínimo de urls necessárias para acionar a convergência. Por exemplo, se o limiar for 100, um grupo de urls que correspondem à expressão regular da regra só será convergido após a contagem atingir 100. Para mais informações, consulte How ARMS convergence works.

Monitoramento do Arthas

Na seção Arthas Monitoring, ative ou desative o recurso de diagnóstico do Arthas e especifique os endereços IP onde ele deve estar ativo. Para mais informações, consulte Arthas diagnostics.

Configurações de perfilamento contínuo

Na seção Continuous profiling settings, ative ou desative a chave principal, os recursos de ponto de acesso de cpu, ponto de acesso de memória e ponto de acesso de código. Também especifique os endereços IP ou blocos CIDR onde o perfilamento deve estar ativo. Para mais informações, consulte Continuous profiling for Java applications.

Configurações de mascaramento de dados

Na seção Data Masking Settings, você pode configurar regras de mascaramento. O agente então mascara dados como parâmetros do sistema JVM, arquivos YAML do Kubernetes, parâmetros de entrada de métodos e variáveis de ambiente e de sistema do Arthas durante a coleta. Nas regras de mascaramento, os elementos são separados por vírgulas. Cada elemento representa uma expressão regular que não diferencia maiúsculas de minúsculas. Por exemplo, password é equivalente à expressão regular .password..

Quando o agente coleta dados, ele filtra as chaves de dados em relação a essas expressões. Se uma chave corresponder a uma regra, o agente a trata como sensível e mascara seu valor. Por exemplo, se você defina a regra como licenseKey, as informações com a chave -Darms.licenseKey serão mascaradas.

ative o mascaramento de IP, o agente mascara automaticamente as informações que envolvem endereços IP, como endereços de endpoint em várias páginas no console de monitoramento da aplicação. Esse processo não afeta a forma como os dados de monitoramento são exibidos.

Configuração de chamadas de API

Na seção Interface call configuration, configure políticas como o limiar de chamada lenta, listas de permissões de exceções, lista de permissões de códigos de status HTTP e filtragem de chamadas de interface inválidas.

• Limiar de chamada lenta: O valor padrão é 500 ms. Uma chamada de interface é marcada como lenta se o tempo de resposta exceder esse limiar.

• Lista de permissões de códigos de status HTTP:

  Por padrão, os códigos de status HTTP de 400 ou superiores são classificados como chamadas com erro. Se você não quiser classificar determinados códigos de status como erros, insira-os na lista de permissões.

  Esta configuração afeta apenas o HTTP frameworks currently supported by application monitoring.

  Dados afetados: Métricas de contagem de erros para servidores e clientes HTTP (arms_http_requests_error_count, arms_http_client_requests_error_count e arms_app_requests_error_count) e status do span.

  Recursos afetados: As contagens de erros nas abas Overview, Provided Services e Dependencies, bem como o status do span e os alertas de contagem de erros na página Trace Explorer.

  Formato: Insira um único código de status. insira vários códigos, separe-os por vírgulas (,). Não há suporte para correspondência difusa.

  Exemplo: 403,502

  Padrão: Vazio

• Filtragem de chamadas de interface inválidas:

  Se você quiser ocultar determinadas chamadas da aba Provided Services, insira os nomes das interfaces que deseja ignorar. O agente não relatará dados de observabilidade para essas interfaces, e elas não aparecerão na página de chamadas de interface.

  Nota

  • Para agentes Java anteriores à versão V4.2.0, este recurso é eficaz apenas para interfaces que aparecem na aba Provided Services.

  • Para o agente Java V4.2.0 e posteriores, este recurso é eficaz para qualquer LocalRootSpan.

  Dados afetados: Todas as métricas e spans para as interfaces correspondentes são ignorados.

  Recursos afetados: Todas as métricas para as interfaces correspondentes nas abas Overview, Provided Services e Dependencies. O número de spans, o volume de chamadas, a contagem de erros e os alertas de chamadas lentas para as interfaces correspondentes na página Trace Explorer também são afetados.

  Formato: Use uma string ou uma expressão AntPath para corresponder ao nome completo de uma interface inválida. insira várias regras, separe-as por vírgulas (,). O valor padrão é escrito como uma expressão AntPath para garantir a compatibilidade com os dados existentes. Recomendamos que você não o exclua. Adicione novas configurações às regras existentes.

  Exemplo: /api/test/*,/api/playground/create

  Padrão: /**/*.jpg,/**/*.png,/**/*.js,/**/*.jpeg,/**/*.pdf,/**/*.xlsx,/**/*.txt,/**/*.docs,/**/*.gif,/**/*.csv

• Registrar nome da interface upstream nas métricas de chamadas de interface e Registrar nome da aplicação upstream nas métricas de chamadas de interface:

  Propósito: Controla se as métricas de interface registram a aplicação e a interface upstream que fizeram a chamada. Isso afeta principalmente a disponibilidade de dados para service upstream e downstream. Se uma aplicação tiver muitas aplicações upstream, registrar essas informações pode aumentar significativamente o volume de métricas relatadas e gerar custos mais altos.

  Efeito: Após desativar o registro de aplicações e interfaces upstream para métricas de interface, a contagem de dados correspondente cai para zero.

• Registrar código de status original nas métricas de chamadas de interface:

  Propósito: Registra o código de resposta original nas métricas relacionadas à interface HTTP.

  Efeito:

  Após ativar isso, visualize o código de resposta original das interfaces HTTP nos detalhes da chamada de interface. Isso permite estatísticas e análises mais detalhadas dos códigos de status.

• Registrar nome do método HTTP para a interface: Após ativar esta chave, o nome expandido da interface na página interface call inclui o método de solicitação HTTP. Por exemplo, o nome muda de /api/v1/use/{userId} para GET /api/v1/use/{userId}.

Configuração de chamadas de banco de dados

Na seção Database call configuration, você pode configurar o limiar de SQL lento, o comprimento máximo das instruções SQL coletadas e especifique se deve exibir valores de variáveis e constantes nas instruções SQL, além de registrar o tamanho dos valores de retorno de consultas MySQL.

• Exibir valores de variáveis associadas no SQL: Captura valores de variáveis associadas aos parâmetros do PreparedStatement. Essa alteração entra em vigor sem reiniciar a aplicação.

  O agente registra os valores dos parâmetros do PreparedStatement nos atributos do span de chamada de banco de dados correspondente. A chave é db.bindvalue, e o valor é uma lista de valores de variáveis separados por vírgulas. Essa alteração entra em vigor sem reiniciar a aplicação.

  • Esta configuração é suportada por todos os JDBC-based frameworks atualmente suportados pelo ARMS.

  • Tipos de variáveis de banco de dados suportados: Boolean, Byte, Short, Int, Long, Float, Double, BigDecimal e Date.

  • Ativar esta chave incorre em sobrecarga adicional proporcional ao número de variáveis na instrução SQL. Em official stress test scenarios com uma variável, ativar esta chave adiciona menos de 0,5% de sobrecarga de cpu e uma sobrecarga de memória insignificante.

  A figura a seguir mostra o efeito após a ativação desta chave:

  Após ativar isso, visualize o atributo db.bindvalue e seus valores de variáveis correspondentes no painel Span Details de um span de chamada de banco de dados.

• Exibir valores de constantes no SQL: O agente apenas trunca as instruções SQL e não aplica processamento extra. Essa alteração entra em vigor sem reiniciar a aplicação. Se as instruções SQL variarem apenas em valores de constantes, elas podem ficar muito fragmentadas e acabar convergindo para {ARMS_OTHERS}. Recomendamos que você não ative esta opção.

• Registrar string de conexão JDBC original: Por padrão, o agente pode analisar apenas um número limitado de formatos de string de conexão JDBC. Para strings de conexão que o agente não consegue analisar corretamente, ele registra o endpoint como UnknownEndpoint. Se você ativar esta chave, o agente registrará a string de conexão JDBC original. Por exemplo, uma string de conexão jdbc:h2:file que antes não era reconhecida e registrada como UnknownEndpoint é registrada corretamente após a ativação desta chave.

Configurações de propagação de contexto de rastreamento

Na seção Trace Context Propagation Protocol Settings, selecione o trace context propagation protocol que atende às suas necessidades.

Por padrão, o agente ARMS seleciona um protocolo de propagação de contexto de rastreamento com base na presença de cabeçalhos de protocolo específicos nos cabeçalhos de uma solicitação. Para mais informações, consulte ARMS trace context propagation protocol selection policy.

Nesta página, selecione qualquer protocolo como o protocolo prioritário. Após selecionar e salvar a configuração, o ARMS prioriza a detecção dos cabeçalhos de solicitação definidos por esse protocolo. Por exemplo, com a configuração a seguir, o agente detecta os contextos de protocolo na ordem de Jaeger, EagleEye, W3C, SkyWalking e Zipkin para chamadas recebidas.

Você também pode optar por impor um protocolo específico. Por exemplo, com a configuração a seguir, o agente detecta apenas os cabeçalhos de solicitação definidos pelo protocolo Jaeger para chamadas recebidas. Se os cabeçalhos não forem encontrados, ele não verifica outros protocolos, mas gera um novo contexto de rastreamento.

Estratégia de extração e injeção de contexto de rastreamento: O comportamento padrão é extrair o contexto de rastreamento dos service upstream e injetá-lo nas solicitações downstream. configure o comportamento de extração e injeção com esta configuração.

Propósito:

selecione um protocolo de propagação de contexto de rastreamento prioritário ou imposto. Os casos de uso comuns incluem:

• Uma solicitação carrega contextos de rastreamento em vários formatos, e a ordem de análise padrão não atende aos seus requisitos. Você deseja priorizar um protocolo específico. Por exemplo, se uma solicitação carrega contextos de rastreamento W3C e Zipkin, o agente analisa o contexto W3C primeiro por padrão. Você pode defina o protocolo de propagação como Zipkin para analisar o protocolo Zipkin com prioridade.

• Uma solicitação carrega um cabeçalho de protocolo de rastreamento, mas você não deseja reutilizá-lo e quer gerar um novo contexto de rastreamento com base em outro protocolo. Por exemplo, se uma solicitação carrega um contexto de rastreamento Zipkin, o contexto Zipkin é analisado por padrão. Você pode defina o protocolo de propagação como W3C e o modo de propagação como Enforced. Dessa forma, o contexto Zipkin é ignorado e um novo contexto é gerado com base na especificação do protocolo W3C. Observe que, se o modo de propagação não estiver definido como Enforced, o agente ainda tentará analisar o contexto Zipkin após a falha na análise do contexto W3C priorizado.

Efeito:

Após a configuração, cada LocalRootSpan tem um atributo trace.protocol.type que indica o protocolo de rastreamento usado.

Configuração de fila de mensagens

Na seção Message queue configuration, você pode personalizar as informações do consumidor.

• Consumidor RabbitMQ personalizado: Especifique o nome da classe de um consumidor personalizado ou uma classe que contenha um consumidor interno anônimo e visualize o rastreamento desse consumidor. Separe vários nomes de classes de consumidores por vírgulas (,).

• Método de consumo Kafka personalizado: defina um método de consumo personalizado e visualize rastreamentos e métricas ao consumir mensagens com o SDK nativo do Kafka.

• Propagar contexto automaticamente para mensagens Kafka: Ao enviar uma mensagem, adicione cabeçalhos automaticamente à mensagem Kafka para correlacionar os rastreamentos do produtor e do consumidor.

Configuração de coleta do agente

Na seção Agent collection configuration, defina o número máximo de spans coletados por segundo, o limiar máximo de QPS que o agente pode lidar e o nível de log do agente.

• Coletar rastreamentos: Controla se os dados de rastreamento são relatados. Este recurso está ativado por padrão. Se você o desativar, o agente parará de relatar dados de rastreamento.

• Máximo de spans coletados por segundo: O número de spans que o agente pode relatar por segundo. Por motivos de desempenho, o limiar efetivo real pode divergir do limiar configurado em até 5%. Spans que excedem o limite não são relatados.

• Limiar máximo de QPS para o agente: O número de solicitações que o agente pode lidar por segundo. Por motivos de desempenho, o limiar efetivo real pode divergir do limiar configurado em até 5%. O agente não monitora solicitações que excedem esse limiar. Consequentemente, nenhum span é gerado e nenhuma métrica é registrada para essas solicitações, e o recurso de associação de log-TraceId não entra em vigor.

• Coletar dados de chamadas internas sem um ponto de entrada: No ARMS, um ponto de entrada pode ser um service HTTP, um service RPC, uma tarefa agendada ou consumo de mensagens. Chamadas como chamadas de banco de dados e solicitações HTTP de saída que ocorrem dentro da lógica de negócios desses pontos de entrada são consideradas chamadas internas com um ponto de entrada. Por outro lado, chamadas HTTP periódicas, chamadas de banco de dados, chamadas NoSQL, envio de mensagens e chamadas RPC iniciadas por pools de threads do JDK são consideradas chamadas internas sem um ponto de entrada. No agente V4.2.2 e posteriores, você pode filtrar esse tipo de dados com um clique. Por exemplo, o framework Lettuce executa periodicamente comandos para manter a conexão com o Redis saudável. Essas são chamadas internas sem um ponto de entrada. Após desativar a coleta, o agente não coleta mais os dados relacionados.

  Por exemplo, na página NoSQL Analysis, os dados de chamadas gerados por comandos Redis como PING, QUIT e AUTH que são executados automaticamente pelo framework Lettuce não serão mais exibidos.

• Nível de log do agente: Ajusta o nível de log do agente para solução de problemas.

• Relatar logs do agente: Permite que o agente relate seus logs operacionais para o servidor ARMS para uma solução rápida de problemas. Em circunstâncias normais, o agente relata apenas um pequeno número de logs por minuto.

• Ativar relatórios HTTPS: Quando ativado, o agente usa HTTPS para relatar dados.

• Filtro de coleta de métricas padrão: Filtra o relatório de tipos específicos de métricas. Os seguintes tipos são atualmente suportados, e selecione várias opções:

  • custom_entry: Métricas personalizadas para monitoramento de métodos.

  • http: Métricas de servidor HTTP.

  • http_client: Métricas de cliente HTTP.

  • rpc: Métricas de servidor RPC.

  • rpc_client: Métricas de cliente RPC.

  • sql: Métricas relacionadas ao acesso ao banco de dados.

  • nosql: Métricas relacionadas ao acesso a service NoSQL.

  • cache: Métricas relacionadas ao acesso a service de cache.

  • producer: Métricas relacionadas ao envio de mensagens.

  • consumer: Métricas relacionadas ao consumo de mensagens.

  • schedule: Métricas relacionadas a service de agendamento.

• Configuração de Coleta de Métricas Personalizadas: Configura a coleta de métricas definidas pelo SDK do OpenTelemetry. Para mais informações, consulte Customize metrics by using the OpenTelemetry Java SDK.

• Baggage a coletar: Se sua aplicação usar baggage, esta configuração grava itens de baggage específicos em atributos de span, facilitando a recuperação de rastreamentos específicos.

Configuração avançada de filtragem de exceções

Na seção Advanced exception filtering configuration, você pode configurar regras de coleta de exceções.

• Coletar exceções de plugins: Especifica se deve coletar exceções de plugins.

• Profundidade de pilha para diferenciar exceções semelhantes: O valor padrão é 2. Esta profundidade de pilha é usada para identificar tipos semelhantes de exceções. Modificar esta configuração pode causar comportamento estatístico inesperado. Proceda com cuidado.

• Lista de permissões de filtragem de exceções:

  Se você não quiser ver determinadas exceções na aba Exception Analysis, insira os nomes de classe totalmente qualificados das exceções que deseja ocultar. Essas exceções não são contadas e não aparecem na página Exception Analysis.

  Dados afetados: Métricas de contagem de exceções (arms_exception_requests_count_raw e arms_exception_requests_seconds_raw) e informações de exceções em spans.

  Recursos afetados: As métricas para as exceções correspondentes na aba Exception Analysis.

  Formato: Use o nome de classe totalmente qualificado para identificar uma exceção a ser filtrada. Para filtrar várias exceções, separe seus nomes de classe por vírgulas (,).

  Exemplo: java.lang.InterruptedException,java.lang.IndexOutOfBoundsException

  Padrão: Nenhum

• Herdar da classe pai para filtragem de exceções: Quando ativado, se uma exceção coletada for uma subclasse de uma classe de exceção na Lista de permissões de filtragem de exceções, o agente também a filtrará.

  Efeito: Exceções que atendem aos critérios de filtro não são exibidas no console do ARMS.

• Filtragem de mensagens de exceção: Após configurar isso, exceções de um tipo especificado também serão filtradas se o campo de mensagem atender às condições configuradas.

  • Nome da exceção: O tipo de exceção ao qual o filtro se aplica.

  • Condição da mensagem: A condição para a mensagem de exceção, que pode ser startsWith, endsWith ou contains.

  • Palavra-chave da mensagem: A string da palavra-chave.

  Efeito: Exceções que atendem aos critérios de filtro não são exibidas no console do ARMS.

Configuração de monitoramento de pools

Na seção Pool monitoring configuration, você pode configurar regras de coleta para pools de threads e pools de conexões.

• Monitoramento de pool de threads e pool de conexões: Ativa o monitoramento de métricas de pool de threads para frameworks como Tomcat, Dubbo e HSF. Você deve atualizar o agente para a versão mais recente.

• Política de extração de padrão de nome de thread do pool de threads: Por padrão, esta opção substitui todos os caracteres numéricos no nome de qualquer thread em execução em um pool de threads por um asterisco (*). Você também pode configurá-la para substituir apenas os caracteres numéricos finais por um asterisco (*). Se sua aplicação iniciar vários provedores Dubbo em portas diferentes, a política padrão pode agregar seus pools de threads distintos em um só, porque os padrões de nome de thread extraídos são idênticos. Ajuste esta política para distingui-los.

  Efeito: Para um pool de threads típico do Tomcat, o padrão de nome de thread exibido é http-nio-*-exec-* por padrão. Após o ajuste, torna-se http-nio-9099-exec-*.

• Filtragem de cenário de uso do pool de threads e Filtragem de padrão de nome de thread do pool de threads: Filtra as métricas de monitoramento de determinados pools de threads com base em seus cenários de uso e padrões de nome de thread.

  Nota

  Esta configuração é eficaz apenas para o agente Java V4.2.0 e posteriores.

  • Cenário de uso do pool de threads: O contexto no qual o pool de threads é usado. Os cenários suportados incluem Tomcat, Vert.x, Undertow, Dubbo, Jetty, AliyunJavaAgent e default. AliyunJavaAgent representa o pool de threads usado pelo próprio agente, e default representa outros pools de threads não classificados.

  • Padrão de nome de thread do pool de threads: O padrão derivado dos nomes das threads no pool. Por exemplo, http-nio--exec- é um padrão tipicamente obtido substituindo as partes numéricas dos nomes reais das threads por um asterisco (*).

  Dados afetados: Thread pool metrics

  Recursos afetados: A aba Thread Pool Monitoring e os alertas configurados com base nas métricas do pool de threads.

  Formato:

  • Filtragem de cenário de uso do pool de threads: Insira os cenários de uso exibidos na aba de monitoramento do pool de threads. insira vários cenários, separe-os por vírgulas (,).

  • Filtragem de padrão de nome de thread do pool de threads: Insira os padrões de nome de thread exibidos na aba de monitoramento do pool de threads. insira vários padrões, separe-os por vírgulas (,). Isso usa correspondência exata e não suporta correspondência baseada em regras.

  Exemplo:

  • Filtragem de cenário de uso do pool de threads: AliyunJavaAgent,Jetty

  • Filtragem de padrão de nome de thread do pool de threads: Catalina-utility-*,DubboServerHandler-*-thread-*

  Isso significa que o agente não relatará nenhum dado de pool de threads para o cenário AliyunJavaAgent. Para outros cenários, se o padrão de nome de um pool de threads for Catalina-utility-*, o agente também não o relatará.

  Padrão: Nenhum

Configuração de atributos de span

• Registrar atributos da Especificação OTel: A Especificação do OpenTelemetry define os atributos que um span para cada tipo de plugin deve conter. Para reduzir o volume de dados relatados, o agente ARMS não registra todos esses atributos por padrão. ative esta opção com base em seus requisitos. Para mais informações sobre os atributos que são adicionados para cada framework após a ativação desta opção, consulte a Especificação do OpenTelemetry.

  Para um span de servidor HTTP, ativar esta chave adiciona os seguintes atributos.

  Os atributos adicionados incluem informações HTTP como http.path, http.scheme e http.target, bem como informações de rede como net.host.name, net.host.port, net.protocol.name, net.protocol.version, net.sock.peer.addr e net.sock.peer.port.

• Associação de span com tags da aplicação: Controla quais spans são marcados com as tags da aplicação que você vinculou na página Applications. Por padrão, todos os spans incluem tags da aplicação. Para reduzir o volume de uso, você pode optar por anexar tags da aplicação apenas a spans de entrada. Spans de entrada normalmente incluem HTTP Server, RPC Server, consumo de fila de mensagens e tarefas agendadas.

  Por exemplo, se uma aplicação tiver uma tag de aplicação test1:value1 e você configurá-la para ser anexada apenas a spans de entrada:

  Para um span de entrada, visualize os atributos para a tag correspondente.

  Para um span que não é de entrada, ele não contém o atributo test1:value1.

Configurações avançadas

Na seção Advanced settings, defina configurações como interfaces a serem filtradas e o comprimento máximo da pilha de métodos.

• Estatísticas de quantis: especifique se deve ativar estatísticas de quantis.

• Comprimento máximo da pilha de métodos: O valor padrão é 128 quadros, e o valor máximo é 400 quadros.

• Compressão de rastreamento: especifique se deve simplificar chamadas repetitivas, como aquelas em um loop for.

• Comprimento máximo de exibição dos parâmetros de entrada da solicitação: O comprimento padrão é de 512 caracteres, e o comprimento máximo suportado é de 2.048 caracteres.

• Pacote de varredura de propagação de contexto assíncrono: Adicione um pacote de varredura para propagação de contexto assíncrono para monitorar tarefas assíncronas. Quando um novo objeto de uma interface Runnable, Callable ou Supplier no pacote é criado, ele captura automaticamente o contexto de rastreamento da thread atual. Esse contexto é então usado quando a thread assíncrona é executada, completando o rastreamento.

• Incluir TraceId na resposta HTTP: Apenas para solicitações HTTP, isso retorna o campo eagleeye-traceid no cabeçalho de resposta.

• Causa raiz do acionamento de GC da JVM: Quando ativado, visualize a causa raiz dos acionamentos de coleta de lixo (GC) da JVM. Você pode visualizar os detalhes de monitoramento na página JVM Monitoring. Para mais informações sobre as causas de acionamento de GC, consulte GC-related metrics.

Copiar configurações para outras aplicações

Se você precisar aplicar a mesma configuração a outras aplicações, poderá copiar as configurações.

Configuração padrão global

salve a configuração atual como a configuração padrão global. Essa configuração é então aplicada por padrão quando você crie novas aplicações.

1. Na parte inferior da página, clique em Save Current App Settings as Global Default Configuration.

2. Se a caixa de diálogo Current settings not saved aparecer, clique em OK e salve a configuração da aplicação atual e, em seguida, clique em Save Current App Settings as Global Default Configuration novamente.

3. Na caixa de diálogo que aparece, clique em Confirm.

FAQ