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. # Résolution des problèmes liés à l’installation d’Application Signals Cette section contient des conseils de résolution des problèmes relatifs aux signaux CloudWatch d'application. **Topics** + [ ## Résoudre les conflits OpenTelemetry de configuration dans Amazon EKS avec les signaux d'application ](#Application-Signals-troubleshoot-eks-applications) + [ ## Performances de démarrage à froid de la couche Java de la vigie applicative ](#Application-Signals-troubleshoot-cold-start-performance) + [ ## L’application ne démarre pas après l’activation d’Application Signals ](#Application-Signals-troubleshoot-starting) + [ ## L’application Python ne démarre pas après l’activation de la vigie applicative ](#Application-Signals-troubleshoot-starting-Python) + [ ## Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI ](#Application-Signals-troubleshoot-Python-WSGI) + [ ## Mon application Node.js n’est pas instrumentée ou ne génère pas de télémétrie de la vigie applicative ](#Application-Signals-troubleshoot-telemetry-nodejs) + [ ## Mon application .NET n'est pas instrumentée ou s'arrête à cause des appels du AWS SDK ](#Application-Signals-troubleshoot-sdk-calls) + [ ## Aucune donnée d’application dans le tableau de bord de la vigie applicative ](#Application-Signals-troubleshoot-missingdata) + [ ## Les métriques de service ou de dépendance ont des valeurs inconnues ](#Application-Signals-troubleshoot-unknown-values) + [ ## Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS ](#Application-Signals-troubleshoot-conflict) + [ ## Je veux filtrer les métriques et les traces inutiles ](#Application-Signals-troubleshoot-cardinality) + [ ## Que signifie `InternalOperation` ? ](#Application-Signals-troubleshoot-InternalOperation) + [ ## Comment activer la journalisation pour les applications .NET ? ](#Application-Signals-troubleshoot-dotnet-logging) + [ ## Comment résoudre les conflits de version d’assembly dans les applications .NET ? ](#Application-Signals-troubleshoot-dotnet-conflicts) + [ ## Puis-je le désactiver FluentBit ? ](#Application-Signals-troubleshoot-FluentBit) + [ ## Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ? ](#Application-Signals-troubleshoot-filter-logs) + [ ## Résolution TypeError lors de l'utilisation de AWS Distro pour la couche Lambda OpenTelemetry JavaScript (ADOT) ](#lambda-execution) + [ ## TypeError lors de l'utilisation de gestionnaires Lambda Response Streaming avec AWS Distro for ( OpenTelemetry ADOT) Lambda Layer JavaScript ](#lambda-execution-streaming) + [ ## Mettez à jour les versions requises des agents ou du module complémentaire Amazon EKS ](#CloudWatch-Application-Signals-Agent-Versions) + [ ## Format de métrique intégré (EMF) désactivé pour la vigie applicative ](#emf-appsignals) ## Résoudre les conflits OpenTelemetry de configuration dans Amazon EKS avec les signaux d'application Si vous utilisez OpenTelemetry (OTel) pour la surveillance des performances des applications (APM) avec Amazon EKS et que vous configurez des points de terminaison d'exportation OTLP personnalisés autres que les points de CloudWatch terminaison, vous pouvez rencontrer les comportements suivants après l'installation ou la mise à niveau vers le module complémentaire CloudWatch Observability version 5.0.0 ou ultérieure : + Interruption de la OTel télémétrie existante : le module complémentaire d' CloudWatch observabilité peut remplacer les points de terminaison de l'exportateur OTLP que vous avez codés en dur dans votre application. Cette dérogation n'affecte pas les points de terminaison configurés via des variables d'environnement de conteneur ou. `envFrom` ConfigMap En cas de remplacement, vos statistiques et vos traces risquent de ne pas atteindre leur destination prévue. Pour conserver votre configuration APM existante après la mise à niveau vers la version 5.0.0 ou ultérieure, voir [Désactiver les signaux d'application](install-CloudWatch-Observability-EKS-addon.md#Opting-out-App-Signals) + Les signaux d'application risquent de ne pas fonctionner si vous avez déjà activé les signaux d'application à l'aide du module complémentaire CloudWatch Observability et si vous avez configuré un point de terminaison OTLP personnalisé. Pour résoudre ce problème, supprimez les points de terminaison OTLP personnalisés ou définissez la variable d'environnement `OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true` lors de l'installation ou de la mise à niveau vers la version 5.0.0 ou ultérieure ## Performances de démarrage à froid de la couche Java de la vigie applicative L’ajout de la couche de la vigie applicative aux fonctions Lambda Java augmente la latence de démarrage (temps de démarrage à froid). Les conseils suivants peuvent vous aider à réduire la latence pour les fonctions sensibles au temps. **Démarrage rapide pour l’agent Java** : la couche Lambda Java de la vigie applicative comprend une fonctionnalité de démarrage rapide qui est désactivée par défaut, mais qui peut être activée en définissant la variable OTEL\$1JAVA\$1AGENT\$1FAST\$1STARTUP\$1ENABLED sur true. Lorsqu’elle est activée, cette fonctionnalité configure la JVM pour qu’elle utilise le compilateur C1 de niveau 1 afin de générer un code natif optimisé pour un démarrage à froid plus rapide. Le compilateur C1 privilégie la vitesse au détriment de l’optimisation à long terme, tandis que le compilateur C2 offre des performances globales supérieures en profilant les données au fil du temps. Pour plus d’informations, consultez [Démarrage rapide pour l’agent Java](https://github.com/open-telemetry/opentelemetry-lambda/blob/main/java/README.md#fast-startup-for-java-agent). **Réduisez les temps de démarrage à froid grâce à la simultanéité provisionnée** : la AWS Lambda simultanéité provisionnée préalloue un nombre spécifié d'instances de fonction, les gardant initialisées et prêtes à traiter les demandes immédiatement. Cela réduit les temps de démarrage à froid en éliminant la nécessité d’initialiser l’environnement de la fonction pendant l’exécution, garantissant des performances plus rapides et plus cohérentes, en particulier pour les charges de travail sensibles à la latence. Pour plus d’informations, consultez [Configuration de la simultanéité provisionnée pour une fonction](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html). **Optimisation des performances de démarrage à l'aide de Lambda SnapStart** : AWS Lambda SnapStart fonctionnalité qui optimise les performances de démarrage des fonctions Lambda en créant un instantané préinitialisé de l'environnement d'exécution après la phase d'initialisation de la fonction. Cet instantané est ensuite réutilisé pour démarrer de nouvelles instances, ce qui réduit considérablement les temps de démarrage à froid en sautant le processus d’initialisation lors de l’invocation de la fonction. Pour plus d'informations, voir [Améliorer les performances de démarrage avec Lambda SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html) ## L’application ne démarre pas après l’activation d’Application Signals Si votre application sur un cluster Amazon EKS ne démarre pas une fois que vous avez activé Application Signals sur le cluster, vérifiez les points suivants : + Vérifiez si l’application a été instrumentée par une autre solution de surveillance. La vigie applicative peut ne pas prendre en charge la coexistence avec d’autres solutions d’instrumentation. + Vérifiez que votre application répond aux exigences de compatibilité pour utiliser Application Signals. Pour de plus amples informations, veuillez consulter [Systèmes pris en charge](CloudWatch-Application-Signals-supportmatrix.md). + Si votre application ne parvient pas à extraire les artefacts Application Signals tels que l'agent et CloudWatch les images de l'agent AWS Distro for OpenTelemetery Java ou Python, cela peut être dû à un problème de réseau. Pour atténuer le problème, supprimez l’annotation `instrumentation.opentelemetry.io/inject-java: "true"` ou `instrumentation.opentelemetry.io/inject-python: "true"` du manifeste de déploiement de votre application et redéployez votre application. Vérifiez ensuite si l’application fonctionne. **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.5.0-eksbuild.1` suivantes. Si vous êtes concerné, rétrogradez la version 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. ## L’application Python ne démarre pas après l’activation de la vigie applicative Il s'agit d'un problème connu en OpenTelemetry matière d'instrumentation automatique : une variable d'`PYTHONPATH`environnement manquante peut parfois empêcher le démarrage de l'application. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Pour plus d’informations sur ce problème, consultez [Le paramètre d’instrumentation automatique Python de PYTHONPATH n’est pas compatible avec le comportement de résolution des modules Python, ce qui perturbe les applications Django](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. ## Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI Si vous utilisez un serveur WSGI tel que Gunicorn ou uWSGI, vous devez effectuer des modifications supplémentaires pour que l’auto-instrumentation ADOT Python fonctionne. **Note** Assurez-vous d'utiliser la dernière version d'ADOT Python et le module complémentaire Amazon CloudWatch Observability EKS avant de continuer. **Étapes supplémentaires pour activer la vigie applicative avec un serveur WSGI** 1. Importez l’instrumentation automatique dans les processus de travail bifurqués. Pour Gunicorn, utilisez le hook `post_fork` : ``` # gunicorn.conf.py def post_fork(server, worker): from opentelemetry.instrumentation.auto_instrumentation import sitecustomize ``` Pour uWSGI, utilisez la directive `import`. ``` # uwsgi.ini [uwsgi] ; required for the instrumentation of worker processes enable-threads = true lazy-apps = true import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize ``` 1. Activez la configuration de l’instrumentation automatique ADOT Python pour ignorer le processus principal et le transférer aux processus de travail en définissant la variable d’environnement `OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED` sur `true`. ## Mon application Node.js n’est pas instrumentée ou ne génère pas de télémétrie de la vigie applicative Pour activer la vigie applicative pour Node.js, vous devez vous assurer que votre application Node.js utilise le format de module CommonJS (CJS). La AWS distribution pour OpenTelemetry Node.js ne prend pas en charge le format du module ESM, car OpenTelemetry JavaScript le support d'ESM est expérimental et est en cours de développement. Pour déterminer si votre application utilise CJS et non ESM, assurez-vous que votre application ne remplit pas les [conditions pour activer](https://nodejs.org/api/esm.html#enabling) ESM. ## Mon application .NET n'est pas instrumentée ou s'arrête à cause des appels du AWS SDK 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. ## Aucune donnée d’application dans le tableau de bord de la vigie applicative Si des métriques ou des suivis sont absents des tableaux de bord d’Application Signals, cela peut être dû aux causes suivantes. N’étudiez ces causes que si vous avez attendu 15 minutes pour qu’Application Signals collecte et affiche les données depuis votre dernière mise à jour. + Assurez-vous que la bibliothèque et le framework que vous utilisez sont pris en charge par l’agent Java ADOT. Pour plus d’informations, veuillez consulter la rubrique [Bibliothèques/Frameworks](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks). + Assurez-vous que l' CloudWatch agent est en cours d'exécution. Vérifiez d'abord l'état des modules d' CloudWatch agents et assurez-vous qu'ils le `Running` sont tous. ``` kubectl -n amazon-cloudwatch get pods. ``` Ajoutez ce qui suit au fichier de configuration de l' CloudWatch agent pour activer les journaux de débogage, puis redémarrez l'agent. ``` "agent": { "region": "${REGION}", "debug": true }, ``` Vérifiez ensuite l'absence d'erreurs dans les modules CloudWatch d'agent. + Vérifiez l'absence de problèmes de configuration avec l' CloudWatch agent. Vérifiez que les informations suivantes se trouvent toujours dans le CloudWatch fichier de configuration de l'agent et que l'agent a été redémarré depuis son ajout. ``` "agent": { "region": "${REGION}", "debug": true }, ``` Vérifiez ensuite les journaux de OpenTelemetry débogage pour détecter les messages d'erreur tels que`ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ...`. Ces messages peuvent indiquer le problème. Si cela ne résout pas le problème, videz et vérifiez les variables d’environnement dont le nom commence par `OTEL_` en décrivant le pod à l’aide de la commande `kubectl describe pod`. + Pour activer la journalisation du débogage en OpenTelemetry Python, définissez la variable d'environnement `OTEL_PYTHON_LOG_LEVEL` sur `debug` et redéployez l'application. + Vérifiez que les autorisations d'exportation des données depuis l' CloudWatchagent ne sont pas correctes ou insuffisantes. Si vous voyez `Access Denied` des messages dans les journaux des CloudWatch agents, cela peut être à l'origine du problème. Il est possible que les autorisations appliquées lors de l'installation de l' CloudWatch agent aient été modifiées ou révoquées ultérieurement. + Vérifiez l'absence d'un problème de AWS distribution pour OpenTelemetry (ADOT) lors de la génération de données de télémétrie. Assurez-vous que les annotations d’instrumentation `instrumentation.opentelemetry.io/inject-java` et ` sidecar.opentelemetry.io/inject-java` sont appliquées au déploiement de l’application et que la valeur est `true`. Sans celles-ci, les pods d’application ne seront pas instrumentés même si le module complémentaire ADOT est correctement installé. Ensuite, vérifiez si le conteneur `init` est appliqué sur l’application et si son état `Ready` est `True`. Si le conteneur `init` n’est pas prêt, veuillez consulter l’état pour en connaître la raison. Si le problème persiste, activez la journalisation du débogage sur le SDK OpenTelemetry Java en définissant la variable d'environnement sur true et `OTEL_JAVAAGENT_DEBUG` en redéployant l'application. Recherchez ensuite les messages commençant par `ERROR io.telemetry`. + L' metric/span exportateur est peut-être en train de supprimer des données. Pour le savoir, consultez le journal des applications pour voir s’il contient des messages incluant `Failed to export...`. + L' CloudWatch agent est peut-être limité lorsqu'il envoie des métriques ou des spans à Application Signals. Vérifiez les messages indiquant une limitation dans les journaux de l' CloudWatch agent. + Veuillez vous assurer que vous avez activé la configuration de la découverte de services. Vous ne devez effectuer cette opération qu’une seule fois dans votre région. Pour confirmer cela, dans la CloudWatch console, choisissez **Application Signals**, **Services**. Si l’étape 1 n’est pas marquée comme **Terminée**, sélectionnez **Commencer à découvrir vos services**. Les données devraient commencer à affluer dans les cinq minutes. ## Les métriques de service ou de dépendance ont des valeurs inconnues Si vous voyez **UnknownService**, **UnknownOperation**UnknownRemoteService****, ou **UnknownRemoteOperation**pour un nom de dépendance ou une opération dans les tableaux de bord des signaux d'application, vérifiez si l'occurrence de points de données pour le service distant inconnu et le fonctionnement à distance inconnu coïncident avec leurs déploiements. + **UnknownService**signifie que le nom d'une application instrumentée est inconnu. Si la variable d’environnement `OTEL_SERVICE_NAME` n’est pas définie et que `service.name` n’est pas spécifié dans `OTEL_RESOURCE_ATTRIBUTES`, le nom du service est défini sur `UnknownService`. Pour résoudre ce problème, veuillez spécifier le nom du service dans `OTEL_SERVICE_NAME` ou `OTEL_RESOURCE_ATTRIBUTES`. + **UnknownOperation**signifie que le nom d'une opération invoquée est inconnu. Cela se produit lorsque la vigie applicative ne parvient pas à découvrir un nom d’opération qui invoque l’appel distant ou lorsque le nom d’opération extrait contient des valeurs de cardinalité élevées. + **UnknownRemoteService**signifie que le nom du service de destination est inconnu. Cela se produit lorsque le système ne parvient pas à extraire le nom du service de destination auquel l’appel distant accède. Une solution consiste à créer une portée personnalisée autour de la fonction qui envoie une requête et à ajouter l’attribut `aws.remote.service` avec la valeur désignée. Une autre option consiste à configurer l' CloudWatch agent pour personnaliser la valeur métrique de`RemoteService`. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultez[Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md). + **UnknownRemoteOperation**signifie que le nom de l'opération de destination est inconnu. Cela se produit lorsque le système est incapable d’extraire le nom de l’opération de destination à laquelle l’appel distant accède. Une solution consiste à créer une portée personnalisée autour de la fonction qui envoie une requête et à ajouter l’attribut `aws.remote.operation` avec la valeur désignée. Une autre option consiste à configurer l' CloudWatch agent pour personnaliser la valeur métrique de`RemoteOperation`. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultez[Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md). ## Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS Lorsque vous installez ou mettez à jour le module complémentaire Amazon CloudWatch Observability EKS, si vous remarquez une défaillance causée par un type `Health Issue` `ConfigurationConflict` de fichier dont la description commence par`Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`, c'est probablement parce que vous avez déjà ClusterRoleBinding installé l' CloudWatch agent et ses composants associés tels que le ServiceAccount, le ClusterRole et le sur le cluster. Lorsque le module complémentaire tente d'installer l' CloudWatch agent et ses composants associés, s'il détecte une modification du contenu, il échoue par défaut à l'installation ou à la mise à jour pour éviter de modifier l'état des ressources du cluster. Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez cet échec, nous vous recommandons de supprimer une configuration d' CloudWatch agent existante que vous aviez précédemment installée sur le cluster, puis d'installer le module complémentaire EKS. Veillez à sauvegarder toutes les personnalisations que vous avez éventuellement apportées à la configuration d'origine de l' CloudWatch agent, telle qu'une configuration d'agent personnalisée, et à les fournir au module complémentaire Amazon CloudWatch Observability EKS lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l' CloudWatch agent pour l'intégration à Container Insights, consultez [Suppression de l' CloudWatch agent et de Fluent Bit for Container Insights](ContainerInsights-delete-agent.md) pour plus d'informations. Le module complémentaire prend également en charge une option de configuration de résolution des conflits capable de spécifier `OVERWRITE`. Vous pouvez utiliser cette option pour procéder à l’installation ou à la mise à jour du module complémentaire en remplaçant les conflits sur le cluster. Si vous utilisez la console Amazon EKS, vous trouverez la **Méthode de résolution des conflits** lorsque vous choisissez les **Paramètres de configuration facultatifs** lorsque vous créez ou mettez à jour le module complémentaire. Si vous utilisez le AWS CLI, vous pouvez fournir le `--resolve-conflicts OVERWRITE` à votre commande pour créer ou mettre à jour le module complémentaire. ## Je veux filtrer les métriques et les traces inutiles Si Application Signals collecte des traces et des mesures que vous ne souhaitez pas utiliser, consultez [Gestion des opérations à cardinalité élevée](Application-Signals-Cardinality.md) pour plus d'informations sur la configuration de l' CloudWatch agent avec des règles personnalisées afin de réduire la cardinalité. Pour plus d’informations sur la personnalisation des règles d’échantillonnage des traces, consultez [Configurer les règles d’échantillonnage](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray-interface-console.html#xray-console) dans la documentation X-Ray. ## Que signifie `InternalOperation` ? Un `InternalOperation` est une opération déclenchée en interne par l’application plutôt que par une invocation externe. L’apparition de `InternalOperation` est un comportement normal et attendu. Voici quelques exemples typiques où vous pourriez voir `InternalOperation` : + **Préchargement au démarrage** : votre application effectue une opération nommée `loadDatafromDB` qui lit les métadonnées d’une base de données pendant la phase de préparation. Au lieu d’observer `loadDatafromDB` comme une opération de service, vous le verrez classé comme `InternalOperation`. + **Exécution asynchrone en arrière-plan** : votre application s’abonne à une file d’attente d’événements et traite les données en continu en conséquence chaque fois qu’il y a une mise à jour. Chaque opération déclenchée sera classée sous `InternalOperation` en tant qu’opération de service. + **Récupération des informations d’hôte à partir d’un registre de services** : votre application communique avec un registre de services pour la découverte de services. Toutes les interactions avec le système de découverte sont classées comme `InternalOperation`. ## Comment activer la journalisation pour les applications .NET ? Pour activer la journalisation pour les applications .NET, veuillez configurer les variables d’environnement suivantes. Pour plus d'informations sur la configuration de ces variables d'environnement, consultez la section [Résolution des problèmes d'instrumentation automatique .NET](https://opentelemetry.io/docs/zero-code/net/troubleshooting/#general-steps) dans la OpenTelemetry documentation. + `OTEL_LOG_LEVEL` + `OTEL_DOTNET_AUTO_LOG_DIRECTORY` + `COREHOST_TRACE` + `COREHOST_TRACEFILE` ## Comment résoudre les conflits de version d’assembly dans les applications .NET ? Si l'erreur suivante s'affiche, consultez la section [Conflits de versions d'assemblage](https://opentelemetry.io/docs/zero-code/net/troubleshooting/#assembly-version-conflicts) dans la OpenTelemetry documentation pour connaître les étapes de résolution. ``` 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.
$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26 ``` ## Puis-je le désactiver FluentBit ? Vous pouvez le désactiver FluentBit en configurant le module complémentaire Amazon CloudWatch Observability EKS. Pour de plus amples informations, veuillez consulter [(Facultatif) Configuration supplémentaire](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration). ## Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ? Non, le filtrage des journaux des conteneurs n’est pas encore pris en charge. ## Résolution TypeError lors de l'utilisation de AWS Distro pour la couche Lambda OpenTelemetry JavaScript (ADOT) Votre fonction Lambda peut échouer avec cette erreur : `TypeError - "Cannot redefine property: handler"` lorsque vous : + Utiliser la couche JavaScript Lambda ADOT + `esbuild`À utiliser pour compiler TypeScript + Exportez votre gestionnaire avec le mot-clé `export` La couche JavaScript Lambda ADOT doit modifier votre gestionnaire lors de l'exécution. Lorsque vous utilisez le `export` mot clé with `esbuild` (directement ou via AWS CDK), `esbuild` cela rend votre gestionnaire immuable, empêchant ainsi ces modifications. Exportez votre fonction de gestionnaire en utilisant `module.exports` au lieu du mot-clé `export` : ``` // Before export const handler = (event) => { // Handler Code } ``` ``` // After const handler = async (event) => { // Handler Code } module.exports = { handler } ``` ## TypeError lors de l'utilisation de gestionnaires Lambda Response Streaming avec AWS Distro for ( OpenTelemetry ADOT) Lambda Layer JavaScript Votre fonction Lambda peut échouer avec cette erreur : `TypeError - "responseStream.write is not a function"` lorsque vous : + Utiliser la couche JavaScript Lambda ADOT avec l'instrumentation AWS Lambda activée (activée par défaut) + Utilisation de la fonctionnalité de diffusion des réponses dans les environnements d'exécution gérés par Node.js. Par exemple, lorsque votre gestionnaire de fonctions est comme : ``` * export const handler = awslambda.streamifyResponse(...) ``` L'instrumentation AWS Lambda de la couche JavaScript Lambda ADOT ne prend actuellement pas en charge le streaming de réponses dans les environnements d'exécution gérés par Node.js. Elle doit donc être désactivée pour éviter cela. TypeError ## Mettez à jour les versions requises des agents ou du module complémentaire Amazon EKS Après le 9 août 2024, CloudWatch Application Signals ne prendra plus en charge les anciennes versions du module complémentaire Amazon CloudWatch Observability EKS, de l'agent et de l' CloudWatch agent AWS Distro for OpenTelemetry Auto-Instrumentation. + Pour le module complémentaire Amazon CloudWatch Observability EKS, les versions antérieures `v1.7.0-eksbuild.1` ne seront pas prises en charge. + Pour l' CloudWatch agent, les versions antérieures `1.300040.0` ne seront pas prises en charge. + Pour l'agent AWS d' OpenTelemetry auto-instrumentation Distro for : + Pour Java, les versions antérieures à `1.32.2` ne seront pas prises en charge. + Pour Python, les versions antérieures à `0.2.0` ne seront pas prises en charge. + Pour .NET, les versions antérieures à `1.3.2` ne seront pas prises en charge. + Pour Node.js, les versions antérieures à `0.3.0` ne seront pas prises en charge. **Important** Les dernières versions des agents incluent des mises à jour du schéma de métriques de la vigie applicative. Ces mises à jour ne sont pas rétrocompatibles, ce qui peut entraîner des problèmes de données si des versions incompatibles sont utilisées. Afin de garantir une transition en douceur vers la nouvelle fonctionnalité, veuillez suivre les étapes suivantes : Si votre application s'exécute sur Amazon EKS, veillez à redémarrer toutes les applications instrumentées après avoir mis à jour le module complémentaire Amazon CloudWatch Observability. **Pour les applications exécutées sur d'autres plateformes, veillez à mettre à niveau l' CloudWatch agent et l'agent d' AWS OpenTelemetry instrumentation automatique vers les dernières versions.** Les instructions fournies dans les sections suivantes peuvent vous aider à effectuer la mise à jour vers une version prise en charge. **Contents** + [ ### Mettre à jour le module complémentaire Amazon CloudWatch Observability EKS ](#Application-Signals-Upgrade-Addon) + [ #### Utilisation de la console ](#Upgrade-Addon-Console) + [ #### Utilisez le AWS CLI ](#Upgrade-Addon-CLI) + [ ### Mettre à jour l' CloudWatch agent et l'agent ADOT ](#Application-Signals-Upgrade-Agents) + [ #### Mettre à jour sur Amazon ECS ](#Upgrade-Agents-ECS) + [ #### Mettre à jour sur Amazon EC2 ou d’autres architectures ](#Upgrade-Addon-EC2) ### Mettre à jour le module complémentaire Amazon CloudWatch Observability EKS Pour le module complémentaire Amazon CloudWatch Observability EKS, vous pouvez utiliser le AWS Management Console ou le AWS CLI. #### Utilisation de la console **Pour mettre à niveau le module complémentaire à l’aide de la console** 1. Ouvrez la console Amazon EKS à l'adresse [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters). 1. Sélectionnez le nom du cluster Amazon EKS à mettre à jour. 1. Choisissez l'onglet **Modules complémentaires**, puis **Amazon CloudWatch Observability**. 1. Sélectionnez **Modifier**, choisissez la version vers laquelle vous voulez effectuer la mise à niveau, puis sélectionnez **Enregistrer les modifications**. Veuillez vous assurer de sélectionner `v1.7.0-eksbuild.1` ou une version ultérieure. 1. Entrez l'une des AWS CLI commandes suivantes pour redémarrer vos services. ``` # Restart a deployment kubectl rollout restart deployment/name # Restart a daemonset kubectl rollout restart daemonset/name # Restart a statefulset kubectl rollout restart statefulset/name ``` #### Utilisez le AWS CLI **Pour mettre à niveau le module complémentaire à l'aide du AWS CLI** 1. Entrez la commande suivante pour trouver la dernière version. ``` aws eks describe-addon-versions \ --addon-name amazon-cloudwatch-observability ``` 1. Entrez la commande suivante pour mettre à jour le module complémentaire. *\$1VERSION*Remplacez-le par une version antérieure `v1.7.0-eksbuild.1` ou ultérieure. Remplacez *\$1AWS\$1REGION* et *\$1CLUSTER* par le nom de votre région et de votre cluster. ``` 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 ``` **Note** Si vous utilisez une configuration personnalisée pour le module complémentaire, vous trouverez un exemple de configuration à utiliser *\$1JSON\$1CONFIG* dans[Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md). 1. Entrez l'une des AWS CLI commandes suivantes pour redémarrer vos services. ``` # Restart a deployment kubectl rollout restart deployment/name # Restart a daemonset kubectl rollout restart daemonset/name # Restart a statefulset kubectl rollout restart statefulset/name ``` ### Mettre à jour l' CloudWatch agent et l'agent ADOT Si vos services s'exécutent sur des architectures autres qu'Amazon EKS, vous devrez mettre à niveau l' CloudWatch agent et l'agent d'auto-instrumentation ADOT pour utiliser les dernières fonctionnalités d'Application Signals. #### Mettre à jour sur Amazon ECS **Pour mettre à niveau vos agents pour les services fonctionnant sur Amazon ECS** 1. Créez une nouvelle révision de définition de tâche. Pour plus d’informations, consultez [Mettre à jour une définition de tâche à l’aide de la console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2). 1. Remplacez le `$IMAGE` du conteneur `ecs-cwagent` par la dernière balise d’image de [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR. Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `1.300040.0`. 1. Remplacez le `$IMAGE` du conteneur `init` par la dernière balise d’image provenant des emplacements suivants : + Pour Java, utilisez [adot-autoinstrumentation-javaaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java). Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `1.32.2`. + Pour Python, utilisez [adot-autoinstrumentation-pythonaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-python). Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `0.2.0`. + Pour .NET, utilisez [adot-autoinstrumentation-dotnetaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-dotnet). Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `1.3.2`. + Pour Node.js, utilisez [adot-autoinstrumentation-nodeaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-node). Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `0.3.0`. 1. Mettez à jour les variables d’environnement de la vigie applicative dans votre conteneur d’application en suivant les instructions fournies dans [Étape 4 : Instrumenter votre application avec l' CloudWatch agent](CloudWatch-Application-Signals-ECS-Sidecar.md#CloudWatch-Application-Signals-Enable-ECS-Instrument). 1. Déployez votre service avec la nouvelle définition de tâche. #### Mettre à jour sur Amazon EC2 ou d’autres architectures **Pour mettre à niveau vos agents pour les services s’exécutant sur Amazon EC2 ou d’autres architectures** 1. Assurez-vous de sélectionner la version `1.300040.0` ou une version ultérieure de la version de l' CloudWatch agent. 1. Téléchargez la dernière version de l'agent AWS Distro for OpenTelemetry Auto-Instrumentation depuis l'un des emplacements suivants : + Pour Java, utilisez [aws-otel-java-instrumentation ](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java). Si vous mettez à niveau vers une version fixe, veillez à choisir `1.32.2` ou une version ultérieure. + Pour Python, utilisez [aws-otel-python-instrumentation ](https://github.com/aws-observability/aws-otel-python-instrumentation/releases). Si vous mettez à niveau vers une version fixe, veillez à choisir `0.2.0` ou une version ultérieure. + Pour .NET, utilisez [aws-otel-dotnet-instrumentation](https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases). Si vous mettez à niveau vers une version fixe, veillez à choisir `1.3.2` ou une version ultérieure. + Pour Node.js, utilisez [aws-otel-js-instrumentation](https://github.com/aws-observability/aws-otel-js-instrumentation/releases). Si vous mettez à niveau vers une version fixe, veillez à choisir `0.3.0` ou une version ultérieure. 1. Appliquez les variables d’environnement de la vigie applicative mises à jour à votre application, puis démarrez votre application. Pour de plus amples informations, veuillez consulter [Étape 3 : instrumenter votre application et la démarrer](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument). ## Format de métrique intégré (EMF) désactivé pour la vigie applicative La désactivation de l’EMF pour le groupe de journaux `/aws/application-signals/data` peut avoir les conséquences suivantes sur les fonctionnalités de la vigie applicative. + Les métriques et les graphiques de la vigie applicative ne s’afficheront pas + Les fonctionnalités de la vigie applicative seront dégradées **Comment restaurer la vigie applicative ?** Lorsque la vigie applicative affiche des graphiques ou des métriques vides, vous devez activer EMF pour le groupe de journaux `/aws/application-signals/data` afin de restaurer toutes les fonctionnalités. Pour de plus amples informations, veuillez consulter [PutAccountPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutAccountPolicy.html#API_PutAccountPolicy_RequestSyntax).