Résolution des problèmes liés à l’installation d’Application Signals - Amazon CloudWatch
Performances 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 applicativeAucune 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 conflit de configuration lors de la gestion du module complémentaire EKS Amazon CloudWatch ObservabilityJe 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 ?Est-il possible de désactiver FluentBit ?Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ? Résolution de l’erreur TypeError lors de l’utilisation de la couche JavaScript Lambda d’AWS Distro for OpenTelemetry (ADOT) 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

Résolution des problèmes liés à l’installation d’Application Signals

Cette section contient des conseils de résolution des problèmes pour CloudWatch Application Signals.

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éduire les temps de démarrage à froid avec la simultanéité provisionnée : la simultanéité provisionnée AWS Lambda pré-alloue un nombre spécifié d’instances de fonction, les gardant initialisées et prêtes à traiter immédiatement les demandes. 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.

Optimiser les performances de démarrage à l’aide de SnapStart de Lambda : le SnapStart d’AWS Lambda est une 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, consultez Amélioration des performances de démarrage avec SnapStart de Lambda

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, consultez Systèmes pris en charge.

  • Si votre application ne parvient pas à extraire les artefacts de la vigie applicative tels que l’agent Java ou Python AWS Distro pour OpenTelemetery et les images de l’agent CloudWatch, cela peut être dû à un problème 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 1.32.5 du kit SDK Java est connue pour ne pas fonctionner avec les applications utilisant JBoss Wildfly. Ce problème s’étend au module complémentaire EKS d’observabilité Amazon CloudWatch, affectant les versions 2.3.0-eksbuild.1 à 2.5.0-eksbuild.1.

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 dans l’instrumentation automatique OpenTelemetry : l’absence de la variable d’environnement PYTHONPATH 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 nécessaires, comme indiqué dans la documentation OpenTelemetry pour 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 permet à OpenTelemetry d’accéder correctement à vos paramètres Django et de s’y intégrer.

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

Veuillez vous assurer que vous utilisez la dernière version d’ADOT Python et le module complémentaire EKS d’observabilité Amazon CloudWatch 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 distribution AWS Distro for OpenTelemetry Node.js ne prend pas en charge le format de module ESM, car la prise en charge d’ESM par OpenTelemetry JavaScript est expérimentale et en cours de développement.

Pour déterminer si votre application utilise CJS et non ESM, assurez-vous qu’elle ne remplit pas les conditions requises pour activer ESM.

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’agent CloudWatch est en cours d’exécution. Vérifiez d’abord l’état des pods de l’agent CloudWatch et assurez-vous qu’ils sont tous dans l’état Running.

    kubectl -n amazon-cloudwatch get pods.

    Ajoutez les éléments suivants au fichier de configuration de l’agent CloudWatch 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 pods de l’agent CloudWatch.

  • Vérifiez les problèmes de configuration de l’agent CloudWatch. Vérifiez que les informations suivantes figurent toujours dans le fichier de configuration de l’agent CloudWatch et que l’agent a été redémarré depuis leur ajout.

    "agent": {
  "region": "${REGION}",
  "debug": true
},

    Vérifiez ensuite les journaux de débogage d’OpenTelemetry 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 de débogage OpenTelemetry Python, définissez la variable d’environnement OTEL_PYTHON_LOG_LEVEL sur debug et redéployez l’application.

  • Vérifiez si les autorisations d’exportation des données de l’agent CloudWatch sont erronées ou insuffisantes. Si vous voyez des messages Access Denied dans les journaux de l’agent CloudWatch, cela peut être à l’origine du problème. Il est possible que les autorisations appliquées lors de l’installation de l’agent CloudWatch aient été modifiées ou révoquées ultérieurement.

  • Vérifiez l’existence d’un problème d’AWS Distro for 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 de débogage sur le kit SDK Java OpenTelemetry en définissant la variable d’environnement OTEL_JAVAAGENT_DEBUG sur true et en redéployant l’application. Recherchez ensuite les messages commençant par ERROR io.telemetry.

  • L’exportateur de métrique/d’intervalle 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’agent CloudWatch est peut-être limité lorsqu’il envoie des métriques ou des intervalles à Application Signals. Vérifiez la présence de messages indiquant une limitation dans les journaux de l’agent CloudWatch.

  • 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 le confirmer, dans la console CloudWatch, sélectionnez Vigie applicative CloudWatch, 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 de la vigie applicative, vérifiez si l’occurrence des points de données pour le service distant inconnu et l’opération distante inconnue coïncide 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 demande et à ajouter l’attribut aws.remote.service avec la valeur désignée. Une autre option consiste à configurer l’agent CloudWatch pour personnaliser la valeur métrique de RemoteService. Pour plus d’informations sur les personnalisations dans l’agent CloudWatch, consultez Activation de CloudWatch Application Signals.

  • 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 demande et à ajouter l’attribut aws.remote.operation avec la valeur désignée. Une autre option consiste à configurer l’agent CloudWatch pour personnaliser la valeur métrique de RemoteOperation. Pour plus d’informations sur les personnalisations dans l’agent CloudWatch, consultez Activation de CloudWatch Application Signals.

Gestion d’un conflit de configuration lors de la gestion du module complémentaire EKS Amazon CloudWatch Observability

Lorsque vous installez ou mettez à jour le module complémentaire EKS Amazon CloudWatch Observability, si vous remarquez une défaillance due à une Health Issue d’un type ConfigurationConflict dont la description commence par Conflicts found when trying to apply. Will not continue due to resolve conflicts mode, c’est probablement parce que l’agent CloudWatch et ses composants associés tels que le ServiceAccount, le ClusterRole et le ClusterRoleBinding sont déjà installés sur le cluster. Lorsque le module complémentaire tente d’installer l’agent CloudWatch et ses composants associés, s’il détecte une modification du contenu, il échoue par défaut à l’installation ou à la mise à jour afin d’éviter de modifier l’état des ressources du cluster.

Si vous essayez d’intégrer le module complémentaire EKS Amazon CloudWatch Observability et que vous constatez cet échec, nous vous recommandons de supprimer une configuration d’agent CloudWatch 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’agent CloudWatch, telle qu’une configuration d’agent personnalisée, et à les fournir à le module complémentaire EKS Amazon CloudWatch Observability lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l’agent CloudWatch pour l’intégration à Container Insights, veuillez consulter Suppression de l’agent CloudWatch et de Fluent Bit pour 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 l’AWS CLI, vous pouvez ajouter --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 la vigie applicative collecte des traces et des métriques dont vous ne voulez pas disposer, consultez Gestion des opérations à cardinalité élevée pour plus d’informations sur la configuration de l’agent CloudWatch 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 un appel 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 Résolution des problèmes d’instrumentation automatique .NET dans la documentation OpenTelemetry.

  • 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 vous obtenez l’erreur suivante, consultez Conflits de version d’assembly dans la documentation OpenTelemetry 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

Est-il possible de désactiver FluentBit ?

Vous pouvez désactiver FluentBit en configurant le module complémentaire EKS d’observabilité Amazon CloudWatch. Pour de plus amples informations, consultez (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 de l’erreur TypeError lors de l’utilisation de la couche JavaScript Lambda d’AWS Distro for OpenTelemetry (ADOT)

Votre fonction Lambda peut échouer avec cette erreur : TypeError - "Cannot redefine property: handler" lorsque vous :

  • Utilisez la couche JavaScript Lambda d’ADOT

  • Utilisez esbuild pour compiler TypeScript

  • Exportez votre gestionnaire avec le mot-clé export

La couche JavaScript Lambda d’ADOT doit modifier votre gestionnaire au moment de l’exécution. Lorsque vous utilisez le mot-clé export avec esbuild (directement ou via AWS CDK), esbuild 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 }

Mettez à jour les versions requises des agents ou du module complémentaire Amazon EKS

Après le 9 août 2024, la vigie applicative CloudWatch ne prendra plus en charge les anciennes versions du module complémentaire EKS d’observabilité Amazon CloudWatch, de l’agent CloudWatch et de l’agent d’instrumentation automatique AWS Distro for OpenTelemetry.

  • Pour le module complémentaire EKS d’observabilité Amazon CloudWatch, les versions antérieures à v1.7.0-eksbuild.1 ne seront pas prises en charge.

  • Pour l’agent CloudWatch, les versions antérieures à 1.300040.0 ne seront pas prises en charge.

  • Pour l’agent d’instrumentation automatique AWS Distro for OpenTelemetry :

    • 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, assurez-vous de redémarrer toutes les applications instrumentées après avoir mis à jour le module complémentaire EKS d’observabilité CloudWatch.

  • Pour les applications fonctionnant sur d’autres plateformes, veillez à mettre à niveau à la fois l’agent CloudWatch et l’agent d’instrumentation automatique AWS OpenTelemetry 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 EKS d’observabilité Amazon CloudWatch

Pour le module complémentaire EKS d’observabilité Amazon CloudWatch, vous pouvez utiliser la AWS Management Console ou l’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. Sélectionnez l’onglet Modules complémentaires, puis Observabilité Amazon CloudWatch.

  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 commandes AWS CLI 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

Utilisation de la AWS CLI

Pour mettre à niveau le module complémentaire à l’aide d’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. Remplacez $VERSION par une version v1.7.0-eksbuild.1 ou ultérieure. Remplacez $AWS_REGION et $CLUSTER par votre région et le nom 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 pour $JSON_CONFIG dans Activation de CloudWatch Application Signals.

  3. Entrez l’une des commandes AWS CLI 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’agent CloudWatch et l’agent ADOT

Si vos services s’exécutent sur des architectures autres qu’Amazon EKS, vous devrez mettre à niveau à la fois l’agent CloudWatch et l’agent d’instrumentation automatique ADOT pour utiliser les dernières fonctionnalités de la vigie applicative.

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’agent CloudWatch.

  5. 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 ultérieure de l’agent CloudWatch.

  2. Téléchargez la dernière version de l’agent d’instrumentation automatique AWS Distro for OpenTelemetry à partir de 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, consultez É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 plus d’informations, consultez PutAccountPolicy.