Solución de problemas de instalación de Application Signals - Amazon CloudWatch
Rendimiento del arranque en frío de la capa Java de Application SignalsLa aplicación no se inicia después de activar Application SignalsLa aplicación Python no se inicia después de activar Application SignalsNo hay datos de Application Signals para la aplicación de Python que usa un servidor WSGIMi aplicación de Node.js no está instrumentada o no genera telemetría de Application SignalsNo hay datos de la aplicación en el panel de Application SignalsLas métricas de servicio o de dependencia tienen valores UnknownGestión de un conflicto de configuración al administrar el complemento de observabilidad de Amazon CloudWatch EKSDeseo filtrar las métricas y los seguimientos innecesarios¿Qué significa InternalOperation?¿Cómo se habilita el registro para aplicaciones .NET?¿Cómo se resuelven los conflictos entre versiones de ensamblado en las aplicaciones .NET?¿Puedo desactivar FluentBit?¿Se pueden filtrar los registros de contenedores antes de exportarlos a los Registros de CloudWatch? Resolver TypeError al usar la AWS Distro para OpenTelemetry (ADOT) con la capa Lambda de JavaScript Actualización a las versiones requeridas de los agentes o del complemento de Amazon EKS

Solución de problemas de instalación de Application Signals

Esta sección contiene sugerencias para solucionar los problemas de CloudWatch Application Signals.

Rendimiento del arranque en frío de la capa Java de Application Signals

Agregar la capa Application Signals a las funciones Java de Lambda aumenta la latencia de inicio (tiempo de arranque en frío). Los siguientes consejos pueden ayudar a reducir la latencia para funciones sensibles al tiempo.

Inicio rápido para el agente Java: la capa Application Signals para Java Lambda incluye una característica de Inicio rápido, que está desactivada de forma predeterminada, pero se puede habilitar al configurar la variable OTEL_JAVA_AGENT_FAST_STARTUP_ENABLED en verdadero. Cuando se habilita, esta característica configura la JVM para usar el compilador de nivel 1 C1 de compilación en varias etapas, con el fin de generar código nativo optimizado rápidamente para un inicio en frío más rápido. El compilador C1 prioriza la velocidad a costa de la optimización a largo plazo, mientras que el compilador C2 ofrece un rendimiento general superior al perfilar datos a lo largo del tiempo.

Para obtener más información, consulte Inicio rápido para el agente Java.

Reduzca los tiempos de inicio en frío con simultaneidad aprovisionada: la simultaneidad aprovisionada de AWS Lambda preasigna una cantidad específica de instancias de función, manteniéndolas inicializadas y listas para gestionar solicitudes de inmediato. Esto reduce los tiempos de inicio en frío al eliminar la necesidad de inicializar el entorno de la función durante la ejecución, con lo que se asegura un rendimiento más rápido y consistente, especialmente para cargas de trabajo sensibles a la latencia. Para obtener más información, consulte Cómo configurar la simultaneidad aprovisionada para una función.

Optimice el rendimiento de inicio mediante Lambda SnapStart: AWS Lambda SnapStart es una característica que optimiza el rendimiento de inicio de las funciones de Lambda al crear una instantánea preinicializada del entorno de ejecución después de la fase de inicialización de la función. Esta instantánea se reutiliza luego para iniciar nuevas instancias, lo que reduce significativamente los tiempos de inicio en frío al omitir el proceso de inicialización durante la invocación de la función. Para obtener información, consulte Cómo mejorar el rendimiento de inicio con Lambda SnapStart.

La aplicación no se inicia después de activar Application Signals

Si la aplicación en un clúster de Amazon EKS no se inicia después de habilitar Application Signals en el clúster, compruebe lo siguiente:

  • Compruebe si la aplicación ha sido instrumentada por otra solución de supervisión. Puede que Application Signals no sea compatible con la coexistencia con otras soluciones de instrumentación.

  • Confirme que la aplicación cumpla con los requisitos de compatibilidad para utilizar Application Signals. Para obtener más información, consulte Sistemas compatibles.

  • Si la aplicación no pudo extraer los artefactos de Application Signals, como las imágenes del agente Java o Python de AWS Distro para OpenTelemetery y del agente de CloudWatch, podría deberse a un problema de red.

Para mitigar el problema, elimine la anotación instrumentation.opentelemetry.io/inject-java: "true" o instrumentation.opentelemetry.io/inject-python: "true" del manifiesto de implementación de la aplicación y vuelva a implementarla. A continuación, compruebe si la aplicación funciona.

Problemas conocidos

Se sabe que la colección de métricas de tiempo de ejecución de la versión 1.32.5 del SDK de Java no funciona con aplicaciones que utilizan JBoss Wildfly. Este problema se extiende al complemento de observabilidad de EKS de Amazon CloudWatch y afecta a todas las versiones, de 2.3.0-eksbuild.1 a 2.5.0-eksbuild.1.

Si se ve afectado, cambie a una versión inferior o agregue la variable de entorno OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false a su aplicación para deshabilitar la recopilación de métricas de tiempo de ejecución.

La aplicación Python no se inicia después de activar Application Signals

Es un problema conocido en la instrumentación automática de OpenTelemetry que una variable de entorno PYTHONPATH faltante a veces puede provocar que la aplicación no se inicie. Para solucionar este problema, asegúrese de configurar la variable de entorno PYTHONPATH en la ubicación del directorio de trabajo de la aplicación. Para obtener más información sobre este problema, consulte Python autoinstrumentation setting of PYTHONPATH is not compliant with Python's module resolution behavior, breaking Django applications.

Para las aplicaciones de Django, se requieren configuraciones adicionales, que se describen en la documentación de Python de OpenTelemetry.

  • Use el indicador --noreload para evitar la recarga automática.

  • Establezca la variable de entorno DJANGO_SETTINGS_MODULE en la ubicación del archivo settings.py de su aplicación Django. Esto garantiza que OpenTelemetry pueda acceder correctamente a la configuración de Django e integrarse correctamente con ella.

No hay datos de Application Signals para la aplicación de Python que usa un servidor WSGI

Si está utilizando un servidor WSGI como Gunicorn o uWSGI, debe hacer cambios adicionales para que la instrumentación automática de ADOT para Python funcione.

nota

Asegúrese de utilizar la versión más reciente de ADOT para Python y el complemento de observabilidad de EKS de Amazon CloudWatch antes de continuar.

Pasos adicionales para habilitar Application Signals con un servidor WSGI

  1. Importe la instrumentación automática en los procesos de trabajo adaptados.

    Para Gunicorn, use el enlace post_fork:

    # gunicorn.conf.py
def post_fork(server, worker):
    from opentelemetry.instrumentation.auto_instrumentation import sitecustomize

    Para uWSGI, use la directiva import.

    #  uwsgi.ini
[uwsgi]
; required for the instrumentation of worker processes
enable-threads = true
lazy-apps = true
import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize

  2. Habilite la configuración de la instrumentación automática de ADOT para Python para omitir el proceso principal y dejarlo en manos de los trabajadores mediante el establecimiento de la variable de entorno OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED en true.

Mi aplicación de Node.js no está instrumentada o no genera telemetría de Application Signals

Para habilitar Application Signals para Node.js, debe asegurarse de que su aplicación de Node.js utilice el formato de módulo CommonJS (CJS). Actualmente, la distribución de Node.js de AWS Distro para OpenTelemetry no es compatible con el formato de módulo ESM, ya que la compatibilidad de OpenTelemetry JavaScript con ESM es experimental y está en proceso de desarrollo.

Para determinar si su aplicación utiliza CJS y no ESM, asegúrese de que la aplicación no cumpla las condiciones para habilitar ESM.

No hay datos de la aplicación en el panel de Application Signals

Si faltan métricas o seguimientos en los paneles de Application Signals, las causas podrían ser las siguientes. Investigue estas causas solo si ha esperado 15 minutos para que Application Signals recopile y muestre datos desde la última actualización.

  • Asegúrese de que la biblioteca y el marco que está utilizando sean compatibles con el agente Java de ADOT. Para obtener más información, consulte Bibliotecas/Marcos.

  • Asegúrese de que el agente de CloudWatch esté en ejecución. En primer lugar, compruebe el estado de los pods de agentes de CloudWatch y asegúrese de que todos estén en estado Running.

    kubectl -n amazon-cloudwatch get pods.

    Añada lo siguiente al archivo de configuración del agente de CloudWatch para habilitar los registros de depuración y, a continuación, reinicie el agente.

    "agent": {

  "region": "${REGION}",
  "debug": true
},

    A continuación, compruebe si hay errores en los pods de agentes de CloudWatch.

  • Compruebe si hay problemas de configuración con el agente de CloudWatch. Confirme que lo siguiente sigue en el archivo de configuración del agente de CloudWatch y que el agente se ha reiniciado desde que se añadió.

    "agent": {
  "region": "${REGION}",
  "debug": true
},

    A continuación, consulte los registros de depuración de OpenTelemetry para ver si hay mensajes de error como ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export .... Estos mensajes pueden indicar el problema.

    Si eso no resuelve el problema, vuelque y compruebe las variables de entorno con nombres que comiencen por OTEL_ describiendo el pod con el comando kubectl describe pod.

  • Para habilitar el registro de depuración de OpenTelemetry Python, establezca la variable de entorno OTEL_PYTHON_LOG_LEVEL en debug y vuelva a implementar la aplicación.

  • Compruebe si hay permisos incorrectos o insuficientes para exportar datos desde el agente de CloudWatch. Si ve mensajes Access Denied en los registros del agente de CloudWatch, puede que este sea el problema. Es posible que los permisos aplicados al instalar el agente de CloudWatch se hayan modificado o revocado posteriormente.

  • Compruebe si hay un problema de AWS Distro para OpenTelemetry (ADOT) al generar datos de telemetría.

    Asegúrese de que las anotaciones de la instrumentación instrumentation.opentelemetry.io/inject-java y sidecar.opentelemetry.io/inject-java se apliquen a la implementación de la aplicación y que el valor sea true. Sin ellas, los pods de aplicaciones no se instrumentarán aunque el complemento ADOT esté instalado correctamente.

    A continuación, compruebe si el contenedor init está aplicado a la aplicación y su estado Ready sea True. Si el contenedor init no está listo, consulte el estado para ver el motivo.

    Si el problema persiste, habilite el registro de depuración en el SDK de OpenTelemetry Java al configurar la variable de entorno OTEL_JAVAAGENT_DEBUG en verdadero e implementar nuevamente la aplicación. A continuación, busque los mensajes que comiencen por ERROR io.telemetry.

  • Es posible que el exportador de métricas o intervalos esté descartando datos. Para averiguarlo, consulte el registro de la aplicación para ver si hay mensajes que incluyan Failed to export...

  • Es posible que el agente de CloudWatch se esté viendo limitado al enviar métricas o intervalos a Application Signals. Compruebe si hay mensajes que indiquen una limitación en los registros del agente de CloudWatch.

  • Asegúrese de que haya habilitado la configuración de detección de servicios. Solo es necesario hacerlo una vez en la región.

    Para confirmar esto, en la consola de CloudWatch, seleccione Application Signals, Servicios. Si el Paso 1 no está marcado como Completar, seleccione Empiece a detectar los servicios. Los datos deberían empezar a fluir en cinco minutos.

Las métricas de servicio o de dependencia tienen valores Unknown

Si ve UnknownService, UnknownOperation, UnknownRemoteService, o UnknownRemoteOperation como nombres de dependencia o de operación en los paneles de Application Signals, compruebe si la aparición de los puntos de datos para el servicio remoto desconocido y la operación remota desconocida coinciden con su implementación.

  • UnknownService significa que se desconoce el nombre de una aplicación instrumentada. Si la variable de entorno OTEL_SERVICE_NAME no está definida y service.name no está especificado en OTEL_RESOURCE_ATTRIBUTES, el nombre del servicio se establece en UnknownService. Para solucionar este problema, especifique el nombre del servicio en OTEL_SERVICE_NAME o OTEL_RESOURCE_ATTRIBUTES.

  • UnknownOperation significa que se desconoce el nombre de una operación invocada. Esto ocurre cuando Application Signals no puede detectar el nombre de una operación que invoca la llamada remota o cuando el nombre de la operación extraída contiene valores de cardinalidad altos.

  • UnknownRemoteService significa que se desconoce el nombre del servicio de destino. Esto ocurre cuando el sistema no puede extraer el nombre del servicio de destino al que accede la llamada remota.

    Una solución consiste en crear un intervalo personalizado alrededor de la función que envía la solicitud y agregar el atributo aws.remote.service con el valor designado. Otra opción es configurar el agente de CloudWatch para personalizar el valor métrico de RemoteService. Para obtener más información sobre las personalizaciones en el agente de CloudWatch, consulte Habilitación de CloudWatch Application Signals.

  • UnknownRemoteOperation significa que se desconoce el nombre de la operación de destino. Esto ocurre cuando el sistema no puede extraer el nombre de la operación de destino a la que accede la llamada remota.

    Una solución consiste en crear un intervalo personalizado alrededor de la función que envía la solicitud y agregar el atributo aws.remote.operation con el valor designado. Otra opción es configurar el agente de CloudWatch para personalizar el valor métrico de RemoteOperation. Para obtener más información sobre las personalizaciones en el agente de CloudWatch, consulte Habilitación de CloudWatch Application Signals.

Gestión de un conflicto de configuración al administrar el complemento de observabilidad de Amazon CloudWatch EKS

Al instalar o actualizar el complemento de observabilidad de Amazon CloudWatch EKS, si observa un error provocado por un Health Issue del tipo ConfigurationConflict con una descripción que comienza por Conflicts found when trying to apply. Will not continue due to resolve conflicts mode, probablemente se deba a que ya tiene el agente de CloudWatch y sus componentes asociados, como ServiceAccount, ClusterRole y ClusterRoleBinding instalados en el clúster. Cuando el complemento intenta instalar el agente de CloudWatch y sus componentes asociados, si detecta algún cambio en el contenido, por defecto no se realiza la instalación o la actualización para evitar sobrescribir el estado de los recursos del clúster.

Si está intentando incorporar al complemento de observabilidad de ECS de Amazon CloudWatch y observa este error, le recomendamos que elimine la configuración de agente de CloudWatch existente que haya instalado anteriormente en el clúster y, a continuación, instale el complemento EKS. Asegúrese de hacer una copia de seguridad de las personalizaciones que haya realizado en la configuración original del agente de CloudWatch, como una configuración de agente personalizada, y envíelas al complemento de observabilidad de Amazon CloudWatch EKS la próxima vez que lo instale o actualice. Si ya había instalado el agente de CloudWatch para incorporar Información de contenedores, consulte Eliminación del agente de CloudWatch y Fluen Bit para Información de contenedores para obtener más información.

Como alternativa, el complemento admite una opción de configuración de resolución de conflictos que puede especificar OVERWRITE. Puede usar esta opción para continuar con la instalación o actualización del complemento sobrescribiendo los errores en el clúster. Si utiliza la consola de Amazon EKS, encontrará el método de resolución de errores al elegir los ajustes de configuración opcionales al crear o actualizar el complemento. Si está utilizando la AWS CLI, puede proporcionar --resolve-conflicts OVERWRITE al comando para crear o actualizar el complemento.

Deseo filtrar las métricas y los seguimientos innecesarios

Si Application Signals recopila seguimientos y métricas que no desea, consulte Administración de operaciones de alta cardinalidad para acceder a información sobre cómo configurar el agente de CloudWatch con reglas personalizadas para reducir la cardinalidad.

Para acceder a información sobre la personalización de las reglas de muestreo de seguimientos, consulte Configure sampling rules en la documentación de X-Ray.

¿Qué significa InternalOperation?

Un InternalOperation es una operación que la aplicación desencadena internamente y no mediante una invocación externa. La aparición de InternalOperation es un comportamiento esperable y positivo.

Algunos ejemplos típicos en los que se puede observar InternalOperation son los siguientes:

  • Carga previa al inicio: la aplicación realiza una operación denominada loadDatafromDB, la cual lee los metadatos de una base de datos durante la fase de calentamiento. En lugar de observar a loadDatafromDB como una operación de servicio, la verá categorizada como una InternalOperation.

  • Ejecución asíncrona en segundo plano: su aplicación se suscribe a una cola de eventos y procesa los datos de streaming en consecuencia cada vez que hay una actualización. Cada operación que se active estará en InternalOperation como una operación de servicio.

  • Recuperación de la información del host de un registro de servicios: la aplicación se comunica con un registro de servicios para la detección de servicios. Todas las interacciones con el sistema de detección se clasifican como un InternalOperation.

¿Cómo se habilita el registro para aplicaciones .NET?

Si desea habilitar el registro para aplicaciones .NET, configure las siguientes variables de entorno. Para obtener más información sobre cómo configurar estas variables de entorno, consulte Solución de problemas de instrumentación automática de .NET en la documentación de OpenTelemetry.

  • OTEL_LOG_LEVEL

  • OTEL_DOTNET_AUTO_LOG_DIRECTORY

  • COREHOST_TRACE

  • COREHOST_TRACEFILE

¿Cómo se resuelven los conflictos entre versiones de ensamblado en las aplicaciones .NET?

Si aparece el siguiente error, consulte Conflictos entre versiones de ensamblado en la documentación de OpenTelemetry para ver los pasos de resolución.

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults)
   at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
   at Program.<Main>$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26

¿Puedo desactivar FluentBit?

Puede desactivar FluentBit al configurar el complemento de observabilidad de EKS de Amazon CloudWatch. Para obtener más información, consulte Configuraciones adicionales (Opcional).

¿Se pueden filtrar los registros de contenedores antes de exportarlos a los Registros de CloudWatch?

No, el filtrado de registros de contenedores aún no es compatible.

Resolver TypeError al usar la AWS Distro para OpenTelemetry (ADOT) con la capa Lambda de JavaScript

Su función de Lambda puede fallar con este error: TypeError - "Cannot redefine property: handler" cuando:

  • Utiliza la capa Lambda de JavaScript de ADOT

  • Utiliza esbuild para compilar TypeScript

  • Exporta su controlador con la palabra clave export

La capa Lambda de JavaScript de ADOT necesita modificar su controlador en tiempo de ejecución. Cuando usa la palabra clave export con esbuild (directamente o a través de AWS CDK), esbuild hace que su controlador sea inmutable, lo que impide estas modificaciones.

Exporte la función de su controlador con module.exports, en lugar de la palabra clave export: 

// Before
export const handler = (event) => {
  // Handler Code
}
// After
const handler = async (event) => {
  // Handler Code
}
module.exports = { handler }

Actualización a las versiones requeridas de los agentes o del complemento de Amazon EKS

A partir del 9 de agosto de 2024, CloudWatch Application Signals ya no será compatible con las versiones anteriores del complemento de observabilidad de EKS de Amazon CloudWatch, el agente de CloudWatch y el agente de autoinstrumentación de AWS Distro para OpenTelemetry.

  • En el caso del complemento de observabilidad de EKS de Amazon CloudWatch, las versiones anteriores a v1.7.0-eksbuild.1 no serán compatibles.

  • En el caso del agente de CloudWatch, las versiones anteriores a 1.300040.0 no serán compatibles.

  • Para el agente de autoinstrumentación de AWS Distro para OpenTelemetry:

    • Para Java, las versiones anteriores a 1.32.2 no serán compatibles.

    • Para Python, las versiones anteriores a 0.2.0 no serán compatibles.

    • Para .NET, las versiones anteriores a 1.3.2 no serán compatibles.

    • En el caso de Node.js, las versiones anteriores a 0.3.0 no son compatibles.

importante

Las versiones más recientes de los agentes incluyen actualizaciones del esquema de métrica de Application Signals. Estas actualizaciones no son compatibles con versiones anteriores y esto puede provocar problemas de datos si se utilizan versiones incompatibles. Para garantizar una transición sin problemas a la nueva funcionalidad, haga lo siguiente:

  • Si su aplicación se ejecuta en Amazon EKS, asegúrese de reiniciar todas las aplicaciones instrumentadas después de actualizar el complemento de observabilidad de Amazon CloudWatch.

  • En el caso de las aplicaciones que se ejecutan en otras plataformas, asegúrese de actualizar ambos agentes, el de CloudWatch y el de autoinstrumentación de AWS OpenTelemetry, a las versiones más recientes.

Con las instrucciones de las siguientes secciones, pueden actualizar a una versión compatible.

Actualice el complemento de observabilidad de EKS de Amazon CloudWatch

Para el complemento de observabilidad de EKS de Amazon CloudWatch, puede utilizar la AWS Management Console o la AWS CLI.

Uso de la consola

Actualización del complemento con la consola

  1. Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

  2. Seleccione el nombre del clúster de Amazon EKS que desea actualizar.

  3. Seleccione la pestaña Complementos y, a continuación, Observabilidad de Amazon CloudWatch.

  4. Seleccione Editar, luego la versión a la que desee actualizar y, a continuación, Guardar cambios.

    Asegúrese de elegir la versión v1.7.0-eksbuild.1 o posterior.

  5. Ingrese uno de los siguientes comandos de AWS CLI para reiniciar los servicios.

      # Restart a deployment
  kubectl rollout restart deployment/name
  # Restart a daemonset
  kubectl rollout restart daemonset/name
  # Restart a statefulset
  kubectl rollout restart statefulset/name

Utilizar AWS CLI

Actualización del complemento con la AWS CLI

  1. Ingrese el siguiente comando para encontrar la versión más reciente.

    aws eks describe-addon-versions \
--addon-name amazon-cloudwatch-observability

  2. Ingrese el siguiente comando para actualizar el complemento. Sustituya $VERSION por la versión v1.7.0-eksbuild.1 o una posterior. Sustituya $AWS_REGION y $CLUSTER por su región y nombre de clúster.

    aws eks update-addon \
--region $AWS_REGION \
--cluster-name $CLUSTER \
--addon-name amazon-cloudwatch-observability \
--addon-version $VERSION \
# required only if the advanced configuration is used.
--configuration-values $JSON_CONFIG
    nota

    Si utiliza una configuración personalizada para el complemento, puede encontrar un ejemplo de la configuración que se debe usar para $JSON_CONFIG en Habilitación de CloudWatch Application Signals.

  3. Ingrese uno de los siguientes comandos de AWS CLI para reiniciar los servicios.

      # Restart a deployment
  kubectl rollout restart deployment/name
  # Restart a daemonset
  kubectl rollout restart daemonset/name
  # Restart a statefulset
  kubectl rollout restart statefulset/name

Actualización del agente de CloudWatch y el agente de ADOT

Si sus servicios se ejecutan en arquitecturas distintas de Amazon EKS, tendrá que actualizar tanto el agente CloudWatch como el agente de autoinstrumentación de ADOT para utilizar las características más recientes de Application Signals.

Actualización sobre Amazon ECS

Actualización de sus agentes para los servicios que se ejecutan en Amazon ECS

  1. Cree una revisión de definición de tarea. Para más información, consulte Updating a task definition using the console.

  2. Sustituya el $IMAGE del contenedor ecs-cwagent por la etiqueta de imagen más reciente de cloudwatch-agent en Amazon ECR.

    Si actualiza a una versión fija, asegúrese de usar la versión 1.300040.0 o una posterior.

  3. Sustituya la etiqueta $IMAGE del contenedor init por la imagen más reciente de las siguientes ubicaciones:

  4. Actualice las variables del entorno de Application Signals en el contenedor de su aplicación con las instrucciones que se encuentran en Paso 4: instrumentar la aplicación con el agente de CloudWatch.

  5. Implemente el servicio con la nueva definición de tareas.

Actualización sobre Amazon EC2 u otras arquitecturas

Actualización de los agentes para los servicios que se ejecutan en Amazon EC2 u otras arquitecturas

  1. Siga las instrucciones en Descargue del paquete de del agente de CloudWatch y actualice el agente de CloudWatch a la versión más reciente. Asegúrese de seleccionar la versión 1.300040.0 o una posterior.

  2. Descargue la última versión del agente de autoinstrumentación de AWS Distro para OpenTelemetry desde una de las siguientes ubicaciones:

  3. Aplique las variables de entorno de Application Signals actualizadas a su aplicación y, a continuación, iníciela. Para obtener más información, consulte Paso 3: instrumentar la aplicación e iníciela.