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.
Temas
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
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
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.
En algunas aplicaciones en contenedores, la falta de una variable de entorno
PYTHONPATH
a veces puede provocar que la aplicación no se inicie. Para solucionar este problema, asegúrese de configurar la variable de entornoPYTHONPATH
en la ubicación del directorio de trabajo de la aplicación. Esto se debe a un problema conocido con la instrumentación automática de OpenTelemetry. Para obtener más información sobre este problema, consulte Python autoinstrumentation setting of PYTHONPATH is not compliant. 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 archivosettings.py
de su aplicación Django. Esto garantiza que OpenTelemetry pueda acceder correctamente a la configuración de Django e integrarse correctamente con ella.
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
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
AWS Distro para OpenTelemetry Node.js ofrece compatibilidad limitada con ESM, basada en la compatibilidad experimental de OpenTelemetry JavaScript con ESM. Esto significa que:
La versión de Node.js debe ser 18.19.0 o posterior.
La aplicación Node.js que desea instrumentar debe incluir
@aws/aws-distro-opentelemetry-node-autoinstrumentation
y@opentelemetry/instrumentation
como dependencias.La aplicación Node.js que desea instrumentar debe comenzar con la siguiente opción de nodo:
NODE_OPTIONS=' --import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs'
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:
Amazon EKS: Configuración de una aplicación Node.js con el formato de módulo ESM
Amazon ECS con estrategia sidecar: Setting up a Node.js application with the ESM module format
Amazon ECS con estrategia daemon: Setting up a Node.js application with the ESM module format
Amazon ECS con AWS CDK
Amazon EC2: Setting up a Node.js application with the ESM module format
Kubernetes: Configuración de una aplicación Node.js con el formato de módulo ESM
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:
-
Instale la dependencia requerida:
go get go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws
-
Añada la línea siguiente a la aplicación:
otelaws.AppendMiddlewares(&cfg.APIOptions)
-
Cree los clientes de AWS subsiguientes con el objeto
aws.Config
anterior:s3Client := s3.NewFromConfig(cfg)
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:
-
Use
QueryContext
en lugar deQuery
-
Use
ExecContext
en lugar deExec
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 }
nota
Actualmente, el atributo db.system
no es compatible con las llamadas SQL. Esta limitación afecta a la capacidad de CloudWatch de identificar con precisión los clientes de bases de datos. Como consecuencia, las dependencias mostrarán UnknownRemoteService en lugar del nombre del cliente de base de datos que hace la consulta.
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
Idioma | Versión de runtime |
---|---|
Java |
JVM, versiones 8, 11, 17, 21 y 23 |
Python |
Las versiones 3.9 y posteriores de Python se admiten |
.NET |
La versión 1.6.0 y anteriores admiten .NET 6 y 8, y .NET Framework 4.6.2 y versiones posteriores La versión 1.7.0 y posteriores admiten .NET 8 y 9, y .NET Framework 4.6.2 y versiones posteriores |
Node.js |
Node.js, versiones 14, 16, 18, 20 y 22 |
PHP |
PHP, versión 8.0 y posteriores |
Ruby |
CRuby >= 3.1, JRuby >= 9.3.2.0 o TruffleRuby >= 22.1 |
GoLang |
GoLang, versión 1.18 y posteriores |
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.