Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Systèmes pris en charge
La vigie applicative est prise en charge et testé sur Amazon EKS, Kubernetes natif, Amazon ECS et Amazon EC2. Les instructions d'activation des signaux d'application sur Amazon EC2 doivent fonctionner sur toutes les plateformes prenant en charge l' CloudWatch agent et AWS la distribution pour. OpenTelemetry
**Topics**
+ [Java compatibility](#CloudWatch-Application-Signals-supportmatrix-java)
+ [Compatibilité .NET](#CloudWatch-Application-Signals-supportmatrix-dotnet)
+ [Compatibilité PHP](#php-compatibility)
+ [Compatibilité Ruby](#ruby-compatibility)
+ [Compatibilité Python](#CloudWatch-Application-Signals-supportmatrix-python)
+ [Compatibilité Node.js](#CloudWatch-Application-Signals-supportmatrix-node)
+ [GoLang compatibilité](#golang-compatibility)
+ [Matrice de prise en charge des versions d’exécution](#rumtime-version-matix)
+ [Problèmes connus](#AppSignals-Issues)
## Java compatibility
Application Signals prend en charge les applications Java et prend en charge les mêmes bibliothèques et frameworks Java que AWS Distro for OpenTelemetry . Pour plus d'informations, consultez [Bibliothèques, frameworks, serveurs d'applications et JVMs](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md).
## Compatibilité .NET
Application Signals prend en charge les mêmes bibliothèques et frameworks .NET que AWS Distro for OpenTelemetry . Pour plus d’informations, consultez la section [Instrumentations prises en charge](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/internal/instrumentation-libraries.md).
Application Signals prend en charge les applications .NET exécutées sur x86-64 ou ARM64 CPUs, et prend en charge Linux x64, Linux ARM64 et Microsoft Windows Server 2022 x64.
**Note**
Le SDK ADOT ( AWS Distro for Open Telemetry) pour .NET ne prend pas en charge le SDK pour .NET V4. AWS Utilisez le AWS SDK .NET V3 pour une prise en charge complète des signaux d'application.
## Compatibilité PHP
Application Signals prend en charge les applications PHP dotées d'une instrumentation OpenTelemetry Zero Code. Aucun SDK ADOT ( AWS Distro for Open Telemetry) n'est disponible à cette fin. Vous devez utiliser le SDK OpenTelemetry d'instrumentation standard avec la [recherche de transactions](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) activée. Pour commencer à utiliser l'instrumentation zéro code en PHP, suivez les étapes décrites dans la documentation OpenTelemetry PHP Instrumentation, [instrumentation code zéro PHP](https://opentelemetry.io/docs/zero-code/php/). L’instrumentation automatique est disponible pour un certain nombre de bibliothèques PHP couramment utilisées. Pour plus d'informations, consultez le [OpenTelemetry registre](https://packagist.org/search/?query=open-telemetry%3Dinstrumentation).
## Compatibilité Ruby
Application Signals prend en charge les applications Ruby dotées d'une instrumentation OpenTelemetry Zero Code. Aucun SDK ADOT ( AWS Distro for Open Telemetry) n'est disponible à cette fin. Vous devez utiliser le SDK OpenTelemetry d'instrumentation standard avec la [recherche de transactions](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) activée. Pour commencer à utiliser l'instrumentation zéro code dans Ruby, suivez les étapes décrites dans la documentation OpenTelemetry Ruby Instrumentation, [Ruby zero-code instrumentation](https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation). Pour obtenir la liste des bibliothèques d’instrumentation publiées, consultez [Registre](https://opentelemetry.io/ecosystem/registry/?language=rubycomponent=instrumentation).
## Compatibilité Python
Application Signals prend en charge les mêmes bibliothèques et frameworks que AWS Distro for OpenTelemetry . Pour plus d'informations, consultez la section **Packages pris en charge** à l'adresse [ opentelemetry-python-contrib](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation/README.md).
Avant d’activer la vigie applicative pour vos applications Python, tenez compte des considérations suivantes.
+ Dans certaines applications conteneurisées, l’absence de la variable d’environnement `PYTHONPATH` peut empêcher l’application de démarrer. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Cela est dû à un problème connu lié à l' OpenTelemetry auto-instrumentation. Pour plus d’informations sur ce problème, consultez la section [Le paramètre d’instrumentation automatique Python pour PYTHONPATH n’est pas conforme](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
+ Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la [documentation OpenTelemetry Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html).
+ Utilisez le paramètre `--noreload` pour empêcher le rechargement automatique.
+ Définissez la variable d’environnement `DJANGO_SETTINGS_MODULE` sur l’emplacement du fichier `settings.py` de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.
## Compatibilité Node.js
Application Signals prend en charge les mêmes bibliothèques et frameworks Node.js que AWS Distro for OpenTelemetry . Pour plus d’informations, consultez la section [Instrumentations prises en charge](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main).
### Limitations connues concernant Node.js avec ESM
La AWS distribution pour Opentelemetry Node.js prend en charge deux systèmes de ECMAScript modules : Modules (ESM) et CommonJS (CJS). Pour activer les signaux d'application, nous vous recommandons d'utiliser le format du module CJS car OpenTelemetry JavaScript le support d'ESM est expérimental et en cours de développement. Pour plus de détails, voir [ ECMAScript Modules vs CommonJS](https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/doc/esm-support.md) on GitHub.
Pour déterminer si votre application utilise CJS et non ESM, assurez-vous qu’elle ne remplit pas les conditions requises pour activer ESM. Pour plus d’informations sur ces conditions, consultez [Activation](https://nodejs.org/api/esm.html#enabling) dans la documentation Node.js.
The AWS Distro for Opentelemetry Node.js fournit un support limité pour ESM sur la base OpenTelemetry JavaScript du support expérimental pour ESM. Cela signifie que :
+ La version Node.js doit être 18.19.0 ou ultérieure.
+ L’application Node.js que vous voulez instrumenter doit inclure `@aws/aws-distro-opentelemetry-node-autoinstrumentation` et `@opentelemetry/instrumentation` en tant que dépendances.
+ L’application Node.js que vous voulez instrumenter doit démarrer avec l’option du nœud suivante :
```
NODE_OPTIONS=' --import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs'
```
Pour activer la vigie applicative avec le format de module ESM Node.js, nous proposons différentes configurations pour différentes plateformes :
+ **Amazon EKS** : [Configuration d’une application Node.js utilisant le format de module ESM](CloudWatch-Application-Signals-Enable-EKS.md#EKS-NodeJs-ESM)
+ **Amazon ECS avec stratégie sidecar** : [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Sidecar.md#ECS-NodeJs-ESM)
+ **Amazon ECS avec stratégie daemon** : [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Daemon.md#ECSDaemon-NodeJs-ESM)
+ **Amazon ECS avec 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** : [Configuration d’une application Node.js utilisant le format de module ESM](CloudWatch-Application-Signals-Enable-KubernetesMain.md#Kubernetes-NodeJs-ESM)
## GoLang compatibilité
Application Signals prend en charge GoLang les applications dotées d'une instrumentation OpenTelemetry Zero Code. Aucun SDK ADOT ( AWS Distro for Open Telemetry) n'est disponible à cette fin. Vous devez utiliser le SDK OpenTelemetry d'instrumentation standard avec la [recherche de transactions](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) activée. Pour commencer à utiliser une instrumentation zéro code dans GoLang, suivez les étapes décrites dans la documentation d' OpenTelemetry GoLang instrumentation, [Getting Started with OpenTelemetry Go Automatic Instrumentation](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/getting-started.md).
### Considérations relatives à la mise GoLang en
Découvrez les détails importants relatifs à la mise en œuvre de l' GoLang instrumentation. Ce guide explique comment implémenter une propagation contextuelle explicite dans GoLang les applications et configurer les signaux d'application. La mise en œuvre correcte de l' GoLang instrumentation vous aide à suivre et à analyser efficacement les performances de votre application.
#### Instrumentation du SDK AWS
La bibliothèque d'auto-instrumentation Golang ne prend pas en charge l'instrumentation du AWS SDK prête à l'emploi. Vous devez utiliser l’instrumentation de la bibliothèque `otelaws` avec l’agent d’instrumentation automatique :
1. Installez la dépendance requise :
```
go get go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws
```
1. Ajoutez la ligne suivante à l’application :
```
otelaws.AppendMiddlewares(&cfg.APIOptions)
```
1. Créez les AWS clients suivants avec l'`aws.Config`objet précédent :
```
s3Client := s3.NewFromConfig(cfg)
```
L'exemple suivant générera des intervalles pour les AWS appels et s'intègre à l'instrumentation automatique.
```
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
}
```
Pour plus d’informations sur la configuration de l’exécutable d’instrumentation automatique, consultez [Méthodes de configuration](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/configuration.md).
#### Instrumentation des appels HTTP
Les appels HTTP peuvent diviser les traces lorsque le contexte n’est pas transmis entre les requêtes. Les clients HTTP doivent utiliser `NewRequestWithContext()` au lieu de `NewRequest()` pour s’assurer que le service en aval utilise le même contexte. Lorsque les deux services disposent d'agents d'instrumentation, les spans se connectent avec le même identifiant de trace pour garantir la end-to-end visibilité.
```
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()
}
```
#### Instrumentation des appels SQL
Les portées SQL peuvent être déconnectées de leur portée parent, ce qui entraîne l’interprétation des appels clients comme des portées serveur. Cela se produit lorsque les appels SQL ne reçoivent pas le contexte de leurs gestionnaires en amont. Les appels SQL standard tels que `Query` et `Exec` utilisent `context.Background()` par défaut, et non le contexte de l’appelant en amont. Remplacez les appels SQL standard par leurs équivalents sensibles au contexte :
+ Utilisez `QueryContext` au lieu de `Query`
+ Utilisez `ExecContext` au lieu de `Exec`
Ces méthodes transmettent le contexte de la requête en amont aux appels de base de données, ce qui permet de maintenir une continuité de trace appropriée.
```
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
}
```
**Note**
L’attribut `db.system` n’est actuellement pas pris en charge pour les appels SQL. Cette limitation affecte la CloudWatch capacité à identifier avec précision les clients de base de données. Par conséquent, les dépendances s'afficheront à la **UnknownRemoteService**place du nom du client de base de données effectuant la requête.
#### Détecteurs de ressources
L’instrumentation automatique Go ne prend actuellement pas en charge la configuration des détecteurs de ressources lors de l’exécution. La OpenTelemetry communauté travaille sur une fonctionnalité permettant de configurer les détecteurs de ressources à l'aide de variables d'environnement. Cette fonctionnalité sera disponible dans une prochaine mise à jour. Dans l'intervalle, vous pouvez utiliser l' CloudWatch agent avec une instrumentation automatique pour générer automatiquement les attributs des ressources de l'hôte.
## Matrice de prise en charge des versions d’exécution
| Language | Version d'environnement d'exécution |
| --- | --- |
| Java | Versions JVM 8, 11, 17, 21 et 23 |
| Python | Les versions Python 3.9 et supérieures sont prises en charge |
| .NET | La version 1.6.0 et les versions antérieures prennent en charge .NET 6, 8 et .NET Framework 4.6.2 et supérieures
La version 1.7.0 et les versions supérieures prennent en charge .NET 8, 9 et .NET Framework 4.6.2 et supérieures |
| Node.js | Versions Node.js 14, 16, 18, 20 et 22 |
| PHP | Versions PHP 8.0 et supérieures |
| Ruby | CRuby >= 3,1, JRuby >= 9.3.2.0, ou >= 22,1 TruffleRuby |
| GoLang | Versions Golang 1.18 et supérieures |
## Problèmes connus
La collecte de métriques d'exécution dans la version v1.32.5 du SDK Java est connue pour ne pas fonctionner avec les applications utilisant Wildfly. JBoss Ce problème s'étend au module complémentaire Amazon CloudWatch Observability EKS, affectant les `2.3.0-eksbuild.1` versions `2.6.0-eksbuild.1` suivantes. Le problème est résolu dans la version du SDK Java `v1.32.6` et dans la version complémentaire Amazon CloudWatch Observability EKS. `v3.0.0-eksbuild.1`
Si vous êtes concerné, mettez à niveau la version du kit SDK Java ou désactivez la collecte des métriques d’exécution en ajoutant la variable d’environnement `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` à votre application.