Résolution des problèmes liés à l’installation d’Application Signals - Amazon CloudWatch
Signaux d'application : performances de démarrage à froid de la couche JavaL’application ne démarre pas après l’activation d’Application SignalsL'application Python ne démarre pas une fois les signaux d'application activésAucune donnée de signal d'application pour une application Python utilisant un serveur WSGIMon application Node.js n'est pas instrumentée ou ne génère pas de télémétrie des signaux d'applicationAucune donnée d'application dans le tableau de bord des signaux d'applicationLes métriques de service ou les métriques de dépendance ont des valeurs inconnuesGestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKSJe souhaite filtrer les métriques et les traces inutilesQu'est-ce que InternalOperation cela signifie ?Comment activer la journalisation pour les applications .NET ?Comment puis-je résoudre les conflits de version d'assemblage 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) Mise à jour vers les versions requises des agents ou du module complémentaire Amazon EKS

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.

Signaux d'application : performances de démarrage à froid de la couche Java

L'ajout de la couche de signaux d'application aux fonctions Java Lambda augmente la latence de démarrage (temps de démarrage à froid). Les conseils suivants peuvent vous aider à réduire le temps de latence pour les fonctions sensibles au facteur temps.

Démarrage rapide pour l'agent Java — La couche Lambda Java Application Signals inclut 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 un compilateur C1 de niveau 1 de compilation hiérarchisé afin de générer un code natif optimisé rapide pour des démarrages à froid plus rapides. Le compilateur C1 privilégie la vitesse au détriment de l'optimisation à long terme, tandis que le compilateur C2 fournit des performances globales supérieures en profilant les données au fil du temps.

Pour plus d'informations, voir Démarrage rapide de 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 le besoin d'initialiser l'environnement des fonctions pendant l'exécution, garantissant ainsi des performances plus rapides et plus cohérentes, en particulier pour les charges de travail sensibles à la latence. Pour plus d'informations, consultez la section 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 omettant 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. Les signaux d'application peuvent 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, puis 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 votre collecte de 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 une fois les signaux d'application activés

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'PYTHONPATHenvironnement à l'emplacement du répertoire de travail de votre application. Pour plus d'informations sur ce problème, consultez la section Le paramètre d'auto-instrumentation Python de PYTHONPATH n'est pas conforme au comportement de résolution des modules de 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 --noreload drapeau pour empêcher le rechargement automatique.

  • Définissez la variable d'DJANGO_SETTINGS_MODULEenvironnement sur l'emplacement du settings.py fichier de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.

Aucune donnée de signal d'application pour une application Python utilisant un serveur WSGI

Si vous utilisez un serveur WSGI tel que Gunicorn ou uWSGI, vous devez apporter des modifications supplémentaires pour que l'instrumentation automatique 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 les signaux d'application avec un serveur WSGI

  1. Importez l'instrumentation automatique dans les processus de travail bifurqués.

    Pour Gunicorn, utilisez le post_fork crochet :

    # 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 pour l'instrumentation automatique ADOT Python afin d'ignorer le processus principal et de s'en remettre aux travailleurs en définissant la variable d'OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLEDenvironnement sur. true

Mon application Node.js n'est pas instrumentée ou ne génère pas de télémétrie des signaux d'application

Pour activer les signaux d'application pour Node.js, vous devez vous assurer que votre application Node.js utilise le format du module CommonJS (CJS). Actuellement, la AWS distribution pour OpenTelemetry Node.js ne prend pas en charge le format du module ESM, car le support OpenTelemetry JavaScript 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.

Aucune donnée d'application dans le tableau de bord des signaux d'application

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.

  • Assurez-vous d'avoir activé la configuration de découverte de services. Vous ne devez le faire 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, choisissez Commencer à découvrir vos services. Les données devraient commencer à affluer dans les cinq minutes.

Les métriques de service ou les métriques 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'OTEL_SERVICE_NAMEenvironnement n'est pas définie et service.name n'est pas spécifiée dansOTEL_RESOURCE_ATTRIBUTES, le nom du service est défini sur. UnknownService Pour résoudre ce problème, spécifiez le nom du service dans OTEL_SERVICE_NAME ouOTEL_RESOURCE_ATTRIBUTES.

  • UnknownOperationsignifie que le nom d'une opération invoquée est inconnu. Cela se produit lorsque Application Signals ne parvient pas à découvrir le nom d'une opération qui appelle l'appel à distance, ou lorsque le nom de l'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 un intervalle personnalisé autour de la fonction qui envoie la demande 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 ne parvient pas à extraire le nom de l'opération de destination à laquelle l'appel distant accède.

    Une solution consiste à créer un intervalle personnalisé autour de la fonction qui envoie la demande 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 Supprimer l' CloudWatch agent et 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 souhaite filtrer les métriques et les traces inutiles

Si Application Signals collecte des traces et des mesures que vous ne souhaitez pas utiliser, consultez Gérez les opérations à haute cardinalité 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 la section Configurer les règles d'échantillonnage dans la documentation de X-Ray.

Qu'est-ce que InternalOperation cela signifie ?

An InternalOperation est une opération déclenchée par l'application en interne plutôt que par un appel externe. Voir InternalOperation est attendu, comportement sain.

Voici quelques exemples typiques que vous pourriez voir InternalOperation :

  • Préchargement au démarrage : votre application exécute une opération nommée loadDatafromDB qui lit les métadonnées d'une base de données pendant la phase de préchauffage. Au lieu de l'observer en loadDatafromDB tant qu'opération de service, vous la verrez classée dans la catégorieInternalOperation.

  • Exécution asynchrone en arrière-plan : votre application s'abonne à une file d'événements et traite les données de streaming en conséquence chaque fois qu'une mise à jour est effectuée. Chaque opération déclenchée sera considérée InternalOperation comme une opération de service.

  • Extraction des informations sur l'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 dans la catégorieInternalOperation.

Comment activer la journalisation pour les applications .NET ?

Pour activer la journalisation pour les applications .NET, configurez 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 puis-je résoudre les conflits de version d'assemblage 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 à la module.exports place du export mot-clé : 

// Before
export const handler = (event) => {
  // Handler Code
}
// After
const handler = async (event) => {
  // Handler Code
}
module.exports = { handler }

Mise à jour vers 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 sont pas prises en charge.

    • Pour Python, les versions plus anciennes 0.2.0 ne sont pas prises en charge.

    • Pour .NET, les versions antérieures 1.3.2 ne sont pas prises en charge.

    • Pour Node.js, les versions antérieures 0.3.0 ne sont pas prises en charge.

Important

Les dernières versions des agents incluent des mises à jour du schéma métrique des signaux d'application. 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. Pour garantir une transition fluide vers les nouvelles fonctionnalités, procédez comme suit :

  • 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 des sections suivantes peuvent vous aider à effectuer une 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. Choisissez le nom du cluster Amazon EKS à mettre à jour.

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

  4. Choisissez Modifier, sélectionnez la version vers laquelle vous souhaitez effectuer la mise à jour, puis sélectionnez Enregistrer les modifications.

    Assurez-vous de choisir v1.7.0-eksbuild.1 ou plus tard.

  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.

Mise à jour sur Amazon ECS

Pour mettre à niveau vos agents pour les services exécutés sur Amazon ECS

  1. Créez une nouvelle révision de définition de tâche. Pour plus d'informations, consultez la section Mise à jour d'une définition de tâche à l'aide de la console.

  2. Remplacez le ecs-cwagent conteneur par $IMAGE la dernière balise d'image créée par cloudwatch-agent sur Amazon ECR.

    Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou ultérieure à1.300040.0.

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

  4. Mettez à jour les variables d'environnement Application Signals dans votre conteneur d'applications en suivant les instructions deÉ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. Suivez les instructions Téléchargez le package de CloudWatch l'agent et mettez à niveau l' CloudWatch agent vers la dernière version. Assurez-vous de sélectionner la version 1.300040.0 ou une version ultérieure.

  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 effectuez une mise à niveau vers une version fixe, veillez à choisir 1.32.2 une version ultérieure.

    • Pour Python, utilisez aws-otel-python-instrumentation .

      Si vous effectuez une mise à niveau vers une version fixe, veillez à choisir 0.2.0 une version ultérieure.

    • Pour .NET, utilisez aws-otel-dotnet-instrumentation.

      Si vous effectuez une mise à niveau vers une version fixe, veillez à choisir 1.3.2 une version ultérieure.

    • Pour Node.js, utilisez aws-otel-js-instrumentation.

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

  3. Appliquez les variables d'environnement Application Signals mises à jour à votre application, puis démarrez-la. Pour de plus amples informations, veuillez consulter Étape 3 : instrumenter votre application et la démarrer.