Résolution des problèmes liés à l’installation d’Application Signals - Amazon CloudWatch
Résoudre les conflits OpenTelemetry de configuration dans Amazon EKS avec les signaux d'applicationPerformances de démarrage à froid de la couche Java de la vigie applicativeL’application ne démarre pas après l’activation d’Application SignalsL’application Python ne démarre pas après l’activation de la vigie applicativeAucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGIMon application Node.js n’est pas instrumentée ou ne génère pas de télémétrie de la vigie applicativeMon application .NET n'est pas instrumentée ou s'arrête à cause des appels du AWS SDKAucune donnée d’application dans le tableau de bord de la vigie applicativeLes métriques de service ou de dépendance ont des valeurs inconnuesGestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKSJe veux filtrer les métriques et les traces inutilesQue signifie InternalOperation ?Comment activer la journalisation pour les applications .NET ?Comment résoudre les conflits de version d’assembly dans les applications .NET ?Puis-je le désactiver FluentBit ?Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ? Résolution TypeError lors de l'utilisation de AWS Distro pour la couche Lambda OpenTelemetry JavaScript (ADOT) TypeError lors de l'utilisation de gestionnaires Lambda Response Streaming avec AWS Distro for ( OpenTelemetry ADOT) Lambda Layer JavaScript Mettez à jour les versions requises des agents ou du module complémentaire Amazon EKSFormat de métrique intégré (EMF) désactivé pour la vigie applicative

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.

Rubriques

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

  • Les signaux d'application peuvent 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_JAVA_AGENT_FAST_STARTUP_ENABLED 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.

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.

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

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.

  • 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'PYTHONPATHenvironnement 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.

Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la documentation OpenTelemetry Python.

  • 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

  2. 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 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.

  • 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 queERROR 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 la présence de 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, UnknownOperationUnknownRemoteService, ou UnknownRemoteOperationpour 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.

  • UnknownServicesignifie 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.

  • UnknownOperationsignifie 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.

  • UnknownRemoteServicesignifie 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 deRemoteService. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultezActiver les signaux CloudWatch d'application.

  • UnknownRemoteOperationsignifie 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 deRemoteOperation. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultezActiver les signaux CloudWatch d'application.

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 parConflicts 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 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 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 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 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 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.<Main>$(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.

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.

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#/clusters.

  2. Sélectionnez le nom du cluster Amazon EKS à mettre à jour.

  3. Choisissez l'onglet Modules complémentaires, puis Amazon CloudWatch Observability.

  4. 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.

  5. 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

  2. Entrez la commande suivante pour mettre à jour le module complémentaire. $VERSIONRemplacez-le par une version antérieure v1.7.0-eksbuild.1 ou ultérieure. Remplacez $AWS_REGION et $CLUSTER 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 $JSON_CONFIG dansActiver les signaux CloudWatch d'application.

  3. 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.

  2. Remplacez le $IMAGE du conteneur ecs-cwagent par la dernière balise d’image de 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.

  3. Remplacez le $IMAGE du conteneur init par la dernière balise d’image provenant des emplacements suivants :

  4. 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.

  5. Déployez votre service avec la nouvelle définition de tâche.

Mise à jour sur Amazon EC2 ou sur d'autres architectures

Pour mettre à niveau vos agents pour les services exécutés sur Amazon EC2 ou sur 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.

  2. 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 .

      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 .

      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.

      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.

      Si vous mettez à niveau vers une version fixe, veillez à choisir 0.3.0 ou une version ultérieure.

  3. 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.

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.