Sistemas compatibles

Application Signals es compatible y está probado en Amazon EKS, Kubernetes nativo, Amazon ECS y Amazon EC2. Las instrucciones para activar Application Signals en Amazon EC2 deberían funcionar en cualquier plataforma que admita el agente de CloudWatch y AWS Distro para OpenTelemetry.

Compatibilidad con Java

Application Signals admite aplicaciones de Java, así como las mismas bibliotecas y marcos de Java que AWS Distro para OpenTelemetry. Para obtener más información, consulte Bibliotecas, marcos, servidores de aplicaciones y máquinas virtuales compatibles.

Compatibilidad con .NET

Application Signals admite las mismas bibliotecas y marcos de .NET que AWS Distro para OpenTelemetry. Para obtener más información, consulte Supported instrumentations.

Application Signals admite aplicaciones .NET que se ejecutan en CPU x86-64 o ARM64 y es compatible con Linux x64, Linux ARM64 y Microsoft Windows Server 2022 x64.

Compatibilidad con PHP

Application Signals admite aplicaciones de PHP con instrumentación sin código de OpenTelemetry. No hay un SDK de AWS Distro para OpenTelemetry (ADOT) disponible para este propósito. Debe usar el SDK de instrumentación de OpenTelemetry estándar con Búsqueda de transacciones habilitada. Para empezar a usar la instrumentación sin código en PHP, siga estos pasos de la documentación de instrumentación de PHP de OpenTelemetry, PHP zero-code instrumentation. La instrumentación automática está disponible para varias bibliotecas PHP de uso común. Para obtener más información, consulte el registro de OpenTelemetry.

Compatibilidad con Ruby

Application Signals admite aplicaciones de Ruby con instrumentación sin código de OpenTelemetry. No hay un SDK de AWS Distro para OpenTelemetry (ADOT) disponible para este propósito. Debe usar el SDK de instrumentación de OpenTelemetry estándar con Búsqueda de transacciones habilitada. Para empezar a usar la instrumentación sin código en Ruby, siga estos pasos de la documentación de instrumentación de Ruby de OpenTelemetry, Ruby zero-code instrumentation. Para ver una lista de las bibliotecas de instrumentación publicadas, consulte Registry.

Compatibilidad con Python

Application Signals admite las mismas bibliotecas y marcos que AWS Distro para OpenTelemetry. Para obtener más información, consulte Supported packages en opentelemetry-python-contrib.

Antes de activar las señales de aplicación para sus aplicaciones Python, debe tener en cuenta las consideraciones siguientes.

Compatibilidad con Node.js

Application Signals admite las mismas bibliotecas de Node.js y marcos que AWS Distro para OpenTelemetry. Para obtener más información, consulte Supported instrumentations.

Limitaciones conocidas de Node.js con ESM

AWS Distro para OpenTelemetry Node.js es compatible con dos sistemas de módulos: ECMAScript Modules (ESM) y CommonJS (CJS). Para habilitar Application Signals, recomendamos usar el formato de módulo CJS, ya que la compatibilidad de OpenTelemetry JavaScript con ESM es experimental y está en proceso. Para obtener más información, consulte ECMAScript Modules vs. CommonJS en GitHub.

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. Para obtener más información sobre estas condiciones, consulte Habilitar en la documentación de Node.js.

AWS Distro para OpenTelemetry Node.js ofrece compatibilidad limitada con ESM, basada en la compatibilidad experimental de OpenTelemetry JavaScript con ESM. Esto significa que:

A continuación se puede acceder a la configuración para habilitar Application Signals con el formato de módulo ESM de Node.js en diferentes plataformas:

Compatibilidad con GoLang

Application Signals admite aplicaciones de GoLang con instrumentación sin código de OpenTelemetry. No hay un SDK de AWS Distro para OpenTelemetry (ADOT) disponible para este propósito. Debe usar el SDK de instrumentación de OpenTelemetry estándar con Búsqueda de transacciones habilitada. Para empezar a utilizar la instrumentación sin código en GoLang, siga estos pasos de la documentación de instrumentación de GoLang de OpenTelemetry, Getting Started with OpenTelemetry Go Automatic Instrumentation.

Consideraciones de implementación para la instrumentación de GoLang

Obtenga información sobre los detalles de implementación importantes para usar la instrumentación de GoLang. En esta guía se explica cómo implementar la propagación explícita del contexto en las aplicaciones de GoLang y cómo configurar Application Signals. La implementación adecuada de la instrumentación de GoLang le ayuda a rastrear y analizar el rendimiento de su aplicación de manera eficaz.

Instrumentación del SDK de AWS

La biblioteca de instrumentación automática de GoLang no admite la instrumentación del SDK de AWS lista para usar. Debe utilizar la instrumentación de la otelaws biblioteca junto con el agente de instrumentación automática:

El siguiente ejemplo generará intervalos para las llamadas de AWS y se integrará en la instrumentación automática.

func handleRequest(ctx context.Context) error {
    cfg, err := config.LoadDefaultConfig(ctx)
    if err != nil {
        return err
    }
    
    // Add OpenTelemetry instrumentation middleware to the AWS config
    otelaws.AppendMiddlewares(&cfg.APIOptions)
    
    // Create S3 client with the instrumented config
    s3Client := s3.NewFromConfig(cfg)
    
    // Now any operations with this client will be traced
    // with the context from the upstream call
    _, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
    return err
}

Para obtener información sobre la configuración del ejecutable de instrumentación automática, consulte Configuration methods.

Instrumentación de llamadas HTTP

Las llamadas HTTP pueden dividir los rastreos cuando el contexto no se pasa entre solicitudes; los clientes HTTP deben usar NewRequestWithContext() en lugar de NewRequest() para garantizar que el servicio descendente utilice el mismo contexto. Cuando ambos servicios tienen agentes de instrumentación, los intervalos se conectan con el mismo identificador de rastreo para ofrecer una visibilidad integral.

func makeDownstreamCall(ctx context.Context, url string) ([]byte, error) {
    client := &http.Client{}
    
    // Create request with context from the upstream call
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    
    // Execute the request
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
}

Instrumentación de llamadas SQL

Los intervalos de SQL pueden desconectarse de su intervalo principal, lo que hace que las llamadas de los clientes se deduzcan como intervalos de servidor. Esto ocurre cuando las llamadas SQL no reciben el contexto de sus controladores ascendentes. Las llamadas SQL estándar, como Query y Exec, usan context.Background() de forma predeterminada, no el contexto de la llamada ascendente. Reemplace las llamadas SQL estándar por sus equivalentes sensibles al contexto:

Estos métodos pasan el contexto de la solicitud ascendente a las llamadas de la base de datos, lo que mantiene una continuidad de rastreo adecuada.

func queryDatabase(ctx context.Context, db *sql.DB, userID string) (*sql.Rows, error) {
    // This breaks the trace context
    // row := db.Query("SELECT name FROM users WHERE id = $1", userID)
    
    // This passes the context from the upstream call for trace continuity
    rows, err := db.QueryContext(ctx, "SELECT name FROM users WHERE id = $1", userID)
    
    return rows, error
}

Detectores de recursos

Actualmente, la instrumentación automática de Go no admite la configuración de detectores de recursos en tiempo de ejecución. La comunidad de OpenTelemetry está trabajando en una característica para configurar los detectores de recursos mediante variables de entorno. Busque esta característica en una actualización futura. Mientras tanto, puede utilizar el agente de CloudWatch con instrumentación automática para generar automáticamente los atributos de los recursos del host.

Matriz de compatibilidad con versiones del tiempo de ejecución

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.6.0-eksbuild.1. El problema ya está solucionado en la versión v1.32.6 del SDK de Java y en la versión v3.0.0-eksbuild.1 del complemento de observabilidad de EKS de Amazon CloudWatch.

Si se ve afectado, cambie a una versión posterior de SDK de Java o desactive la colección de métricas de tiempo de ejecución agregando la variable de entorno OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false a la aplicación.