Configuración de Application Signals

Esta sección contiene información sobre la configuración de CloudWatch Application Signals.

Frecuencia de muestreo de trazas

De forma predeterminada, al activar Application Signals, el muestreo centralizado de X-Ray se habilita con los ajustes de frecuencia de muestreo predeterminados de reservoir=1/s y fixed_rate=5%. Las variables de entorno del agente SDK de AWS Distro para OpenTelemetry (ADOT) se configuran de la siguiente manera.

Para obtener información sobre cómo cambiar la configuración de muestreo, consulte lo siguiente:

Si desea deshabilitar el muestreo centralizado de X-Ray y utilizar el muestreo local en su lugar, defina los siguientes valores para el agente Java del SDK de ADOT como se indica a continuación. El siguiente ejemplo establece la frecuencia de muestreo en un 5 %.

Para obtener información sobre ajustes de muestreo más avanzados, consulte OTEL_TRACES_SAMPLER.

Habilitación de la correlación entre seguimientos y registros

Puede habilitar la correlación entre seguimientos y registros en Application Signals. Esto introduce automáticamente los ID de seguimiento y los ID de intervalo en los registros de aplicación pertinentes. A continuación, al abrir una página de detalles del seguimiento en la consola de Application Signals, las entradas de registro pertinentes (si las hay) que se correlacionan con el seguimiento actual aparecen automáticamente en la parte inferior de la página.

Por ejemplo, supongamos que observa un pico en un gráfico de latencia. Puede elegir el punto del gráfico para cargar la información de diagnóstico correspondiente a ese punto en el tiempo. A continuación, selecciona el seguimiento correspondiente para obtener más información. Al ver la información del seguimiento, puede desplazarse hacia abajo para ver los registros asociados a él. Estos registros pueden revelar patrones o códigos de error asociados a los problemas que provocan el pico de latencia.

Para lograr la correlación del registro de trazas, Application Signals se basa en lo siguiente:

Todos estos instrumentos están disponibles en la comunidad de OpenTelemetry. Application Signals los utiliza para inyectar contextos de seguimientos, como el ID de seguimiento y el ID de intervalo, en los registros de la aplicación. Para habilitar esto, debe cambiar manualmente la configuración de registro para habilitar la autoinstrumentación.

Según la arquitectura en la que se ejecute la aplicación, es posible que también deba configurar una variable de entorno para habilitar la correlación de registros de seguimiento, además de seguir los pasos de esta sección.

Una vez que habilite la correlación de los registros de seguimientos,

Ejemplos de configuración de la correlación del registro de seguimientos

Esta sección contiene ejemplos de cómo configurar la correlación del registro de seguimientos en varios entornos.

Spring Boot para Java

Supongamos que tiene una aplicación Spring Boot en una carpeta llamada custom-app. La configuración de la aplicación suele ser un archivo YAML con el nombre custom-app/src/main/resources/application.yml y que podría tener este aspecto:

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...   

Para habilitar la correlación del registro de seguimientos, agregue la siguiente configuración de registro.

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...    

logging:
  pattern:
    level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p

Logback para Java

En la configuración de registro (como logback.xml), inserte el contexto de seguimiento trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p en pattern del codificador. Por ejemplo, la siguiente configuración antepone el contexto de seguimiento al mensaje de registro.

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
  <file>app.log</file>
  <append>true</append>
  <encoder> 
    <pattern>trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n</pattern> 
  </encoder>
</appender>

Para obtener más información sobre los codificadores de Logback, consulte Encoders en la documentación de Logback.

Log4j2 para Java

En la configuración de registro (por ejemplo, log4j2.xml), inserte el contexto de seguimiento trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p en PatternLayout. Por ejemplo, la siguiente configuración antepone el contexto de seguimiento al mensaje de registro.

<Appenders>
  <File name="FILE" fileName="app.log">
    <PatternLayout pattern="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>
  </File>
</Appenders>

Para obtener más información sobre los diseños de patrones en Log4j2, consulte Pattern Layout en la documentación de Log4j2.

Log4j para Java

En la configuración de registro (como log4j.xml), inserte el contexto de seguimiento trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p en PatternLayout. Por ejemplo, la siguiente configuración antepone el contexto de seguimiento al mensaje de registro.

<appender name="FILE" class="org.apache.log4j.FileAppender">;
  <param name="File" value="app.log"/>;
  <param name="Append" value="true"/>;
  <layout class="org.apache.log4j.PatternLayout">;
    <param name="ConversionPattern" value="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>;
  </layout>;
</appender>;

Para obtener más información sobre los diseños de patrones en Log4j, consulte Class Pattern Layout en la documentación de Log4j.

Python

Establezca la variable de entorno de OTEL_PYTHON_LOG_CORRELATION en true mientras se ejecuta la aplicación. Para obtener más información, consulte Enable trace context injection en la documentación de OpenTelemetry de Python.

Node.js

Para obtener más información sobre cómo habilitar la inyección de contexto de rastreo en Node.js para las bibliotecas de registro que la admiten, consulte la documentación de uso de NPM de las instrumentaciones automáticas de Pino, Winston o Bunyan para Node.js.

Habilitación de la correlación entre métricas y registros

Si publica registros de aplicaciones en grupos de registro de Registros de CloudWatch, puede habilitar la correlación entre métricas y registros de aplicación en Application Signals. Con la correlación entre métricas y registros, la consola de Application Signals muestra automáticamente los grupos de registro correspondientes asociados a una métrica.

Por ejemplo, supongamos que observa un pico en un gráfico de latencia. Puede elegir un punto del gráfico para cargar la información de diagnóstico correspondiente a ese punto en el tiempo. La información de diagnóstico mostrará los grupos de registro de aplicación correspondientes que estén asociados al servicio y la métrica actuales. Después, puede seleccionar un botón para ejecutar una consulta de Información de registros de CloudWatch en esos grupos de registro. Dependiendo de la información contenida en los registros de aplicación, esto puede servir de ayuda para investigar la causa del pico de latencia.

En función de la arquitectura en la que se ejecute la aplicación, es posible que también deba configurar una variable de entorno para habilitar la correlación entre métricas y registros de aplicación.

Administración de operaciones de alta cardinalidad

Application Signals incluye configuraciones en el agente de CloudWatch que puede usar para administrar la cardinalidad de sus operaciones y administrar la exportación de métricas para optimizar los costes. De forma predeterminada, la función de limitación de métricas se activa cuando el número de operaciones distintas de un servicio a lo largo del tiempo supera el umbral predeterminado de 500. Puede ajustar el comportamiento ajustando los ajustes de configuración.

Comprobación de si la limitación de métricas está activada

Puede utilizar uno de los métodos siguientes para comprobar si se está aplicando el límite de métricas predeterminado. Si es así, debe considerar la posibilidad de optimizar el control de cardinalidad siguiendo los pasos que se indican en la siguiente sección.

Optimización del control de cardinalidad

Para optimizar el control de cardinalidad, puede hacer lo siguiente:

Creación de reglas personalizadas para agregar operaciones

A veces, las operaciones de alta cardinalidad pueden deberse a valores únicos inapropiados extraídos del contexto. Por ejemplo, enviar solicitudes HTTP/S que incluyan ID de usuario o ID de sesión en la ruta puede provocar cientos de operaciones dispares. Para resolver estos problemas, recomendamos configurar el agente de CloudWatch con reglas de personalización para volver a escribir estas operaciones.

En los casos en los que se generen numerosas métricas diferentes a través de llamadas RemoteOperation individuales, por ejemplo PUT /api/customer/owners/123, PUT /api/customer/owners/456 y solicitudes similares, le recomendamos que consolide estas operaciones en una sola RemoteOperation. Un enfoque es estandarizar todas las llamadas RemoteOperation que comienzan con PUT /api/customer/owners/ a un formato uniforme, específicamente PUT /api/customer/owners/{ownerId}. En el siguiente ejemplo, se ilustra este caso. Para obtener información sobre otras reglas de personalización, consulte Habilitación de CloudWatch Application Signals.

{
   "logs":{
      "metrics_collected":{
         "application_signals":{
            "rules":[
               {
                  "selectors":[
                     {
                        "dimension":"RemoteOperation",
                        "match":"PUT /api/customer/owners/*"
                     }
                  ],
                  "replacements":[
                     {
                        "target_dimension":"RemoteOperation",
                        "value":"PUT /api/customer/owners/{ownerId}"
                     }
                  ],
                  "action":"replace"
               }
            ]
         }
      }
   }
}

En otros casos, es posible que las métricas de alta cardinalidad se hayan agregado a AllOtherRemoteOperations y es posible que no esté claro qué métricas específicas se incluyen. El agente de CloudWatch puede registrar las operaciones interrumpidas. Para identificar las operaciones interrumpidas, utilice la configuración del siguiente ejemplo para activar el registro hasta que el problema vuelva a surgir. A continuación, inspeccione los registros del agente de CloudWatch (a los que se puede acceder mediante un contenedor stdout o archivos de registro de EC2) y busque la palabra clave drop metric data.

{
  "agent": {
    "config": {
      "agent": {
        "debug": true
      },
      "traces": {
        "traces_collected": {
          "application_signals": {
          }
        }
      },
      "logs": {
        "metrics_collected": {
          "application_signals": {
            "limiter": {
              "log_dropped_metrics": true
            }
          }
        }
      }
    }
  }
}

Creación de su política de limitación de métricas

Si la configuración de limitación de métricas predeterminada no aborda la cardinalidad de su servicio, puede personalizar la configuración del limitador de métricas. Para configurar esta acción, agregue una sección limiter en la sección logs/metrics_collected/application_signals del archivo de configuración del agente de CloudWatch.

El siguiente ejemplo reduce el umbral del límite de métricas de 500 métricas distintas a 100.

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "limiter": {
          "drop_threshold": 100
        }
      }
    }
  }
}