# 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. **Topics** + [Compatibilidad con Java](#CloudWatch-Application-Signals-supportmatrix-java) + [Compatibilidad con .NET](#CloudWatch-Application-Signals-supportmatrix-dotnet) + [Compatibilidad con PHP](#php-compatibility) + [Compatibilidad con Ruby](#ruby-compatibility) + [Compatibilidad con Python](#CloudWatch-Application-Signals-supportmatrix-python) + [Compatibilidad con Node.js](#CloudWatch-Application-Signals-supportmatrix-node) + [Compatibilidad con GoLang](#golang-compatibility) + [Matriz de compatibilidad con versiones del tiempo de ejecución](#rumtime-version-matix) + [Problemas conocidos](#AppSignals-Issues) ## 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](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md). ## 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](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/internal/instrumentation-libraries.md). 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. **nota** El SDK de AWS Distro para Open Telemetry (ADOT) para .NET no es compatible con el AWS SDK para .NET V4. Utilice el AWS SDK .NET V3 para obtener una compatibilidad total con Application Signals. ## 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](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) 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](https://opentelemetry.io/docs/zero-code/php/). 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](https://packagist.org/search/?query=open-telemetry%3Dinstrumentation). ## 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](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) 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](https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation). Para ver una lista de las bibliotecas de instrumentación publicadas, consulte [Registry](https://opentelemetry.io/ecosystem/registry/?language=rubycomponent=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](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation/README.md). 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 entorno `PYTHONPATH` 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](https://github.com/open-telemetry/opentelemetry-operator/issues/2302). + Para las aplicaciones de Django, se requieren configuraciones adicionales, que se describen en la [documentación de Python de OpenTelemetry](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html). + 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. ## 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](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main). ### 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](https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/doc/esm-support.md) 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](https://nodejs.org/api/esm.html#enabling) 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: + 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](CloudWatch-Application-Signals-Enable-EKS.md#EKS-NodeJs-ESM) + **Amazon ECS con estrategia sidecar** – [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Sidecar.md#ECS-NodeJs-ESM) + **Amazon ECS con estrategia daemon** – [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Daemon.md#ECSDaemon-NodeJs-ESM) + **Amazon ECS con AWS CDK** + **Amazon EC2** – [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-Enable-EC2Main.md#EC2-NodeJs-ESM) + **Kubernetes** – [Configuración de una aplicación Node.js con el formato de módulo ESM](CloudWatch-Application-Signals-Enable-KubernetesMain.md#Kubernetes-NodeJs-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](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) 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](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/getting-started.md). ### 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: 1. Instale la dependencia requerida: ``` go get go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws ``` 1. Añada la línea siguiente a la aplicación: ``` otelaws.AppendMiddlewares(&cfg.APIOptions) ``` 1. 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](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/configuration.md). #### Instrumentación de llamadas HTTP Las llamadas HTTP pueden dividir los seguimientos 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 de `Query` + Use `ExecContext` en lugar de `Exec` 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.