Application Real-Time Monitoring Service:Modos de muestreo de trazas (Agent V3.2.8 o posterior)

Conceptos clave

• span: Una operación específica dentro de una solicitud, como una entrada de llamada remota o una invocación de método interno.

• root span: El primer span en una traza.

• local root span: El primer span de un segmento de traza dentro de una sola aplicación.

• span context: Información que se propaga con una solicitud para vincular todas las operaciones dentro de la misma traza.

• head-based sampling: Una estrategia de muestreo que se ejecuta únicamente en el root span. En la mayoría de los casos, este método conserva una traza completa.

• non-head-based sampling: Una estrategia de muestreo que puede activarse en cualquier local root span si el head-based sampling no muestrea la traza. Por lo general, este método no garantiza una traza completa.

Estrategias y marcas de muestreo

Para ayudarle a capturar datos de traza más valiosos, ARMS proporciona varias estrategias de muestreo, incluidas dos estrategias de head-based sampling y tres estrategias de non-head-based sampling.

• Estrategias de head-based sampling

  • fixed-rate sampling

  • adaptive sampling

• Estrategias de non-head-based sampling

  • minimum sampling for all interfaces

  • sampling for failed or slow requests

  • custom sampling

Marcas de muestreo

Cuando utiliza EagleEye protocol para propagar un contexto de traza entre procesos, ARMS registra si la traza se muestreó. La clave del encabezado de solicitud es EagleEye-Sampled y su valor puede ser:

• s0: No muestreado

• s1: Muestreado

En el local root span donde se muestrea una traza, el motivo de muestreo se registra como un atributo de span con la clave sample.reason. Los valores posibles son:

• s2: muestreo mínimo para todas las interfaces

• s3: muestreo personalizado

• s4: muestreo de tasa fija

• s5: Reservado

• s6: muestreo adaptativo

• s7: Reservado

• s8: muestreo de Basic Edition

• s9: muestreo de solicitudes con errores

• s10: muestreo de solicitudes lentas

• s11: muestreo de llamadas anómalas

• s12: muestreo de trazas de negocio

Estrategias de head-based sampling

ARMS ofrece dos estrategias de head-based sampling: el muestreo de tasa fija, que es el enfoque más común en el rastreo distribuido, y el muestreo adaptativo, una alternativa rentable desarrollada por ARMS.

Estrategias de non-head-based sampling

Las estrategias de head-based sampling no pueden garantizar la captura de spans con características específicas que suelen ser de gran interés, como spans con errores, alta latencia o excepciones, así como spans de interfaces con muy poco tráfico o definidas personalizadas. La contrapartida es que, dado que estas estrategias toman decisiones de muestreo en cualquier punto de una traza, no pueden garantizar la integridad de la traza.

Muestreo mínimo para todas las interfaces

No se requiere configuración. Esta estrategia asegura automáticamente que se muestree como mínimo una traza por cada interfaz por minuto. Los spans muestreados de esta manera se marcan con el atributo sample.reason y el valor s2.

Muestreo para solicitudes con errores o lentas

Una traza se muestrea si una llamada de interfaz cumple alguna de las siguientes condiciones:

• Error de interfaz: Para interfaces basadas en HTTP, el código de respuesta no es 200. Para otros tipos de interfaces, el método instrumentado lanza una excepción.

• Excepción de ejecución interna: Ocurre una excepción durante la ejecución interna de una llamada de interfaz, pero no se propaga a la instrumentación del punto de entrada del framework.

• Alta latencia: La duración de la llamada de una interfaz supera el slow-call threshold de la interfaz configurado en la página Custom Configurations.

  Nota

  Si también están habilitadas las estadísticas de cuantiles, la regla de muestreo de solicitudes lentas también se activa si la duración de la llamada supera la latencia P99 para esa interfaz.

Los spans muestreados por estos motivos se marcan con el atributo sample.reason, que se establece en s9 (error de interfaz), s11 (excepción interna) o s10 (alta latencia), respectivamente.

Muestreo personalizado

Si otras estrategias de muestreo no capturan todas las trazas que necesita, puede utilizar el muestreo personalizado para asegurar que ciertas interfaces siempre se muestreen (tasa de muestreo del 100 %). Puede definir interfaces por su nombre exacto, un prefijo o un sufijo. Un span muestreado por esta estrategia lleva un atributo con la clave sample.reason y el valor s3.

Para configurar el muestreo personalizado:

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

2. En la parte superior de la página Application List, seleccione la región de destino y luego haga clic en la aplicación objetivo.

   Nota

   Los iconos en la columna Language tienen los siguientes significados:

   : Una aplicación Java conectada a Application Monitoring.

   : Una aplicación Go monitoreada por Application Monitoring.

   : Una aplicación Python monitoreada por Application Monitoring.

   -: Una aplicación integrada con Managed Service for OpenTelemetry.

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

4. En la sección Sampling Settings, especifique las interfaces, prefijos de interfaz y sufijos de interfaz que desea muestrear completamente.

   Nota

   Los cambios surten efecto inmediatamente sin necesidad de reiniciar la aplicación.

5. Haga clic en Save.

Funcionamiento

Considere una ruta de traza A > B > C. La decisión final de reportar spans para una llamada de negocio se determina mediante una combinación de las estrategias de muestreo. El proceso de decisión, que se muestra en el siguiente diagrama de flujo, se ejecuta cada vez que una solicitud llega a A, B y C. Sin embargo, algunos pasos se omiten dependiendo de si el span actual es un root span o un local root span.

Los colores en el diagrama de flujo tienen los siguientes significados:

• Morado: Head-based sampling estándar. Se activa únicamente en el root span de la traza. En el ejemplo A > B > C, esta estrategia se activa solo en A.

• Azul: Esta estrategia puede activarse en cualquier nodo de la traza si no se activa el head-based sampling. Por ejemplo, si A decide no muestrear una solicitud, B reevalúa si debe muestrearla basándose en sus propias estrategias de muestreo personalizado y muestreo mínimo para todas las interfaces. Si B decide muestrear, propaga la marca de muestreo a C. Esta estrategia puede activarse en A, B y C.

• Verde: Esta estrategia puede activarse en cualquier nodo si la decisión de muestreo actual es "no muestrear", pero no afecta la decisión de muestreo para los servicios posteriores. Por ejemplo, si A decide no muestrear una solicitud, B aún podría decidir muestrearla basándose en la estrategia de muestreo para solicitudes con errores o lentas. En este caso, B no propaga la marca de muestreo a C. Esta estrategia puede activarse en A, B y C.

Documentos relacionados

Una vez recopiladas las trazas, puede analizar los datos almacenados en tiempo real combinando diversas condiciones de filtro y dimensiones de agregación. Para obtener más información, consulte trace analysis.