Application Real-Time Monitoring Service:Configuración personalizada de aplicaciones Java

Requisitos previos

Debe haber instalado un probe para su aplicación. Para consultar las instrucciones, véase Overview of Application Monitoring Integration.

Procedimiento

1. Inicie sesión en la consola de ARMS. En el panel de navegación izquierdo, seleccione Application Monitoring > Application List.

2. En la página Application List, seleccione la región en la barra de navegación superior y luego haga clic en el nombre de la aplicación.

   Nota

   Los iconos en la columna Language tienen los siguientes significados:

   • : una aplicación Java conectada a Application Monitoring.

   • : una aplicación Golang conectada a Application Monitoring.

   • : una aplicación Python conectada a Application Monitoring.

   • -: una aplicación conectada a Managed Service for OpenTelemetry.

3. En la barra de navegación superior, seleccione Application Configuration > Custom Configurations.

4. Establezca los parámetros de configuración personalizada y haga clic en Save.

Configuración de muestreo

En la sección Sampling Settings, puede configurar las directivas de muestreo, la tasa de muestreo y las características de las interfaces siempre muestreadas para los traces. También puede habilitar o deshabilitar el muestreo de bajo tráfico. Para obtener más información, consulte Select a trace sampling mode (agent V3.2.8 or later).

Configuración de interruptores del agente

En la sección Agent Switch Settings, puede habilitar o deshabilitar el monitoreo de aplicaciones y alternar interruptores individuales del agente.

Esta sección enumera todos los interruptores disponibles del agente en una cuadrícula. Puede habilitar o deshabilitar el monitoreo de frameworks y funciones específicos según sea necesario.

Configuración de perfilado de hilos

En la sección Thread profiling settings, puede activar o desactivar el interruptor principal del perfilado de hilos.

Configuración de asociación de registros de aplicación

En la sección Application log association configuration, puede configurar la información de origen de los registros para inyectar automáticamente TraceId y SpanId. Para obtener más información, consulte Log analysis.

• Inyección automática de TraceId y SpanId: Cuando está habilitada, el agente inyecta automáticamente el TraceId y el SpanId en sus registros sin modificar la configuración de registros.

  Efecto:

  # 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)

• Agregar TraceId al MDC de registros: De forma predeterminada, el agente V4.x y versiones posteriores no admiten la obtención del TraceId mediante org.slf4j.MDC.get("EagleEye-TraceID"). Para utilizar este método, habilite este interruptor.

Configuración de convergencia de URL

En la sección URL Convergence Settings, puede habilitar o deshabilitar la convergencia de URL y configurar el umbral y las reglas de convergencia. La convergencia de URL agrupa una serie de URL similares y las muestra como una sola entrada. Por ejemplo, agrupa las URL que comienzan con /service/demo/. El umbral de convergencia es el número mínimo de URL necesarias para activar la convergencia. Por ejemplo, si el umbral es 100, un grupo de URL que coincida con la expresión regular de la regla se convergerá solo después de que el recuento alcance 100. Para obtener más información, consulte How ARMS convergence works.

Monitoreo de Arthas

En la sección Arthas Monitoring, puede habilitar o deshabilitar la función de diagnóstico de Arthas y especificar las direcciones IP donde debe estar activa. Para obtener más información, consulte Arthas diagnostics.

Configuración de perfilado continuo

En la sección Continuous profiling settings, puede activar o desactivar el interruptor principal y las funciones de puntos críticos de CPU, memoria y código. También puede especificar las direcciones IP o bloques CIDR donde debe estar activo el perfilado. Para obtener más información, consulte Continuous profiling for Java applications.

Configuración de desensibilización de datos

En la sección Data Masking Settings, puede configurar reglas de desensibilización. Posteriormente, el agente desensibiliza datos como parámetros del sistema JVM, archivos YAML de Kubernetes, parámetros de entrada de métodos, y variables de entorno y sistema de Arthas durante la recolección. En las reglas de desensibilización, los elementos se separan por comas. Cada elemento representa una expresión regular que no distingue entre mayúsculas y minúsculas. Por ejemplo, password equivale a la expresión regular .password..

Cuando el agente recolecta datos, filtra las claves de datos con base en estas expresiones. Si una clave coincide con una regla, el agente la considera sensible y enmascara su valor. Por ejemplo, si establece la regla como licenseKey, la información con la clave -Darms.licenseKey se desensibilizará.

Después de habilitar la desensibilización de IP, el agente desensibiliza automáticamente la información que involucra direcciones IP, como las direcciones de endpoint en varias páginas de la consola de monitoreo de aplicaciones. Este proceso no afecta la forma en que se muestran los datos de monitoreo.

Configuración de llamadas a API

En la sección Interface call configuration, puede configurar directivas como el umbral de llamada lenta, listas de permitidos de excepciones, lista de permitidos de códigos de estado HTTP y filtrado de llamadas a interfaces no válidas.

• Umbral de llamada lenta: El valor predeterminado es 500 ms. Una llamada a interfaz se marca como lenta si su tiempo de respuesta supera este umbral.

• Lista de permitidos de códigos de estado HTTP:

  De forma predeterminada, los códigos de estado HTTP de 400 o superiores se clasifican como llamadas con error. Si no desea clasificar ciertos códigos de estado como errores, puede agregarlos a la lista de permitidos.

  Esta configuración solo afecta a HTTP frameworks currently supported by application monitoring.

  Datos afectados: Métricas de recuento de errores para servidores y clientes HTTP (arms_http_requests_error_count, arms_http_client_requests_error_count y arms_app_requests_error_count) y estado del span.

  Funciones afectadas: Los recuentos de errores en las pestañas Overview, Provided Services y Dependencies, así como el estado del span y las alertas de recuento de errores en la página Trace Explorer.

  Formato: Introduzca un solo código de estado. Para introducir varios códigos, sepárelos con comas (,). No se admite la coincidencia difusa.

  Ejemplo: 403,502

  Predeterminado: Vacío

• Filtrado de llamadas a interfaces no válidas:

  Si desea ocultar ciertas llamadas en la pestaña Provided Services, puede introducir los nombres de las interfaces que desea ignorar. El agente no reportará datos de observability para estas interfaces, y dichas interfaces no aparecerán en la página de llamadas a interfaces.

  Nota

  • Para agentes de Java anteriores a la V4.2.0, esta función solo es efectiva para las interfaces que aparecen en la pestaña Provided Services.

  • Para el agente de Java V4.2.0 y posteriores, esta función es efectiva para cualquier LocalRootSpan.

  Datos afectados: Se ignoran todas las métricas y spans de las interfaces coincidentes.

  Funciones afectadas: Todas las métricas de las interfaces coincidentes en las pestañas Overview, Provided Services y Dependencies. También se ven afectados el número de spans, el volumen de llamadas, el recuento de errores y las alertas de llamadas lentas para las interfaces coincidentes en la página Trace Explorer.

  Formato: Utilice una cadena o una expresión AntPath para hacer coincidir el nombre completo de una interfaz no válida. Para introducir varias reglas, sepárelas con comas (,). El valor predeterminado se escribe como una expresión AntPath para garantizar la compatibilidad con los datos existentes. Se recomienda no eliminarlo. Agregue nuevas configuraciones a las reglas existentes.

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

  Predeterminado: /**/*.jpg,/**/*.png,/**/*.js,/**/*.jpeg,/**/*.pdf,/**/*.xlsx,/**/*.txt,/**/*.docs,/**/*.gif,/**/*.csv

• Registrar nombre de interfaz ascendente en métricas de llamadas a interfaz y Registrar nombre de aplicación ascendente en métricas de llamadas a interfaz:

  Propósito: Controla si las métricas de interfaz registran la aplicación y la interfaz ascendentes que realizaron la llamada. Esto afecta principalmente la disponibilidad de datos de servicios ascendentes y descendentes. Si una aplicación tiene muchas aplicaciones ascendentes, registrar esta información puede aumentar significativamente el volumen de métricas reportadas y generar costos más altos.

  Efecto: Después de deshabilitar el registro de aplicaciones e interfaces ascendentes para las métricas de interfaz, el recuento de datos correspondientes cae a cero.

• Registrar código de estado original en métricas de llamadas a interfaz:

  Propósito: Registra el código de respuesta original en las métricas relacionadas con interfaces HTTP.

  Efecto:

  Una vez habilitado, puede ver el código de respuesta original de las interfaces HTTP en los detalles de llamadas a interfaz. Esto permite estadísticas y análisis más detallados de los códigos de estado.

• Registrar nombre de método HTTP para interfaz: Después de habilitar este interruptor, el nombre expandido de la interfaz en la página interface call incluye el método de solicitud HTTP. Por ejemplo, el nombre cambia de /api/v1/use/{userId} a GET /api/v1/use/{userId}.

Configuración de llamadas a base de datos

En la sección Database call configuration, puede configurar el umbral de SQL lento, la longitud máxima de las sentencias SQL recolectadas, y especificar si se muestran valores constantes y de variables vinculadas en las sentencias SQL, así como si se registra el tamaño de los valores de retorno de consultas MySQL.

• Mostrar valores de variables vinculadas en SQL: Captura los valores de las variables vinculadas a los parámetros PreparedStatement. Este cambio surte efecto sin reiniciar la aplicación.

  El agente registra los valores de los parámetros PreparedStatement en los atributos del span de llamada a base de datos correspondiente. La clave es db.bindvalue y el valor es una lista de valores de variables separados por comas. Este cambio surte efecto sin reiniciar la aplicación.

  • Todas las JDBC-based frameworks compatibles actualmente con ARMS admiten esta configuración.

  • Tipos de variables de base de datos admitidos: Boolean, Byte, Short, Int, Long, Float, Double, BigDecimal y Date.

  • Habilitar este interruptor genera una sobrecarga adicional proporcional al número de variables en la sentencia SQL. En official stress test scenarios con una variable, habilitar este interruptor añade menos del 0.5% de sobrecarga de CPU y una sobrecarga de memoria insignificante.

  La siguiente figura muestra el efecto tras habilitar este interruptor:

  Una vez habilitado, puede ver el atributo db.bindvalue y sus valores de variables correspondientes en el panel Span Details de un span de llamada a base de datos.

• Mostrar valores constantes en SQL: El agente solo trunca las sentencias SQL y no aplica procesamiento adicional. Este cambio surte efecto sin reiniciar la aplicación. Si las sentencias SQL varían solo en valores constantes, pueden fragmentarse demasiado y terminar convergiendo en {ARMS_OTHERS}. Se recomienda no habilitar esta opción.

• Registrar cadena de conexión JDBC original: De forma predeterminada, el agente solo puede analizar un número limitado de formatos de cadenas de conexión JDBC. Para las cadenas de conexión que el agente no puede analizar correctamente, registra el endpoint como UnknownEndpoint. Si habilita este interruptor, el agente registra la cadena de conexión JDBC original. Por ejemplo, una cadena de conexión jdbc:h2:file que anteriormente no se reconocía y se registraba como UnknownEndpoint se registra correctamente después de habilitar este interruptor.

Configuración de propagación de contexto de trace

En la sección Trace Context Propagation Protocol Settings, puede seleccionar el trace context propagation protocol que se ajuste a sus necesidades.

De forma predeterminada, el agente de ARMS selecciona un protocolo de propagación de contexto de trace basándose en si los encabezados de una solicitud contienen encabezados de protocolo específicos. Para obtener más información, consulte ARMS trace context propagation protocol selection policy.

En esta página, puede seleccionar cualquier protocolo como protocolo prioritario. Después de seleccionar y guardar la configuración, ARMS prioriza la detección de los encabezados de solicitud definidos por ese protocolo. Por ejemplo, con la siguiente configuración, el agente detecta los contextos de protocolo en el orden de Jaeger, EagleEye, W3C, SkyWalking y Zipkin para las llamadas entrantes.

También puede optar por aplicar un protocolo específico. Por ejemplo, con la siguiente configuración, el agente solo detecta los encabezados de solicitud definidos por el protocolo Jaeger para las llamadas entrantes. Si no se encuentran los encabezados, no busca otros protocolos, sino que genera un nuevo contexto de trace.

Estrategia de extracción e inyección de contexto de trace: El comportamiento predeterminado es extraer el contexto de trace de los servicios ascendentes e inyectarlo en las solicitudes descendentes. Puede configurar el comportamiento de extracción e inyección con este ajuste.

Propósito:

Puede seleccionar un protocolo de propagación de contexto de trace prioritario u obligatorio. Los casos de uso comunes incluyen:

• Una solicitud lleva contextos de trace en múltiples formatos y el orden de análisis predeterminado no cumple con sus requisitos. Desea priorizar un protocolo específico. Por ejemplo, si una solicitud lleva contextos de trace tanto de W3C como de Zipkin, el agente analiza primero el contexto de trace de W3C de forma predeterminada. Puede establecer el protocolo de propagación en Zipkin para analizar el protocolo Zipkin con prioridad.

• Una solicitud lleva un encabezado de protocolo de trace, pero no desea reutilizarlo y quiere generar un nuevo contexto de trace basado en otro protocolo. Por ejemplo, si una solicitud lleva un contexto de trace de Zipkin, el contexto de trace de Zipkin se analiza de forma predeterminada. Puede establecer el protocolo de propagación en W3C y el modo de propagación en Enforced. De esta manera, se ignora el contexto de trace de Zipkin y se genera un nuevo contexto basado en la especificación del protocolo W3C. Tenga en cuenta que si el modo de propagación no se establece en Enforced, el agente todavía intenta analizar el contexto de Zipkin después de que falla el análisis del contexto de W3C priorizado.

Efecto:

Después de la configuración, cada LocalRootSpan tiene un atributo trace.protocol.type que indica el protocolo de trace utilizado.

Configuración de cola de mensajes

En la sección Message queue configuration, puede personalizar la información del consumidor.

• Consumidor personalizado de RabbitMQ: Especifique el nombre de clase de un consumidor personalizado o una clase que contenga un consumidor interno anónimo para ver el trace de ese consumidor. Separe varios nombres de clases de consumidores con comas (,).

• Método de consumo personalizado de Kafka: Defina un método de consumo personalizado para ver traces y métricas al consumir mensajes con el SDK nativo de Kafka.

• Propagar contexto automáticamente para mensajes de Kafka: Al enviar un mensaje, agrega automáticamente encabezados al mensaje de Kafka para correlacionar los traces del productor y del consumidor.

Configuración de recolección del agente

En la sección Agent collection configuration, puede establecer el número máximo de spans recolectados por segundo, el umbral máximo de QPS que el agente puede manejar y el nivel de registro del agente.

• Recolectar traces: Controla si se reportan datos de trace. Esta función está habilitada de forma predeterminada. Si la deshabilita, el agente deja de reportar datos de trace.

• Máximo de spans recolectados por segundo: El número de spans que el agente puede reportar por segundo. Por razones de rendimiento, el umbral efectivo real puede desviarse del umbral configurado hasta en un 5%. Los spans que superan el límite no se reportan.

• Umbral máximo de QPS para el agente: El número de solicitudes que el agente puede manejar por segundo. Por razones de rendimiento, el umbral efectivo real puede desviarse del umbral configurado hasta en un 5%. El agente no monitorea las solicitudes que superan este umbral. En consecuencia, no se generan spans ni se registran métricas para estas solicitudes, y la función de asociación de registro-TraceId no surte efecto.

• Recolectar datos de llamadas internas sin punto de entrada: En ARMS, un punto de entrada puede ser un servicio HTTP, un servicio RPC, una tarea programada o el consumo de mensajes. Las llamadas, como las llamadas a bases de datos y las solicitudes HTTP salientes que ocurren dentro de la lógica de negocio de estos puntos de entrada, se consideran llamadas internas con un punto de entrada. Por el contrario, las llamadas HTTP periódicas, las llamadas a bases de datos, las llamadas NoSQL, el envío de mensajes y las llamadas RPC iniciadas por pools de hilos JDK se consideran llamadas internas sin un punto de entrada. En el agente V4.2.2 y posteriores, puede filtrar este tipo de datos con un solo clic. Por ejemplo, el framework Lettuce ejecuta periódicamente comandos para mantener sana la conexión a Redis. Estas son llamadas internas sin un punto de entrada. Después de deshabilitar la recolección, el agente ya no recolecta los datos relacionados.

  Por ejemplo, en la página NoSQL Analysis, ya no se mostrarán los datos de llamadas generados por comandos de Redis como PING, QUIT y AUTH que el framework Lettuce ejecuta automáticamente.

• Nivel de registro del agente: Ajusta el nivel de registro del agente para la resolución de problemas.

• Reportar registros del agente: Permite que el agente reporte sus registros operativos al servidor de ARMS para una rápida resolución de problemas. En circunstancias normales, el agente reporta solo una pequeña cantidad de registros por minuto.

• Habilitar reporte HTTPS: Cuando está habilitado, el agente usa HTTPS para reportar datos.

• Filtro predeterminado de recolección de métricas: Filtra el reporte de tipos específicos de métricas. Actualmente se admiten los siguientes tipos, y puede seleccionar varias opciones:

  • custom_entry: Métricas personalizadas para monitoreo 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 con el acceso a bases de datos.

  • nosql: Métricas relacionadas con el acceso a servicios NoSQL.

  • cache: Métricas relacionadas con el acceso a servicios de caché.

  • producer: Métricas relacionadas con el envío de mensajes.

  • consumer: Métricas relacionadas con el consumo de mensajes.

  • schedule: Métricas relacionadas con servicios de programación.

• Configuración de recolección de métricas personalizadas: Configura la recolección de métricas definidas por el SDK de OpenTelemetry. Para obtener más información, consulte Customize metrics by using the OpenTelemetry Java SDK.

• Baggage a recolectar: Si su aplicación utiliza baggage, esta configuración escribe elementos específicos de baggage en los atributos del span, lo que facilita la recuperación de traces específicos.

Configuración avanzada de filtrado de excepciones

En la sección Advanced exception filtering configuration, puede configurar reglas de recolección de excepciones.

• Recolectar excepciones de plugins: Especifica si se deben recolectar excepciones de plugins.

• Profundidad de pila para diferenciar excepciones similares: El valor predeterminado es 2. Esta profundidad de pila se utiliza para identificar tipos similares de excepciones. Modificar esta configuración puede causar un comportamiento estadístico inesperado. Proceda con precaución.

• Lista de permitidos de filtrado de excepciones:

  Si no desea ver ciertas excepciones en la pestaña Exception Analysis, puede introducir los nombres de clase totalmente calificados de las excepciones que desea ocultar. Estas excepciones no se cuentan y no aparecen en la página Exception Analysis.

  Datos afectados: Métricas de recuento de excepciones (arms_exception_requests_count_raw y arms_exception_requests_seconds_raw) e información de excepciones en spans.

  Funciones afectadas: Las métricas de las excepciones correspondientes en la pestaña Exception Analysis.

  Formato: Utilice el nombre de clase totalmente calificado para identificar una excepción a filtrar. Para filtrar varias excepciones, separe sus nombres de clase con comas (,).

  Ejemplo: java.lang.InterruptedException,java.lang.IndexOutOfBoundsException

  Predeterminado: Ninguna

• Heredar de clase padre para filtrado de excepciones: Cuando está habilitado, si una excepción recolectada es una subclase de una clase de excepción en la Lista de permitidos de filtrado de excepciones, el agente también la filtra.

  Efecto: Las excepciones que cumplen con los criterios de filtro no se muestran en la consola de ARMS.

• Filtrado de mensajes de excepción: Después de configurar esto, las excepciones de un tipo especificado también se filtran si su campo de mensaje cumple con las condiciones configuradas.

  • Nombre de excepción: El tipo de excepción al que se aplica el filtro.

  • Condición de mensaje: La condición para el mensaje de excepción, que puede ser startsWith, endsWith o contains.

  • Palabra clave de mensaje: La cadena de palabras clave.

  Efecto: Las excepciones que cumplen con los criterios de filtro no se muestran en la consola de ARMS.

Configuración de monitoreo de pools

En la sección Pool monitoring configuration, puede configurar reglas de recolección para pools de hilos y pools de conexiones.

• Monitoreo de pool de hilos y pool de conexiones: Habilita el monitoreo de métricas de pool de hilos para frameworks como Tomcat, Dubbo y HSF. Debe actualizar el agente a la última versión.

• Directiva de extracción de patrón de nombre de hilo de pool de hilos: De forma predeterminada, esta opción reemplaza todos los caracteres numéricos en el nombre de cualquier hilo en ejecución dentro de un pool de hilos con un asterisco (*). También puede configurarla para reemplazar solo los caracteres numéricos finales con un asterisco (*). Si su aplicación inicia varios proveedores Dubbo en diferentes puertos, la directiva predeterminada puede agregar sus distintos pools de hilos en uno solo porque los patrones de nombres de hilos extraídos son idénticos. Ajuste esta directiva para distinguirlos.

  Efecto: Para un pool de hilos típico de Tomcat, el patrón de nombre de hilo mostrado es http-nio-*-exec-* de forma predeterminada. Después del ajuste, se convierte en http-nio-9099-exec-*.

• Filtrado de escenario de uso de pool de hilos y Filtrado de patrón de nombre de hilo de pool de hilos: Filtra las métricas de monitoreo de ciertos pools de hilos según sus escenarios de uso y patrones de nombres de hilos.

  Nota

  Esta configuración solo es efectiva para el agente de Java V4.2.0 y posteriores.

  • Escenario de uso de pool de hilos: El contexto en el que se utiliza el pool de hilos. Los escenarios admitidos incluyen Tomcat, Vert.x, Undertow, Dubbo, Jetty, AliyunJavaAgent y default. AliyunJavaAgent representa el pool de hilos utilizado por el propio agente, y default representa otros pools de hilos no clasificados.

  • Patrón de nombre de hilo de pool de hilos: El patrón derivado de los nombres de los hilos en el pool. Por ejemplo, http-nio--exec- es un patrón que se obtiene típicamente al reemplazar las partes numéricas de los nombres reales de los hilos con un asterisco (*).

  Datos afectados: Thread pool metrics

  Funciones afectadas: La pestaña Thread Pool Monitoring y las alertas configuradas con base en métricas de pool de hilos.

  Formato:

  • Filtrado de escenario de uso de pool de hilos: Introduzca los escenarios de uso mostrados en la pestaña de monitoreo de pool de hilos. Para introducir varios escenarios, sepárelos con comas (,).

  • Filtrado de patrón de nombre de hilo de pool de hilos: Introduzca los patrones de nombres de hilos mostrados en la pestaña de monitoreo de pool de hilos. Para introducir varios patrones, sepárelos con comas (,). Esto utiliza coincidencia exacta y no admite coincidencia basada en reglas.

  Ejemplo:

  • Filtrado de escenario de uso de pool de hilos: AliyunJavaAgent,Jetty

  • Filtrado de patrón de nombre de hilo de pool de hilos: Catalina-utility-*,DubboServerHandler-*-thread-*

  Esto significa que el agente no reportará ningún dato de pool de hilos para el escenario AliyunJavaAgent. Para otros escenarios, si el patrón de nombre de un pool de hilos es Catalina-utility-*, el agente tampoco lo reportará.

  Predeterminado: Ninguna

Configuración de atributos de span

• Registrar atributos de especificación OTel: La Especificación de OpenTelemetry define los atributos que debe contener un span para cada tipo de plugin. Para reducir el volumen de reporte de datos, el agente de ARMS no registra todos estos atributos de forma predeterminada. Puede habilitar esta opción según sus necesidades. Para obtener más información sobre los atributos que se agregan para cada framework después de habilitar esta opción, consulte la Especificación de OpenTelemetry.

  Para un span de servidor HTTP, habilitar este interruptor agrega los siguientes atributos.

  Los atributos agregados incluyen información HTTP como http.path, http.scheme y http.target, así como información de red como net.host.name, net.host.port, net.protocol.name, net.protocol.version, net.sock.peer.addr y net.sock.peer.port.

• Asociación de span con etiquetas de aplicación: Controla qué spans se etiquetan con las etiquetas de aplicación que ha vinculado en la página Applications. De forma predeterminada, todos los spans incluyen etiquetas de aplicación. Para reducir el volumen de uso, puede optar por adjuntar etiquetas de aplicación solo a los spans de entrada. Los spans de entrada suelen incluir Servidor HTTP, Servidor RPC, consumo de cola de mensajes y tareas programadas.

  Por ejemplo, si una aplicación tiene una etiqueta de aplicación test1:value1 y configura que se adjunte solo a los spans de entrada:

  Para un span de entrada, puede ver los atributos de la etiqueta correspondiente.

  Para un span que no es de entrada, no contiene el atributo test1:value1.

Configuración avanzada

En la sección Advanced settings, puede configurar ajustes como interfaces a filtrar y la longitud máxima de la pila de métodos.

• Estadísticas de cuantiles: Especifica si se habilitan las estadísticas de cuantiles.

• Longitud máxima de pila de métodos: El valor predeterminado es 128 marcos y el valor máximo es 400 marcos.

• Compresión de trace: Especifica si se simplifican las llamadas repetitivas, como las de un bucle for.

• Longitud máxima de visualización de parámetros de entrada de solicitud: La longitud predeterminada es de 512 caracteres y la longitud máxima admitida es de 2,048 caracteres.

• Paquete de escaneo de propagación de contexto asíncrono: Agregue un paquete de escaneo para la propagación de contexto asíncrono con el fin de monitorear tareas asíncronas. Cuando se crea un nuevo objeto de una interfaz Runnable, Callable o Supplier en el paquete, captura automáticamente el contexto de trace del hilo actual. Luego, este contexto se utiliza cuando se ejecuta el hilo asíncrono, completando el trace.

• Incluir TraceId en respuesta HTTP: Solo para solicitudes HTTP, esto devuelve el campo eagleeye-traceid en el encabezado de respuesta.

• Causa raíz de activación de GC de JVM: Cuando está habilitado, puede ver la causa raíz de las activaciones de recolección de basura (GC) de la JVM. Puede ver los detalles de monitoreo en la página JVM Monitoring. Para obtener más información sobre las causas de activación de GC, consulte GC-related metrics.

Copiar configuraciones a otras aplicaciones

Si necesita aplicar la misma configuración a otras aplicaciones, puede copiar los ajustes.

Configuración predeterminada global

Puede guardar la configuración actual como la configuración predeterminada global. Esta configuración se aplica entonces de forma predeterminada cuando crea nuevas aplicaciones.

1. En la parte inferior de la página, haga clic en Save Current App Settings as Global Default Configuration.

2. Si aparece el cuadro de diálogo Current settings not saved, haga clic en OK para guardar la configuración de la aplicación actual y luego haga clic nuevamente en Save Current App Settings as Global Default Configuration.

3. En el cuadro de diálogo que aparece, haga clic en Confirm.

Preguntas frecuentes