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.
# Surveillez l’état de fonctionnement de vos applications avec Application Signals
Utilisez les signaux d'application dans la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/) pour surveiller et résoudre les problèmes liés à l'état de fonctionnement de vos applications :
+ **Surveillez les services de votre application** : dans le cadre de la surveillance opérationnelle quotidienne, utilisez la page [Services](Services-page.md) pour consulter un résumé de tous vos services. Identifiez les services présentant le taux de défaillance ou le temps de latence le plus élevé, et identifiez les services présentant des [indicateurs de niveau de service défaillants (SLIs)](CloudWatch-ServiceLevelObjectives.md). Sélectionnez un service pour ouvrir la page [Détails du service](ServiceDetail.md) et consulter les indicateurs détaillés, les opérations de service, les scripts canary Synthetics et les demandes des clients. Cela vous aide à résoudre les problèmes opérationnels et à identifier la cause première des problèmes opérationnels.
+ **Vérifier la topologie de votre application** : utilisez la [carte d’application](ServiceMap.md) pour comprendre et surveiller la topologie de votre application au fil du temps, y compris les relations entre les clients, les canaries Synthetics, les services et les dépendances. Consultez instantanément l’état de l’indicateur de niveau de service (SLI) et consultez les indicateurs clés tels que le volume d’appels, le taux d’erreur et la latence. Accédez à des informations plus détaillées sur la page [Détails du service](ServiceDetail.md).
Découvrez un [exemple de scénario](Services-example-scenario.md) qui montre comment ces pages peuvent être utilisées pour résoudre rapidement un problème de santé d’un service opérationnel, de la détection initiale à l’identification de la cause première.
**Comment Application Signals permettent de surveiller l’état de fonctionnement des opérations**
Une fois que vous avez [activé votre](CloudWatch-Application-Signals-Enable.md) application pour les signaux d'application APIs, les services de votre application et leurs dépendances sont automatiquement découverts et affichés dans les pages **Services**, **Détails du service** et **Carte des applications**. Application Signals collecte des informations provenant de sources multiples pour permettre la découverte de services et la surveillance de l’état de fonctionnement :
+ [AWS Distro for OpenTelemetry (ADOT)](CloudWatch-Application-Signals-supportmatrix.md) — Dans le cadre de l'activation des signaux d'application, les bibliothèques d'auto-instrumentation OpenTelemetry Java et Python sont configurées pour émettre des métriques et des traces collectées par l'agent. CloudWatch Les métriques et les suivis sont utilisés pour permettre la découverte des services, des opérations, des dépendances et d’autres informations sur les services.
+ [Objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md) — Une fois que vous avez créé des objectifs de niveau de service pour vos services, les pages Services, Détails du service et Carte des applications affichent l'état de l'indicateur de niveau de service (SLI). SLIs peut surveiller la latence, la disponibilité et d'autres indicateurs opérationnels.
+ CloudWatch Canaris [synthétiques —](CloudWatch_Synthetics_Canaries.md) Lorsque vous configurez le suivi par rayons X sur vos canaris, les appels adressés à vos services depuis vos scripts Canary sont associés à votre service et affichés sur la page détaillée du service.
+ [CloudWatch Surveillance des utilisateurs réels (RUM)](CloudWatch-RUM.md) — Lorsque le suivi X-Ray est activé sur votre client Web CloudWatch RUM, les demandes adressées à vos services sont automatiquement associées et affichées sur la page détaillée du service.
+ [AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html)— Application Signals découvre automatiquement AWS les ressources de votre compte et vous permet de les regrouper dans des applications logiques créées dans AppRegistry. Le nom de l’application affiché sur la page Services est basé sur la ressource de calcul sous-jacente sur laquelle vos services s’exécutent.
**Note**
Application Signals affiche vos services et opérations en fonction des métriques et des suivis émis dans le filtre temporel actuel que vous avez choisi. (Par défaut, il s’agit des trois dernières heures.) S’il n’y a aucune activité dans le filtre temporel actuel pour un service, une opération, une dépendance, un script Canary Synthetics ou une page client, elle ne sera pas affichée.
Jusqu’à 1 000 services peuvent être affichés. La découverte de vos services et de leur topologie peut être retardée de 10 minutes maximum. L’évaluation de l’état de votre indicateur de niveau de service (SLI) peut être retardée jusqu’à 15 minutes.
**Note**
La console de la vigie applicative ne permet actuellement de sélectionner qu’un seul jour dans la plage de 30 jours.
# Affichage de l’activité globale des services et de l’état de fonctionnement sur la page Services
Utilisez la page Services pour voir la liste de vos services qui sont [activés pour Application Signals](CloudWatch-Application-Signals-Enable.md). Vous pouvez également consulter les indicateurs opérationnels et identifier rapidement les services présentant des indicateurs de niveau de service défaillants (SLIs). Analysez les anomalies de performance à mesure que vous identifiez la cause première des problèmes opérationnels. Pour afficher cette page, ouvrez la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/) et choisissez **Services** dans la section **Signaux d'application** dans le volet de navigation de gauche.
Pour les services non instrumentés, la page de présentation des services affiche des informations limitées, mises en évidence calls-to-action pour permettre l'instrumentation des signaux d'application.
## Explorez les indicateurs d’état de fonctionnement de vos services
La partie supérieure de la page Services comprend un graphique global sur l’état de fonctionnement des services et plusieurs tableaux affichant les principaux services et les dépendances entre services par taux de défaillance et liste de services. Le graphique des services sur la gauche affiche une ventilation du nombre de services présentant des indicateurs de niveau de service sains ou malsains (SLIs) pendant le filtre temporel actuel au niveau de la page. SLIs peut surveiller la latence, la disponibilité et d'autres indicateurs opérationnels. Consultez les principaux services par taux de défaillance dans les deux tableaux situés à côté du graphique. Sélectionnez un nom de service dans l’un des tableaux pour ouvrir sa [page de détails](ServiceDetail.md), qui affiche des informations détaillées sur le fonctionnement du service. Sélectionnez un chemin de dépendance pour afficher les détails de la dépendance du service sur sa page de détails.
Les deux tableaux affichent des informations relatives aux trois dernières heures, même si un filtre de période plus longue est sélectionné en haut à droite de la page.
Lorsque vous utilisez le regroupement dynamique des services, les métriques d’état de fonctionnement agrègent automatiquement les données de tous les services au sein de chaque groupe. Cela permet d’obtenir :
+ Les taux de défaillance consolidés pour les groupes de services
+ L’état de SLI au niveau du groupe
+ Les mesures de performance agrégées qui aident à identifier les clusters de services problématiques
+ L’identification rapide des groupes qui nécessitent une attention immédiate en cas d’incident
![\[CloudWatch Principaux graphiques des services\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/services-top-graphs.png)
## Surveillez l’état de fonctionnement à l’aide du tableau Services
Le tableau Services affiche la liste de vos services qui ont été activés pour Application Signals. Choisissez **Activer Application Signals** pour ouvrir une page de configuration et commencer à configurer vos services. Pour plus d’informations, veuillez consulter la rubrique [Activer Application Signals](CloudWatch-Application-Signals-Enable.md).
Filtrez le tableau Services pour faciliter la recherche en sélectionnant une ou plusieurs propriétés dans la zone de texte du filtre. Au fur et à mesure que vous choisissez chaque propriété, vous êtes guidé à travers les critères de filtrage. Vous verrez le filtre complet sous la zone de texte du filtre. Choisissez **Effacer les filtres** à tout moment pour supprimer le filtre du tableau.
Les options de filtrage avancées vous permettent de :
+ Filtrer par groupes de services (regroupements par défaut et personnalisés)
+ Filtrer par activité de déploiement récente
+ Filtrer par plateforme
+ Filtrer par SLI Health
+ Filtrer par ID de compte (dans les configurations d'observabilité entre comptes)
+ Filtrer par état de l'instrumentation (instrumenté ou non instrumenté)
+ Filter par environnement
+ Filtrer par état du service
![\[CloudWatch Tableau des services\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/services-table-healthy-updated.png)
Pour les services non instrumentés, la page de présentation des services affiche des informations limitées, mises en évidence calls-to-action pour permettre l'instrumentation des signaux d'application. Les services non instrumentés apparaissent dans le tableau des services même s'ils n'ont pas été configurés avec des signaux d'application, ce qui vous aide à identifier les lacunes dans votre couverture d'observabilité et à hiérarchiser les services à instrumenter ensuite en fonction de leur position dans votre architecture.
Choisissez le nom de n’importe quel service dans le tableau pour afficher une [page de détails du service](ServiceDetail.md) contenant des métriques de niveau de service, des opérations et des détails supplémentaires. Si vous avez associé la ressource de calcul sous-jacente du service à une application dans AppRegistry ou dans la carte Applications de la page d' AWS Management Console accueil, choisissez le nom de l'application pour afficher les détails de l'application sur la page de console [MyApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html). Pour les services hébergés dans Amazon EKS, choisissez n'importe quel lien dans la colonne **Hébergé dans** pour afficher le cluster, l'espace de noms ou la charge de travail dans CloudWatch Container Insights. Pour les services exécutés sur Amazon ECS ou Amazon EC2, la valeur de l'environnement est affichée.
L’état de l’[Indicateur de niveau de service (SLI)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-concepts) est affiché pour chaque service dans le tableau. Choisissez l'état SLI d'un service pour afficher une fenêtre contextuelle contenant un lien vers tout service défectueux SLIs et un lien SLOs pour afficher tout ce qui concerne le service.
![\[Services avec des SLI non sains\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/services-unhealthy-sli.png)
Si aucun service SLOs n'a été créé, cliquez sur le bouton **Create SLO** dans la colonne **SLI Status**. Pour créer des options supplémentaires SLOs pour n'importe quel service, sélectionnez le bouton d'option à côté du nom du service, puis choisissez **Create SLO** en haut à droite du tableau. Lorsque vous créez SLOs, vous pouvez voir en un coup d'œil quels services et opérations fonctionnent bien et lesquels ne le sont pas. Voir les [objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md) pour plus d'informations.
## Aperçu du service
Une fois que vous avez sélectionné un service dans le tableau Services, la page d'aperçu des services s'ouvre. Cette page fournit une vue complète de la santé opérationnelle et des indicateurs de performance de votre service. La vue d'ensemble affiche les mesures récapitulatives suivantes :
+ Nombre total d’opérations
+ Dépendances des services
+ État de surveillance de Canary
+ Données du client RUM
Ces indicateurs vous donnent un aperçu immédiat de l'état actuel de votre service.
Vous pouvez visualiser les indicateurs clés de performance opérationnelle au fil du temps à l'aide d'une série de graphiques. Pour analyser les tendances et identifier les problèmes potentiels affectant l'état de santé de votre service, ajustez le filtre temporel. Tous les graphiques sont automatiquement mis à jour pour refléter les données de la période sélectionnée.
La section Résultats de l'audit détecte et affiche automatiquement les problèmes critiques liés au comportement de votre service. Vous n'avez donc pas besoin de les examiner manuellement. Application Signals analyse vos applications pour signaler les observations importantes et les problèmes potentiels, simplifiant ainsi l'analyse des causes profondes. Ces résultats automatisés consolident les traces pertinentes, éliminant ainsi le besoin de naviguer en plusieurs clics. Le système d'audit aide les équipes à identifier rapidement les problèmes et leurs causes sous-jacentes, permettant ainsi une résolution plus rapide des problèmes.
Vous pouvez utiliser la section Événements de modification pour identifier la manière dont les récents déploiements ou modifications de configuration affectent le comportement de votre service. Application Signals traite automatiquement les CloudTrail événements pour suivre les événements de changement dans l'ensemble de votre application. Surveillez les événements de configuration et de déploiement des services et de leurs dépendances, en fournissant un contexte immédiat pour l'analyse opérationnelle et le dépannage. La vigie applicative établit automatiquement une corrélation entre les délais de déploiement et les changements de performances, vous permettant ainsi d’identifier rapidement si les déploiements récents ont contribué à des problèmes de service.
![\[Aperçu du service\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/Service_detail.png)
# Afficher l’activité détaillée du service et l’état opérationnel à l’aide de la page de détails du service
Lorsque vous instrumentez votre application, [Amazon CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) cartographie tous les services découverts par votre application. Utilisez la page de détails du service pour obtenir une vue d’ensemble de vos services, opérations, dépendances, canaries et requêtes client pour un service unique. Pour afficher la page de détails du service, procédez comme suit :
+ Ouvrez la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/).
+ Sélectionnez **Services** dans la section **Vigie applicative CloudWatch** du volet de navigation.
+ Sélectionnez le nom d’un service dans **Services**, **Principaux services** ou les tableaux de dépendances.
Sous **schedule-visits**, vous verrez le libellé et l’ID de compte sous le nom du service.
La page de détails du service est organisée en plusieurs onglets :
+ [Vue d’ensemble](#ServiceDetail-overview) : utilisez cet onglet pour obtenir une vue d’ensemble d’un service unique, y compris le nombre d’opérations, de dépendances, de synthétiques et de pages client. Cet onglet affiche les métriques clés pour l’ensemble de votre service, les opérations principales et les dépendances. Ces métriques comprennent des données de séries temporelles sur la latence, les défaillances et les erreurs pour toutes les opérations de service de ce service.
+ [Opérations de service](#ServiceDetail-operations) : utilisez cet onglet pour afficher la liste des opérations appelées par votre service et des graphiques interactifs avec les métriques clés qui évaluent l’état de chaque opération. Vous pouvez sélectionner un point de données dans un graphique pour obtenir des informations sur les traces, les journaux ou les métriques associées à ce point de données.
+ [Dépendances](#ServiceDetail-dependencies) : utilisez cet onglet pour afficher la liste des dépendances appelées par votre service, ainsi que la liste des indicateurs pour ces dépendances.
+ [Canaries synthétiques](#ServiceDetail-canaries) : utilisez cet onglet pour afficher la liste des canaries synthétiques qui simulent les appels des utilisateurs vers votre service, ainsi que les indicateurs de performance clés pour ces canaries.
+ [Pages client](#ServiceDetail-clientpages) : utilisez cet onglet pour afficher la liste des pages client qui appellent votre service, ainsi que les métriques qui mesurent la qualité des interactions des clients avec votre application.
+ [Métriques associées](#ServiceDetail-relatedmetrics) : utilisez cet onglet pour corréler les métriques associées, telles que les métriques standard, les métriques d’exécution et les métriques personnalisées pour un service, ses opérations ou ses dépendances.
## Afficher la vue d’ensemble de votre service
Utilisez la page de vue d’ensemble du service pour afficher un résumé général des métriques de toutes les opérations du service en un seul endroit. Vérifiez les performances de toutes les opérations, dépendances, pages client et canaries synthétiques qui interagissent avec votre application. Utilisez ces informations pour déterminer où concentrer vos efforts afin d’identifier les problèmes, de résoudre les erreurs et de trouver des opportunités d’optimisation.
Sélectionnez n’importe quel lien dans **Détails du service** pour afficher les informations relatives à un service spécifique. Par exemple, pour les services hébergés dans Amazon EKS, la page de détails du service affiche les informations relatives au **Cluster**, à l’**Espace de noms** et à la **Charge de travail**. Pour les services hébergés dans Amazon ECS ou Amazon EC2, la page Détails du service affiche la valeur **Environnement**.
Sous **Services**, l’onglet **Vue d’ensemble** affiche un résumé des éléments suivants :
+ Opérations : utilisez cet onglet pour voir l’état de santé de vos opérations de service. L’état de santé est déterminé par des indicateurs de niveau de service (SLI) définis dans le cadre d’un [objectif de niveau de service](CloudWatch-ServiceLevelObjectives.md) (SLO).
+ Dépendances : utilisez cet onglet pour consulter les principales dépendances des services appelés par votre application, classées par taux de défaillance, et pour vérifier l’état de santé de vos dépendances de service. L’état de santé est déterminé par des indicateurs de niveau de service (SLI) définis dans le cadre d’un objectif de niveau de service (SLO).
+ Canaris synthétiques : utilisez cet onglet pour voir le résultat d'appels simulés vers des terminaux APIs ou associés à votre service, ainsi que le nombre de canaris ayant échoué.
+ Pages client : utilisez cet onglet pour voir les principales pages appelées par des clients présentant des erreurs asynchrones JavaScript et XML (AJAX).
L’illustration suivante présente une vue d’ensemble de vos services :
![\[Widgets de vue d’ensemble des services\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-detail-widgets.png)
L’onglet **Vue d’ensemble** affiche également un graphique des dépendances présentant la latence la plus élevée parmi tous les services. Utilisez les métriques de latence **p99**, **p90** et **p50** pour évaluer rapidement quelles dépendances contribuent à la latence totale de votre service, comme suit :
![\[Graphique de latence des opérations de service\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-detail-latency.png)
Par exemple, le graphique précédent montre que 99 % des requêtes adressées à la dépendance **customer-service** ont été traitées en environ 4 950 millisecondes. Les autres dépendances ont pris moins de temps.
Les graphiques affichant les quatre principales opérations de service par latence indiquent le volume de requêtes, la disponibilité, le taux de défaillance et le taux d’erreur pour ces services, comme illustré dans l’image suivante :
![\[Graphiques du volume, de la disponibilité, du taux de défaillance et du taux d’erreur des opérations de service\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-detail-operations-graphs.png)
La section **Détails du service** affiche les détails du service, y compris l’**ID de compte** et le **Libellé du compte**.
## Affichage de vos opérations de service
Lorsque vous instrumentalisez votre application, la [vigie applicative](CloudWatch-Application-Monitoring-Sections.md) détecte toutes les opérations de service appelées par votre application. Utilisez l’onglet **Opérations de service** pour afficher un tableau contenant les opérations de service et un ensemble de métriques qui mesurent les performances d’une opération sélectionnée. Ces métriques comprennent le statut SLI, le nombre de dépendances, la latence, le volume, les défaillances, les erreurs et la disponibilité, comme illustré dans l’image suivante :
![\[Tableau Opérations de service\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-operations-table.png)
Filtrez le tableau pour faciliter la recherche d’une opération de service en sélectionnant une ou plusieurs propriétés dans la zone de texte du filtre. Au fur et à mesure que vous choisissez chaque propriété, vous êtes guidé à travers les critères de filtrage et vous verrez le filtre complet sous la zone de texte du filtre. Choisissez **Effacer les filtres** à tout moment pour supprimer le filtre du tableau.
Choisissez l'état SLI d'une opération pour afficher une fenêtre contextuelle contenant un lien vers tout SLI défectueux, ainsi qu'un lien SLOs permettant de voir tous les détails de l'opération, comme indiqué dans le tableau suivant :
![\[État du SLI d’une opération de service\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-operation-unhealthy-slo.png)
Le tableau des opérations de service répertorie l'état du SLI, le nombre d'opérations saines ou non saines SLIs et le nombre total de opérations SLOs pour chaque opération.
SLIs Utilisez-le pour surveiller la latence, la disponibilité et d'autres indicateurs opérationnels qui mesurent la santé opérationnelle d'un service. Utilisez un SLO pour vérifier les performances et l’état de vos services et opérations.
Pour créer un SLO, procédez comme suit :
+ Si une opération ne dispose pas d’un SLO, sélectionnez le bouton **Créer un SLO** dans la colonne **Statut SLI**.
+ Si une opération dispose déjà d’un SLO, procédez comme suit :
+ Sélectionnez le bouton radio à côté du nom de l’opération.
+ Sélectionnez **Créer un SLO** dans la liste déroulante **Actions** en haut à droite du tableau.
Pour plus d'informations, consultez les [objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md).
La colonne **Dépendances** indique le nombre de dépendances appelées par cette opération. Choisissez ce numéro pour ouvrir l’onglet **Dépendances** filtré en fonction de l’opération sélectionnée.
### Afficher les métriques des opérations de service, les traces corrélées et les journaux d’application
Application Signals met en corrélation les indicateurs de fonctionnement des services avec les AWS X-Ray traces, CloudWatch [Container Insights](ContainerInsights.md) et les journaux des applications. Utilisez ces métriques pour résoudre les problèmes d’état opérationnels. Pour afficher les métriques sous forme d’informations graphiques, procédez comme suit :
1. Sélectionnez une opération de service dans le tableau **Opérations de service** pour afficher un ensemble de graphiques pour l’opération sélectionnée au-dessus du tableau avec les métriques pour le **Volume et la disponibilité**, la **Latence** et les **Défaillances et erreurs**.
1. Passez la souris sur un point du graphique pour afficher plus d’informations.
1. Sélectionnez un point pour ouvrir un volet de diagnostic qui affiche les traces, les métriques et les journaux d’application corrélés pour le point sélectionné dans le graphique.
L’image suivante montre l’info-bulle qui apparaît lorsque vous survolez un point du graphique et le volet de diagnostic qui apparaît lorsque vous cliquez sur un point. L’info-bulle contient des informations sur le point de données associé dans le graphique **Défaillances et erreurs**. Le volet contient les **Traces corrélées**, les **Principaux contributeurs** et les **Journaux d’application** associés au point sélectionné.
![\[Traces corrélées pour les défaillances et les erreurs\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-detail-correlated-traces.png)
#### Suivis corrélés
Consultez les traces associées pour comprendre un problème sous-jacent à une trace. Vous pouvez vérifier si les traces corrélées ou les nœuds de service qui leur sont associés se comportent de manière similaire. Pour examiner les traces corrélées, sélectionnez un **ID de trace** dans le tableau **Traces corrélées** afin d’ouvrir la page [Détails de la trace X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html) pour la trace choisie. La page des détails de la trace contient une carte des nœuds de service associés à la trace sélectionnée et une chronologie des segments de trace.
#### Principaux contributeurs
Affichez les principaux contributeurs pour trouver les principales sources d’entrée d’une métrique. Regroupez les contributeurs par composants différents pour rechercher des similitudes au sein du groupe et comprendre comment le comportement des traces diffère entre eux.
L’onglet **Principaux contributeurs** fournit des métriques pour le **Volume d’appels**, la **Disponibilité**, la **Latence moyenne**, les **Erreurs** et les **Défaillances** pour chaque groupe. L’image suivante montre les principaux contributeurs à un ensemble de métriques pour une application déployée sur une plateforme Amazon EKS :
![\[Principaux contributeurs de l’opération de service\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors.png)
Les principaux contributeurs comprennent les métriques suivantes :
+ **Volume d’appels** : utilisez le volume d’appels pour comprendre le nombre de requêtes par intervalle de temps pour un groupe.
+ **Disponibilité** : utilisez la disponibilité pour voir le pourcentage de temps pendant lequel aucune défaillance n’a été détectée pour un groupe.
+ **Latence moyenne** : utilisez la latence pour vérifier le temps moyen d’exécution des requêtes pour un groupe sur un intervalle de temps qui dépend de la date à laquelle les requêtes que vous examinez ont été effectuées. Les requêtes effectuées il y a moins de 15 jours sont évaluées par intervalles d’une minute. Les requêtes effectuées entre 15 et 30 jours auparavant, inclusivement, sont évaluées par intervalles de 5 minutes. Par exemple, si vous examinez les requêtes qui ont causé une défaillance il y a 15 jours, la métrique du volume d’appels est égale au nombre de requêtes par intervalle de 5 minutes.
+ **Erreurs** : nombre d’erreurs par groupe mesuré sur un intervalle de temps.
+ **Défaillances** : nombre de défaillances par groupe sur un intervalle de temps.
**Principaux contributeurs utilisant Amazon EKS ou Kubernetes**
Utilisez les informations sur les principaux contributeurs aux applications déployées sur Amazon EKS ou Kubernetes pour consulter les indicateurs de santé opérationnelle regroupés par **nœud**, **pod** et **PodTemplateHash**. Les définitions suivantes s’appliquent :
+ Un **pod** est un groupe d’un ou plusieurs conteneurs Docker qui partagent du stockage et des ressources. Un pod est la plus petite unité pouvant être déployée sur une plateforme Kubernetes. Regroupez par pods pour vérifier si les erreurs sont liées à des limitations spécifiques aux pods.
+ Un **nœud** est un serveur qui exécute des pods. Regroupez par nœuds pour vérifier si les erreurs sont liées à des limitations spécifiques aux nœuds.
+ Un **hachage de modèle de pod** est utilisé pour trouver une version particulière d’un déploiement. Regroupez par hachage de modèle de pod pour vérifier si les erreurs sont liées à un déploiement particulier.
**Principaux contributeurs utilisant Amazon EC2**
Utilisez les informations sur les principaux contributeurs pour les applications déployées sur Amazon EKS afin de consulter les métriques de santé opérationnelle regroupées par ID d’instance et groupe Auto Scaling. Les définitions suivantes s’appliquent :
+ Un **ID d’instance** est un identifiant unique pour l’instance Amazon EC2 sur laquelle votre service s’exécute. Regroupez par ID d’instance pour vérifier si les erreurs sont liées à une instance Amazon EC2 spécifique.
+ Un [groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) est un ensemble d’instances Amazon EC2 qui vous permet d’augmenter ou de réduire les ressources dont vous avez besoin pour répondre aux requêtes de votre application. Regroupez par groupe Auto Scaling si vous voulez vérifier si les erreurs sont limitées aux instances du groupe.
**Principaux contributeurs utilisant une plateforme personnalisée**
Utilisez les informations sur les principaux contributeurs pour les applications déployées à l’aide d’instruments personnalisés afin de consulter les métriques d’état opérationnelles regroupées par **Nom d’hôte**. Les définitions suivantes s’appliquent :
+ Un nom d’hôte identifie un appareil tel qu’un point de terminaison ou une instance Amazon EC2 connecté à un réseau. Regroupez par nom d’hôte pour vérifier si vos erreurs sont liées à un appareil physique ou virtuel spécifique.
**Afficher les principaux contributeurs dans Log Insights et Container Insights**
Affichez et modifiez la requête automatique qui a généré les métriques pour vos principaux contributeurs dans [Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html). Affichez les métriques de performances de l’infrastructure par groupes spécifiques tels que les pods ou les nœuds dans [Container Insights](ContainerInsights.md). Vous pouvez trier les clusters, les nœuds ou les charges de travail par consommation de ressources et identifier rapidement les anomalies ou atténuer les risques de manière proactive avant que l’expérience de l’utilisateur final ne soit affectée. Une image illustrant la manière de sélectionner ces options est fournie ci-dessous :
![\[Table des principaux contributeurs\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors-insights.png)
Dans **Informations sur le conteneur**, vous pouvez afficher les métriques de votre conteneur Amazon EKS ou Amazon ECS qui sont spécifiques au regroupement de vos principaux contributeurs. Par exemple, si vous avez regroupé par pod pour un conteneur EKS afin de générer les principaux contributeurs, Container Insights affichera les métriques et les statistiques filtrées pour votre pod.
Dans **Informations sur le journal**, vous pouvez modifier la requête qui a généré les métriques sous **Principaux contributeurs** en suivant les étapes suivantes :
1. Sélectionnez **Afficher dans Log Insights**. La page **Informations sur le journal** qui s’ouvre contient une requête générée automatiquement et comprend les informations suivantes :
+ Le nom du groupe de cluster de journaux.
+ L'opération sur laquelle vous enquêtiez CloudWatch.
+ L’agrégat de la métrique d’état opérationnelle avec laquelle vous avez interagi sur le graphique.
Les résultats du journal sont automatiquement filtrés pour afficher les données des cinq dernières minutes avant que vous n’ayez sélectionné le point de données sur le graphique du service.
1. Pour modifier la requête, remplacez le texte généré par vos modifications. Vous pouvez également utiliser le **Générateur de requêtes** pour vous aider à générer une nouvelle requête ou à mettre à jour la requête existante.
#### Journaux d'application
Utilisez la requête dans l’onglet **Journaux d’application** pour générer des informations enregistrées pour votre groupe de journaux, votre service actuel et insérer un horodatage. Un groupe de journaux est un ensemble de flux de journaux que vous pouvez définir lors de la configuration de votre application.
Utilisez un groupe de journaux pour organiser les journaux présentant des caractéristiques similaires, notamment les suivantes :
+ Capturez les journaux d’une organisation, d’une source ou d’une fonction spécifique.
+ Capturer les journaux auxquels un utilisateur particulier a accès.
+ Capturez les journaux pour une période spécifique.
Utilisez ces flux de journaux pour suivre des groupes ou des périodes spécifiques. Vous pouvez également configurer des règles de surveillance, des alarmes et des notifications pour ces groupes de journaux. Pour plus d’informations sur les groupes de journaux, consultez [Utilisation des groupes de journaux et des flux de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html).
La requête des journaux d’application renvoie les journaux, les modèles de texte récurrents et les visualisations graphiques pour vos groupes de journaux.
Pour exécuter la requête, sélectionnez **Exécuter la requête dans Logs Insights** afin d’exécuter la requête générée automatiquement ou de la modifier. Pour modifier la requête, remplacez le texte généré automatiquement par vos modifications. Vous pouvez également utiliser le **Générateur de requêtes** pour vous aider à générer une nouvelle requête ou à mettre à jour la requête existante.
L’image suivante montre l’exemple de requête générée automatiquement en fonction du point sélectionné dans le graphique des opérations du service :
![\[Table des journaux d’application\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-operations-application-logs.png)
Dans l'image précédente, CloudWatch a automatiquement détecté le groupe de log associé au point sélectionné et l'a inclus dans une requête générée.
## Affichage de vos dépendances de service
Choisissez l’onglet **Dépendances** pour afficher le tableau **Dépendances** et un ensemble de métriques relatives aux dépendances de toutes les opérations de service ou d’une seule opération. Le tableau contient une liste des dépendances détectées par la vigie applicative, y compris les métriques relatives au statut SLI, à la latence, au volume d’appels, au taux de défaillance, au taux d’erreur et à la disponibilité.
En haut de la page, sélectionnez une opération dans la liste déroulante pour afficher ses dépendances, ou sélectionnez **Tout** pour afficher les dépendances de toutes les opérations.
Filtrez le tableau pour faciliter la recherche de ce que vous recherchez en choisissant une ou plusieurs propriétés dans la zone de texte du filtre. Au fur et à mesure que vous choisissez chaque propriété, vous êtes guidé à travers les critères de filtrage et vous verrez le filtre complet sous la zone de texte du filtre. Choisissez **Effacer les filtres** à tout moment pour supprimer le filtre du tableau. Sélectionnez **Grouper par dépendance** en haut à droite du tableau pour regrouper les dépendances par nom de service et d’opération. Lorsque le regroupement est activé, développez ou réduisez un groupe de dépendances à l’aide de l’icône **\$1** à côté du nom de la dépendance.
![\[Tableau des dépendances\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-dependencies-table.png)
La colonne **Dépendance** affiche le nom du service de dépendance, tandis que la colonne **Opération à distance** affiche le nom de l’opération de service. La colonne d'**état du SLI** affiche le nombre de personnes saines ou non saines SLIs ainsi que le nombre total de personnes SLIs pour chaque dépendance. Lorsque vous appelez AWS des services, la colonne **Target** affiche la AWS ressource, telle que la table DynamoDB ou la file d'attente Amazon SNS.
Pour sélectionner une dépendance, sélectionnez l’option située à côté d’une dépendance dans le tableau **Dépendances**. Cela affiche un ensemble de graphiques qui présentent des métriques détaillées pour le volume d’appels, la disponibilité, les défaillances et les erreurs. Survolez un point d’un graphique pour afficher une fenêtre contextuelle contenant plus d’informations. Sélectionnez un point dans un graphique pour ouvrir un volet de diagnostic qui affiche les traces corrélées pour le point sélectionné dans le graphique. Sélectionnez un ID de trace dans le tableau **Traces corrélées** pour ouvrir la page [Détails de la trace X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html) pour la trace sélectionnée.
![\[Graphiques de dépendance et suivis corrélés\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-dependency-graph-traces.jpg)
## Affichage de vos scripts canary Synthetics
Choisissez l’onglet **Scripts canary Synthetics** pour afficher le tableau **Scripts canary Synthetics** et un ensemble de métriques pour chaque script canary du tableau. Le tableau inclut des mesures relatives au pourcentage de réussite, à la durée moyenne, aux cycles et au taux d’échec. Seuls les canaris dont le [AWS X-Ray traçage est activé](CloudWatch_Synthetics_Canaries_tracing.md) sont affichés.
Utilisez la zone de texte du filtre dans le tableau des canaris synthétiques pour trouver le canary qui vous intéresse. Chaque filtre que vous créez apparaît sous la zone de texte du filtre. Choisissez **Effacer les filtres** à tout moment pour supprimer le filtre du tableau.
![\[Tableau des scripts canary Synthetics\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-canaries-table.png)
Cochez la case d’option à côté du nom du canary pour afficher un ensemble d’onglets contenant des graphiques avec des mesures détaillées, notamment le pourcentage de réussite, les erreurs et la durée. Survolez un point d’un graphique pour afficher une fenêtre contextuelle contenant plus d’informations. Sélectionnez un point dans un graphique pour ouvrir un volet de diagnostic qui affiche les exécutions de canary corrélées au point sélectionné. Sélectionnez une exécution de canary et choisissez la **Durée d’exécution** pour afficher les artefacts de l’exécution de canary sélectionnée, notamment les journaux, les fichiers d’archive HTTP (HAR), les captures d’écran et les suggestions pour vous aider à résoudre les problèmes. **Choisissez **En savoir plus** pour ouvrir la page [CloudWatch Synthetics](CloudWatch_Synthetics_Canaries.md) Canaries à côté de Canary runs.**
![\[Graphiques et exécutions Synthetics Canary\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-canary-graphs-runs.jpg)
## Consultation de vos pages clients
Sélectionnez l’onglet **Pages client** pour afficher la liste des pages Web client qui appellent votre service. Utilisez l’ensemble de métriques pour la page client sélectionnée afin d’évaluer la qualité de l’expérience de votre client lorsqu’il interagit avec un service ou une application. Ces métriques comprennent les chargements de pages, les indicateurs Web vitaux et les erreurs.
Pour afficher vos pages client dans le tableau, vous devez [configurer votre client Web CloudWatch RUM pour le suivi X-Ray](CloudWatch-RUM-get-started-create-app-monitor.md) et activer les métriques Application Signals pour vos pages client. Sélectionnez **Gérer les pages** pour choisir les pages activées pour les métriques de la vigie applicative.
Utilisez la zone de texte du filtre pour rechercher la page client ou le moniteur d’application qui vous intéresse sous la zone de texte du filtre. Sélectionnez **Effacer les filtres** pour supprimer le filtre du tableau. Sélectionnez **Grouper par client** pour regrouper les pages client par client. Lorsque vous êtes groupés, cliquez sur l’icône **\$1** à côté du nom d’un client pour développer la ligne et afficher toutes les pages relatives à ce client.
![\[Tableau des pages client\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-client-pages-table.png)
Pour sélectionner une page client, sélectionnez l’option située à côté d’une page client dans le tableau **Pages client**. Vous verrez un ensemble de graphiques affichant des métriques détaillées. Survolez un point d’un graphique pour afficher une fenêtre contextuelle contenant plus d’informations. Sélectionnez un point dans un graphique pour ouvrir un volet de diagnostic qui affiche les événements de navigation de performances corrélés pour le point sélectionné dans le graphique. Choisissez un identifiant d'événement dans la liste des événements de navigation pour ouvrir la [vue de la page CloudWatch RUM](CloudWatch-RUM-view-data.md) pour l'événement choisi.
![\[CloudWatch Demandes de page client RUM\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-client-page-graphs-events.jpg)
**Note**
Pour voir les erreurs AJAX dans vos pages client, utilisez le [client Web CloudWatch RUM](CloudWatch-RUM-configure-client.md) version 1.15 ou ultérieure.
Jusqu’à 100 opérations, canaries et pages client, ainsi que jusqu’à 250 dépendances, peuvent être affichés par service.
## Afficher les métriques associées
Utilisez l’onglet Métriques associées pour visualiser plusieurs métriques, identifier des modèles de corrélation et déterminer une cause racine des problèmes.
Le tableau des métriques affiche trois types de métriques :
+ Métriques standard : la vigie applicative collecte les métriques d’application standard à partir des services qu’il détecte. Pour plus d’informations, consultez [Métriques d’application standard collectées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html#AppSignals-StandardMetrics)
+ Métriques d'exécution — Application Signals utilise le OpenTelemetry SDK AWS Distro for pour collecter automatiquement des métriques OpenTelemetry compatibles à partir de vos applications Java et Python. Pour plus d’informations, consultez [Métriques d’exécution](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html#AppSignals-RuntimeMetrics)
+ Métriques personnalisées : la vigie applicative vous permet de générer des métriques personnalisées à partir de votre application. Pour de plus amples informations, consultez [Métriques personnalisées avec la vigie applicative](AppSignals-CustomMetrics.md).
Vous pouvez accéder à l’onglet Métriques associées à partir des onglets Vue d’ensemble du service, Opérations du service, Dépendances, Canaries synthétiques ou RUM.
![\[Afficher les métriques associées\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/Custom_metrics.png)
+ Le volet de navigation de gauche s’ouvre avec toutes les opérations et dépendances désélectionnées
+ Le graphique affiche initialement la métrique de défaillance de l’opération présentant le taux de défaillance le plus élevé
Avant de commencer l’analyse de corrélation, assurez-vous que les points de données sont visibles dans Opérations du service ou Dépendances. Pour analyser les corrélations :
1. Ouvrez la page Opérations du service ou Dépendances.
1. Sélectionnez un point de données sur n’importe quel graphique.
1. Dans le volet de droite, choisissez **Corrélation avec d’autres métriques**.
1. Dans l’onglet **Métriques associées** qui s’ouvre, vous verrez :
+ L’opération ou la dépendance que vous avez sélectionnée dans le volet de navigation gauche
+ La métrique que vous avez sélectionnée représentée sous forme de graphique dans le tableau *Parcourir les métriques*
+ Les intervalles corrélés lorsque vous sélectionnez un point de données
Pour représenter plusieurs métriques sous forme de graphique, sélectionnez une ou plusieurs métriques dans la vue **Parcourir** de l’onglet **Métriques associées**. Choisissez **Métriques représentées graphiquement** pour afficher toutes les métriques représentées graphiquement.
Pour filtrer les métriques, utilisez les filtres du volet de gauche afin de vous concentrer sur des opérations ou des dépendances spécifiques, et utilisez la barre de filtrage de l’en-tête du tableau pour effectuer une recherche par nom, type ou autres attributs. Ces options de filtrage vous aident à détecter des modèles et à résoudre les problèmes plus efficacement.
Pour analyser en détail les métriques associées, sélectionnez un point de données dans l’onglet **Métriques associées**. Vous pouvez ensuite afficher :
+ Principaux contributeurs : analyse les statistiques en exécutant CloudWatch des requêtes Logs Insights. Ces requêtes traitent les enregistrements au format EMF (Enhanced Metrics Format) qui contiennent des attributs clés pour une analyse détaillée des éléments suivants :
+ Mesures de latence
+ Occurrence de défaillance
+ Métriques de disponibilité des services
Les métriques suivantes ne prennent pas en charge les principaux contributeurs :
+ Métriques OTEL
+ Métriques de portée côté serveur
Vous pouvez afficher les principaux contributeurs pour les métriques RED et les métriques de portée côté client.
+ Portées corrélées : la section Portées corrélées fonctionne de manière cohérente avec l’onglet Opérations de service. Pour vous aider à identifier les traces et les métriques associées, le mécanisme de corrélation fonctionne de la manière suivante :
+ Comparaison des noms de métriques avec les attributs de portée
+ Identification des modèles correspondants pendant la période sélectionnée
+ Affichage des informations de trace pertinentes
Pour analyser efficacement vos métriques et vos portées ensemble, vous devez comprendre comment les différents types de métriques sont corrélés. Voici les principales limitations :
+ Les métriques OTEL ne sont pas corrélées aux portées, car elles utilisent des systèmes de nommage indépendants
+ Pour corréler les métriques de portée côté serveur ou côté client avec les portées :
+ Inclure un champ Dimension de service dans votre configuration
+ Sans cette Dimension de service, vous ne pouvez pas corréler ces métriques avec les portées
+ Applications de journalisation : pour plus d’informations sur l’application de journalisation, consultez [Journaux d’application](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceDetail.html#ServiceDetail-operations)
# Consultez la topologie de votre application et surveillez l'état de fonctionnement grâce à la carte des CloudWatch applications
**Note**
Le plan de CloudWatch l'application remplace le plan des services. Pour afficher une carte de votre application basée sur AWS X-Ray des traces, ouvrez la [X-Ray Trace Map](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html). Choisissez **Trace Map** dans la section **X-Ray** du volet de navigation de gauche de la CloudWatch console.
Après avoir activé votre application pour la vigie applicative CloudWatch, la carte d’application affiche les nœuds représentant vos groupes. Vous pouvez ensuite explorer ces groupes pour afficher vos services et leurs dépendances. Utilisez la carte d’application pour afficher la topologie de vos clients d’application, de vos canaries synthétiques, de vos services et de leurs dépendances, et surveiller l’état de leurs services. Pour afficher la carte de l'application, ouvrez la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/) et choisissez **Application Map** dans la section **Application Signals** dans le volet de navigation de gauche.
Après avoir [activé votre application pour la vigie applicative](CloudWatch-Application-Signals-Enable.md), utilisez la carte d’application pour faciliter la surveillance de l’état de fonctionnement de votre application :
+ Visualisez les connexions entre les nœuds de client, de script canary, de service et de dépendance pour vous aider à comprendre la topologie et le flux d’exécution de votre application. Cela est particulièrement utile si vos opérateurs de services ne font pas partie de votre équipe de développement.
+ Découvrez quels services répondent ou non à vos [objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md). Lorsqu'un service ne répond pas à vos attentes SLOs, vous pouvez rapidement identifier si un service en aval ou une dépendance peut contribuer au problème ou avoir un impact sur plusieurs services en amont.
+ Sélectionnez un nœud de client individuel, de script canary synthetics, de service ou de dépendance pour voir les métriques associées. La page [Détails du service](ServiceDetail.md) affiche des informations plus détaillées sur les opérations, les dépendances, les canaries synthétiques et les pages client.
+ Filtrez et zoomez sur la carte d’application pour vous concentrer plus facilement sur une partie de la topologie de votre application ou pour afficher la carte dans son intégralité. Créez un filtre en choisissant une ou plusieurs propriétés dans la zone de texte du filtre. Au fur et à mesure que vous choisissez chaque propriété, vous êtes guidé à travers les critères de filtrage. Vous verrez le filtre complet sous la zone de texte du filtre. Choisissez **Effacer les filtres** à tout moment pour supprimer le filtre.
+ Surveillez les services de plusieurs AWS comptes sur une seule carte d'applications unifiée. Les services provenant de différents comptes sont clairement identifiés à l'aide des informations relatives aux comptes, ce qui permet une observabilité unifiée pour les applications distribuées.
+ Identifiez les services qui ne sont pas encore instrumentés dans votre application. Application Signals détecte et affiche automatiquement les services qui n'ont pas encore été instrumentés, ce qui vous permet d'obtenir une couverture d'observabilité complète. Les services non instrumentés sont visuellement distingués sur la carte pour vous aider à hiérarchiser les efforts d'instrumentation.
+ Regroupez et filtrez les services pour créer des vues personnalisées qui correspondent à vos flux de travail. Cette organisation vous aide à trouver et à accéder rapidement aux services que vous utilisez le plus fréquemment
+ Enregistrez vos vues filtrées et regroupées pour revenir rapidement aux configurations fréquemment utilisées
## Explorer la carte d’application
Lorsque vous consultez la carte d’application, celle-ci affiche par défaut les services regroupés par **Services associés**. Les services associés regroupent les services en fonction de leurs dépendances. Par exemple, si le service A appelle le service B, qui appelle le service C, ils sont regroupés sous le service A. Vous pouvez afficher l’état SLI, les métriques et le nombre de services pour tous les services de chaque groupe.
![\[CloudWatch carte des applications par défaut regroupée par services associés.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-overview.png)
Sélectionnez un onglet pour obtenir des informations sur l’exploration de chaque type de nœud et les connexions entre eux.
### Regroupement et filtrage dynamiques
Vous pouvez cliquer sur le menu déroulant **Regrouper par** pour utiliser différentes options de regroupement. Par défaut, la carte d’application propose deux regroupements :
+ **Services associés** : regroupe les services en fonction de leurs dépendances
+ **Environnement** : regroupe les services en fonction de leur environnement
Si vous voulez définir votre propre regroupement personnalisé, cliquez sur **Gérer les groupes** pour définir des groupes personnalisés, puis baliser vos services ou ajouter des attributs de ressource OTEL avec la clé de groupe.
**Note**
Pour activer le regroupement via les attributs de ressources OTEL, la version de l' CloudWatch agent doit être v1.300056.0 ou ultérieure.
![\[Créer un panneau de regroupement personnalisé\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-create-custom-grouping.png)
Le regroupement par défaut dans la vigie applicative organise automatiquement les services en fonction de leurs dépendances en aval. Le système analyse le graphique de dépendance des services et crée des groupes dont le nom correspond au nœud racine (un service sans dépendances en amont). Tous les services qui dépendent directement ou indirectement de ce service racine sont automatiquement inclus dans le groupe. Par exemple, si le service A appelle le service B, qui à son tour appelle le service C, les trois services seront regroupés avec le service A comme nom de groupe, car il s’agit de la racine de la chaîne de dépendance. Ce mécanisme de regroupement automatique offre un moyen naturel de visualiser et de gérer les services associés en fonction de leurs interactions et dépendances réelles lors de l’exécution.
### Actions et informations sur les groupes
Pour chaque groupe, vous pouvez effectuer les actions suivantes :
+ Cliquez sur **Afficher plus** pour afficher les graphiques de mesures, les deux derniers événements de changement et l'heure du dernier déploiement du groupe
![\[Afficher plus de tiroirs pour les groupes dans la carte des applications\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-view-more.png)
+ Cliquez sur **Afficher le tableau de bord** pour afficher le tableau de bord des indicateurs, le tableau des événements de modification et la liste des services du groupe
![\[Afficher le tableau de bord des applications pour le groupe\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview.png)
![\[Afficher le tableau de bord de l'application pour le groupe avec des graphiques de mesures\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview-2.png)
Vous pouvez utiliser **Grouper et filtrer** dans la barre de gauche pour filtrer les groupes qui proposent des services avec une durée de déploiement, un état de santé SLI ou un type de plate-forme de calcul.
![\[Regroupement et filtrage des services sur le tableau de bord de l'application\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-grouping-filter.png)
Vous pouvez également filtrer par compte pour afficher les services de AWS comptes spécifiques dans votre configuration d'observabilité entre comptes.
![\[Filtrer les services par compte sur le tableau de bord de l'application\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-account-filter.png)
Utilisez la barre **Rechercher et filtrer** pour rechercher des groupes par nom ou rechercher des groupes qui contiennent un environnement de service ou une dépendance spécifique. Filtrez par identifiant de compte pour vous concentrer sur les services fournis par des comptes spécifiques.
![\[Rechercher et filtrer les services dans la carte des applications\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-search-and-filter.png)
### Configuration de groupes personnalisés
Le regroupement personnalisé vous permet d’organiser vos services de manière logique en fonction de vos besoins commerciaux et de vos priorités opérationnelles. Cette fonctionnalité vous permet d’afficher et d’enregistrer des vues définies en fonction de vos besoins spécifiques, de créer des groupes en fonction de l’appartenance à une équipe et de regrouper les services nécessaires aux transactions commerciales critiques.
Créez les noms de groupes personnalisés (les noms de groupes que vous verrez dans l’interface utilisateur) et les noms de clés de groupe correspondants. Effectuez cette étape à partir de l'interface utilisateur des signaux d'application ou à l'aide de l'[PutGroupingConfiguration](https://docs.aws.amazon.com/applicationsignals/latest/APIReference/API_PutGroupingConfiguration.html)API.
Les noms de clé de groupe peuvent être soit une clé de AWS balise, soit un attribut de ressource OTEL pour votre service. Lorsque vous choisissez entre les balises et les attributs de ressource OTEL, tenez compte de votre plateforme de calcul :
+ Pour les plateformes à service unique (par exemple, Lambda ou Auto Scaling Group), utilisez des balises AWS
+ Pour les plateformes multiservices (par exemple, le cluster Amazon EKS) : utilisez les attributs de ressource OTEL pour un regroupement plus granulaire
**Ajouter des AWS tags**
Ajoutez une AWS balise avec la clé de groupe personnalisée comme clé et valeur à un cluster Amazon EKS. Lorsque plusieurs services sont exécutés dans un cluster Amazon EKS, ils sont tous balisés avec la même clé de groupe personnalisée. Par exemple, lorsque les services 1, 2 et 3 sont en cours d'exécution dans le cluster A d'Amazon EKS, l'ajout d'une AWS balise avec la clé *Team X* au cluster ajoutera les trois services à *Team X.* Pour ajouter uniquement des services spécifiques à *Team X*, ajoutez des attributs de ressource OTEL pour les services, comme indiqué ci-dessous.
**Ajout d’attributs de ressource OTEL**
Pour ajouter un attribut de ressource OTEL, consultez la configuration ci-dessous :
**Configuration générale**
Configurez la variable d’environnement `OTEL_RESOURCE_ATTRIBUTES` dans votre application à l’aide des paires clé-valeur de groupe personnalisées. Les clés sont répertoriées sous `aws.application_signals.metric_resource_keys`, séparées par `&`.
Par exemple, pour créer des groupes personnalisés en utilisant `Application=PetClinic` et `Owner=Test`, procédez comme suit :
```
OTEL_RESOURCE_ATTRIBUTES=Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner
```
**Configuration spécifique à la plateforme**
Voici les spécifications de déploiement.
**Amazon EKS et Kubernetes natif**
```
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
replicas: 1
...
template:
spec:
containers:
- name: your-app
image: your-app-image
env:
...
- name: OTEL_RESOURCE_ATTRIBUTES
value: Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner
```
**Amazon EC2**
Ajoutez `OTEL_RESOURCE_ATTRIBUTES` au script de démarrage de votre application. Pour obtenir l’exemple complet, consultez [Ajout de `OTEL_RESOURCE_ATTRIBUTES`](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-EC2Main.html#CloudWatch-Application-Signals-Monitor-EC2).
```
...
OTEL_RESOURCE_ATTRIBUTES="service.name=$YOUR_SVC_NAME,Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner" \
java -jar $MY_JAVA_APP.jar
```
**Amazon ECS**
Ajoutez `OTEL_RESOURCE_ATTRIBUTES` au TaskDefinition. Pour obtenir l’exemple complet, consultez [Activer sur Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-ECSMain.html).
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$YOUR_SVC_NAME,Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Applicationmanagement portalOwner"
},
...
]
}
```
**Lambda**
Ajoutez `OTEL_RESOURCE_ATTRIBUTES` à la variable d’environnement Lambda.
```
OTEL_RESOURCE_ATTRIBUTES="Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner"
```
### Affichage des services au sein des groupes
Pour afficher les services et leurs dépendances au sein d’un groupe, cliquez sur le nom du groupe. Une carte des services au sein du groupe s’affichera. Chaque nœud de service affichera l’état SLI, les métriques et les détails de la plateforme. Les services présentant une violation SLI sont mis en évidence afin d’être facilement reconnaissables.
![\[CloudWatch services cartographiques d'applications au sein d'un groupe.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/View-services-groups.png)
Les services non instrumentés sont affichés avec un indicateur visuel distinctif (comme une bordure en pointillés ou une couleur différente) pour les différencier des services instrumentés. Passez le curseur sur un nœud de service non instrumenté pour consulter les instructions d'instrumentation et les liens vers la documentation de configuration.
![\[Filtrer par services non instrumentés sur la carte des applications\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-uninstrumented-filter.png)
Tous les Canaries, les clients RUM et les nœuds de AWS service seront réduits par défaut. Si les services de ce groupe font appel à des services qui ne font pas partie de ce groupe, ils seront également réduits par défaut.
![\[Les nœuds Canary sont regroupés en un groupe dans la carte de l'application\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-canary-collapse.png)
Si votre carte est encore trop grande pour permettre une analyse efficace, vous pouvez appliquer un regroupement imbriqué afin d’affiner votre analyse. Par exemple, après avoir regroupé les services par **unité commerciale**, si vous avez encore trop de services dans un groupe, utilisez le menu déroulant Regrouper par pour sélectionner **Équipe**, créant ainsi une structure de regroupement imbriquée.
![\[Regroupement imbriqué dans la carte des applications\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-nested-grouping.png)
### Informations et détails sur les services
Sur cette page, vous pouvez également cliquer sur **Enregistrer la vue** à côté de la barre de recherche pour enregistrer votre vue afin de ne pas avoir à appliquer à nouveau le même regroupement et le même filtrage la prochaine fois.
![\[Enregistrer la configuration du regroupement\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-save-view.png)
Cliquez sur **Afficher plus** dans le nœud de service pour afficher les graphiques de l'audit du service, des événements de changement, de l'état du SLI et des métriques.
![\[CloudWatch informations sur les services cartographiques des applications.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-view-more.png)
Si vous souhaitez consulter le fonctionnement du service et d'autres détails du service, cliquez sur **Afficher le tableau de bord** pour accéder à la page de présentation du service.
![\[CloudWatch présentation du service de carte des applications.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-overview.png)
Vous pouvez également cliquer sur Périphérie pour afficher les métriques d’un appel de dépendance spécifique d’un service.
![\[CloudWatch carte de l'application, nœud, bord, tiroir\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-edge.png)
### Événements de changement
Suivez les événements de changement dans votre application grâce au traitement automatique des CloudTrail événements par Application Signals. Surveillez les événements de configuration et de déploiement des services et de leurs dépendances, en fournissant un contexte immédiat pour l'analyse opérationnelle et le dépannage. La détection des événements de changement est activée parallèlement à l'activation de la découverte de services via la CloudWatch console ou l' StartDiscovery API. Pour les services EKS, la détection du déploiement nécessite que les services EKS soient instrumentés avec le SDK d'instrumentation des signaux d'application. La vigie applicative établit automatiquement une corrélation entre les délais de déploiement et les changements de performances, vous permettant ainsi d’identifier rapidement si les déploiements récents ont contribué à des problèmes de service. Consultez l'historique des événements de modification et leur impact sur l'ensemble de vos services sans configuration ou configuration supplémentaire.
### Résultats d’audit
Découvrez des informations essentielles grâce aux résultats d’audit de la vigie applicative. Le service analyse vos applications pour signaler les observations importantes et les problèmes potentiels, simplifiant ainsi l'analyse des causes profondes. Ces résultats automatisés consolident les traces pertinentes, éliminant ainsi le besoin de naviguer en plusieurs clics. Le système d'audit aide les équipes à identifier rapidement les problèmes et leurs causes sous-jacentes, permettant ainsi une résolution plus rapide des problèmes.
Pour les services exécutés sur Amazon Bedrock, Application Signals surveille automatiquement les habitudes d'utilisation des jetons GenAI. Le système d'audit détecte les anomalies dans la consommation de jetons d'entrée et de sortie, en comparant l'utilisation actuelle aux données de référence historiques. Lorsque l'utilisation des jetons dépasse les habitudes, les résultats de l'audit fournissent une analyse détaillée, notamment les tendances en matière de consommation de jetons, les implications financières et les recommandations d'optimisation. Cela aide les équipes à identifier les demandes inefficaces, les pics de jetons inattendus et les opportunités de réduction des coûts opérationnels de GenAI.
### Observabilité entre comptes sur la carte des applications
Application Signals prend en charge l'observabilité entre comptes, ce qui vous permet de surveiller et de visualiser les services distribués sur plusieurs AWS comptes dans une seule carte d'applications unifiée. Cette fonctionnalité est essentielle pour les entreprises dotées d'architectures multi-comptes conformes aux AWS meilleures pratiques.
**Capacités clés :**
+ *Vue unifiée* : visualisez les services de plusieurs AWS comptes sur une seule carte d'applications, fournissant ainsi une image complète de votre architecture d'applications distribuées.
+ *Identification du compte* : Chaque nœud de service affiche clairement son numéro de compte et sa région, ce qui permet d'identifier facilement le propriétaire et l'emplacement du service.
+ *Surveillance centralisée* : surveillez l'état, les performances et l'état du SLO des services sur tous les comptes connectés à partir d'un seul compte de surveillance.
+ *Filtrage entre comptes* : filtrez et regroupez les services par ID de compte pour vous concentrer sur des comptes spécifiques ou consulter les interactions entre comptes.
**Comment ça marche :**
Application Signals utilise AWS les Organisations et le partage entre comptes pour permettre l'observabilité entre plusieurs comptes. Pour configurer l'observabilité entre comptes, reportez-vous à[CloudWatch observabilité entre comptes](CloudWatch-Unified-Cross-Account.md).
------
#### [ View your application services ]
**Service (instrumenté)**
Vous pouvez consulter les services de votre application, leur statut SLOs et les indicateurs de niveau de service (SLIs) dans la **carte des applications**. Si vous n'avez rien créé SLOs pour un service, cliquez sur le bouton **Create SLO** situé sous le nœud de service.
La **Carte d’application** affiche tous vos services. Elle indique également les clients et les canaries qui utilisent le service, ainsi que les dépendances que vos services appellent, comme le montre l’image suivante :
![\[Une carte des CloudWatch applications affichant un service sain et insalubre.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-map-service-healthy-unhealthy.png)
Lorsque vous sélectionnez un nœud de service, un volet s’ouvre et affiche des informations détaillées sur le service :
+ Fréquence totale des erreurs et des défaillances.
+ Le nombre de SLIs et SLOs qui sont `healthy` ou`unhealthy`.
+ L’option permettant d’afficher plus d’informations sur un SLO.
+ Les `Cluster`, `Namespace` et `Workload` pour les services hébergés dans Amazon EKS, ou l’environnement pour les services hébergés dans Amazon ECS ou Amazon EC2. Pour les services hébergés par Amazon EKS, choisissez n'importe quel lien pour ouvrir CloudWatch Container Insights.
+ AccountId et région.
+ La section **Change** affiche les événements de modification récents et la date du dernier déploiement.
+ L’onglet **Audit opérationnel** fournit des résultats d’audit automatisés et des recommandations.
+ Graphique des métriques de service sur la disponibilité, la latence, les défaillances et les erreurs.
Sélectionnez une périphérie ou une connexion entre un nœud de service et un service en aval ou un nœud de dépendance. Cela ouvre un volet contenant les chemins d’accès les plus fréquents par taux de défaillance, latence et taux d’erreur, comme le montre l’exemple d’image suivant. Sélectionnez n’importe quel lien dans le volet pour ouvrir la page [Détails du service](ServiceDetail.md) et afficher des informations détaillées sur le service ou la dépendance choisie.
![\[Un avantage du service de carte des CloudWatch applications\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/App-signals-service-edge.png)
Lorsque vous sélectionnez un nœud périphérique, un volet s’ouvre et affiche des informations détaillées sur le service :
+ Nombre total de requêtes, latence, taux d’erreur et taux de défaillance
+ Principaux chemins d’accès par taux de défaillance
+ Principaux chemins d’accès par latence
+ Principaux chemins d’accès par taux d’erreur
**Service (non instrumenté)**
Les services non instrumentés apparaissent sur la carte des applications même s'ils n'ont pas été configurés avec des signaux d'application. Ces services sont automatiquement découverts en utilisant Resource Explorer à l'aide des noms et des balises des applications. Le système peut détecter automatiquement jusqu'à 3 000 ressources sur votre AWS compte.
Lorsque vous sélectionnez un nœud de service non instrumenté, un volet s'ouvre et affiche :
+ Nom du service et informations d'identification
+ AccountId et région où le service est détecté
+ État de l'instrumentation et conseils
+ Bouton d'appel à l'action « Activer les signaux d'application » qui fournit des instructions de configuration
+ Type de plate-forme de calcul (s'il est détectable)
Les services non instrumentés vous aident à :
+ Identifiez les lacunes dans votre couverture d'observabilité
+ Priorisez les services à instrumenter ensuite en fonction de leur position dans votre architecture
+ Comprendre la topologie complète de l'application avant même l'instrumentation complète
+ Planifiez le déploiement de l'instrumentation au sein de votre organisation
**Note**
Les services non instrumentés affichent des données télémétriques limitées car ils n'envoient pas activement de métriques ou de traces.
![\[CloudWatch carte d'application, filtre d'instrumentation\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/explore-application-map-instrumentation-filter.png)
------
#### [ View dependencies ]
Les dépendances de votre application sont affichées sur la carte d’application, connectées aux services qui les appellent.
Sélectionnez un nœud de dépendance pour ouvrir un volet contenant le taux d’erreur et le taux de défaillance, le graphique des métriques pour les requêtes, la disponibilité, la latence, le taux de défaillance et le taux d’erreur.
Si le nœud de dépendance est un service ou une ressource, le volet affiche les événements de modification pour la plage de temps demandée.
![\[Carte d' CloudWatch application affichant un nœud de dépendance AWS de service extensible.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-map-dependency.png)
------
#### [ View clients ]
Une fois que vous avez [activé le suivi X-Ray](CloudWatch-RUM-get-started-create-app-monitor.md) pour vos clients Web CloudWatch RUM, ils s'affichent sur la carte des applications connectées aux services qu'ils appellent.
Sélectionnez un nœud client pour ouvrir un volet affichant des informations détaillées sur le client :
+ Métriques relatives au chargement des pages, au temps de chargement moyen, aux erreurs et aux données vitales moyennes sur le Web
+ Un graphique présentant la répartition des erreurs
+ Un lien pour afficher les détails du client dans CloudWatch RUM
![\[Carte d' CloudWatch application affichant un nœud client extensible.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-map-client.png)
Sélectionnez **Afficher le tableau de bord** pour ouvrir les détails du canary.
------
#### [ View synthetics canaries ]
Pour afficher les canaris sur la carte de votre application, activez l'option [X-Ray tracing](CloudWatch-RUM-get-started-create-app-monitor.md) pour vos canaris CloudWatch Synthetics. Une fois activés, les canaries apparaîtront connectés à leurs services appelés sur la carte d’application.
Le système regroupe par défaut les canaries dans une seule icône extensible. Le volet d’informations détaillées sur les canaries affiche les métriques, les traces et les informations d’état.
Sélectionnez un nœud canary pour ouvrir un volet affichant des informations détaillées sur les canaries, comme illustré dans l’image suivante :
![\[Une carte CloudWatch d'application affichant un nœud canari synthétique extensible.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-map-canary.png)
Sélectionnez **Afficher le tableau de bord** pour ouvrir les détails du canary.
------
# Observabilité des applications au service de l'action AWS
L'application Observability for AWS GitHub Action fournit un flux de travail d'investigation de end-to-end l'observabilité des applications qui connecte votre code source et les données de télémétrie de production en direct à un agent AI. Il exploite CloudWatch MCPs et génère des invites personnalisées pour fournir le contexte dont les agents d'IA ont besoin pour résoudre des problèmes et appliquer des correctifs de code.
L'action installe et configure les [signaux d'CloudWatch application MCP Server et [CloudWatch MCP Server](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server)](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server), leur permettant d'accéder aux données de télémétrie en direct dans le contexte du dépannage. Vous pouvez utiliser votre modèle d'IA préféré, que ce soit par le biais de votre propre clé d'API, d'un modèle tiers ou d'Amazon Bedrock, pour étudier les performances des applications.
Pour commencer, mentionnez `@awsapm` dans vos GitHub problèmes le déclenchement de l'agent AI. L'agent résoudra les problèmes de production, mettra en œuvre des correctifs et améliorera la couverture d'observabilité en fonction des données réelles de votre application.
Cette action en elle-même n'entraîne aucun coût direct. Cependant, l'utilisation de cette action peut entraîner des frais pour les AWS services et l'utilisation du modèle d'IA. Reportez-vous à la [documentation sur les considérations relatives aux coûts](https://github.com/marketplace/actions/application-observability-for-aws#-cost-considerations) pour obtenir des informations détaillées sur les coûts potentiels.
## Démarrage
Cette action configure les agents d'intelligence artificielle au sein de votre GitHub flux de travail en générant des AWS configurations MCP spécifiques et des instructions d'observabilité personnalisées. Il vous suffit de fournir le rôle IAM à assumer et un [identifiant de modèle Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html) que vous souhaitez utiliser, ou un jeton d'API provenant de votre abonnement LLM existant. L'exemple ci-dessous illustre un modèle de flux de travail qui intègre cette action à celle d'[Anthropic claude-code-base-action](https://github.com/anthropics/claude-code-base-action) pour exécuter des enquêtes automatisées.
### Conditions préalables
Avant de commencer, assurez-vous que vous disposez des éléments suivants :
+ **GitHub Autorisations du référentiel** : accès en écriture ou supérieur au référentiel (nécessaire pour déclencher l'action)
+ AWS Rôle **IAM : rôle** IAM configuré avec OpenID Connect (OIDC) pour les actions avec des autorisations pour GitHub :
+ CloudWatch Signaux d'application et CloudWatch accès
+ Accès au modèle Amazon Bedrock (si vous utilisez des modèles Bedrock)
+ **GitHub Jeton** : le flux de travail utilise automatiquement GITHUB\$1TOKEN avec les autorisations requises
### Étapes de configuration
#### Étape 1 : configurer les AWS informations d'identification
Cette action repose sur l'action [aws-actions/](https://github.com/aws-actions/configure-aws-credentials) pour configurer configure-aws-credentials l' AWS authentification dans votre environnement Actions. GitHub Nous vous recommandons d'utiliser OpenID Connect (OIDC) pour vous authentifier auprès de. AWS OIDC permet à vos flux de travail GitHub Actions d'accéder aux AWS ressources à l'aide d' AWS informations d'identification de courte durée, de sorte que vous n'avez pas à stocker des informations d'identification à long terme dans votre référentiel.
1. **Création d'un fournisseur d'identité IAM**
Créez d'abord un fournisseur d'identité IAM qui approuve le point GitHub de terminaison OIDC dans la console de AWS gestion :
1. Ouvrez la console IAM
1. Cliquez sur **Fournisseurs d'identité** sous **Gestion des accès**
1. Cliquez sur le bouton **Ajouter un fournisseur** pour ajouter un fournisseur GitHub d'identité s'il n'a pas encore été créé
1. Sélectionnez le type de fournisseur d'identité **OpenID Connect**
1. Entrez dans `https://token.actions.githubusercontent.com` la zone de saisie **de l'URL du fournisseur**
1. Entrez `sts.amazonaws.com` pour la zone de saisie **Audience**
1. Cliquez sur le bouton **Ajouter un fournisseur**
1. **Création d'une politique IAM**
Créez une politique IAM avec les autorisations requises pour cette action. Consultez la [Autorisations nécessaires](#Service-Application-Observability-for-AWS-GitHub-Action-required-permissions) section ci-dessous pour plus de détails.
1. **Création d'un rôle IAM**
Créez un rôle IAM (par exemple,`AWS_IAM_ROLE_ARN`) dans la console de AWS gestion avec le modèle de politique de confiance suivant. Cela permet aux GitHub référentiels autorisés d'assumer le rôle suivant :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:/:ref:refs/heads/"
}
}
}
]
}
```
Remplacez les espaces réservés suivants dans le modèle :
+ ``- Votre identifiant AWS de compte
+ ``- Le nom GitHub de votre organisation
+ ``- Le nom de votre dépôt
+ ``- Le nom de votre agence (par exemple, principale)
1. **Joindre la politique IAM**
Dans l'onglet Autorisations du rôle, joignez la politique IAM que vous avez créée à l'étape 2.
Pour plus d'informations sur la configuration d'OIDC avec AWS, consultez le guide de [démarrage rapide configure-aws-credentials OIDC](https://github.com/aws-actions/configure-aws-credentials/tree/main?tab=readme-ov-file#quick-start-oidc-recommended).
#### Étape 2 : Configuration des secrets et ajout d'un flux de travail
1. **Configurer les secrets du référentiel**
Accédez à votre dépôt → Paramètres → Secrets et variables → Actions.
+ Créez un nouveau secret de référentiel nommé `AWS_IAM_ROLE_ARN` et définissez sa valeur sur l'ARN du rôle IAM que vous avez créé à l'étape 1.
+ (Facultatif) Créez une variable de référentiel nommée `AWS_REGION` pour spécifier votre AWS région (la valeur par défaut est `us-east-1` si elle n'est pas définie)
1. **Ajouter le fichier de flux de travail**
Voici un exemple de flux de travail illustrant l'utilisation de cette action avec les modèles Amazon Bedrock. Créez un flux de travail d'investigation sur l'observabilité des applications à partir de ce modèle dans le répertoire `.github/workflows` de votre GitHub référentiel.
```
name: Application observability for AWS
on:
issue_comment:
types: [created, edited]
issues:
types: [opened, assigned, edited]
jobs:
awsapm-investigation:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@awsapm')) ||
(github.event_name == 'issues' && (contains(github.event.issue.body, '@awsapm') || contains(github.event.issue.title, '@awsapm')))
runs-on: ubuntu-latest
permissions:
contents: write # To create branches for PRs
pull-requests: write # To post comments on PRs
issues: write # To post comments on issues
id-token: write # Required for AWS OIDC authentication
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_IAM_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION || 'us-east-1' }}
# Step 1: Prepare AWS MCP configuration and investigation prompt
- name: Prepare Investigation Context
id: prepare
uses: aws-actions/application-observability-for-aws@v1
with:
bot_name: "@awsapm"
cli_tool: "claude_code"
# Step 2: Execute investigation with Claude Code
- name: Run Claude Investigation
id: claude
uses: anthropics/claude-code-base-action@beta
with:
use_bedrock: "true"
# Set to any Bedrock Model ID
model: "us.anthropic.claude-sonnet-4-5-20250929-v1:0"
prompt_file: ${{ steps.prepare.outputs.prompt_file }}
mcp_config: ${{ steps.prepare.outputs.mcp_config_file }}
allowed_tools: ${{ steps.prepare.outputs.allowed_tools }}
# Step 3: Post results back to GitHub issue/PR (reuse the same action)
- name: Post Investigation Results
if: always()
uses: aws-actions/application-observability-for-aws@v1
with:
cli_tool: "claude_code"
comment_id: ${{ steps.prepare.outputs.awsapm_comment_id }}
output_file: ${{ steps.claude.outputs.execution_file }}
output_status: ${{ steps.claude.outputs.conclusion }}
```
**Remarque sur la configuration :**
+ Ce flux de travail se déclenche automatiquement lorsqu'il `@awsapm` est mentionné dans un problème ou un commentaire
+ Le flux de travail utilise le `AWS_IAM_ROLE_ARN` secret configuré à l'étape précédente
+ Mettez à jour le paramètre du modèle à l'étape 2 pour spécifier votre identifiant de modèle Amazon Bedrock préféré
+ Vous pouvez personnaliser le nom du bot (par exemple,`@awsapm-prod`,`@awsapm-staging`) dans le paramètre bot\$1name pour prendre en charge différents environnements
#### Étape 3 : commencez à utiliser l'action
Une fois le flux de travail configuré, mentionnez-le `@awsapm` dans n'importe quel GitHub problème pour déclencher une enquête basée sur l'IA. L'action analysera votre demande, accédera aux données de télémétrie en direct et fournira des recommandations ou mettra en œuvre des correctifs automatiquement.
**Exemples de cas d'utilisation :**
1. Étudiez les problèmes de performances, publiez et corrigez :
`@awsapm, can you help me investigate availability issues in my appointment service?`
![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-investigate.png)
`@awsapm, can you post a fix?`
![\[alt text not found\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-pr-fix.png)
1. Activez l'instrumentation :
`@awsapm, please enable Application Signals for lambda-audit-service and create a PR with the required changes.`
1. Interrogez les données de télémétrie :
`@awsapm, how many GenAI tokens have been consumed by my services in the past 24 hours?`
**Que se passera-t-il ensuite :**
1. Le flux de travail détecte la `@awsapm` mention et déclenche l'enquête
1. L'agent AI accède à vos données de AWS télémétrie en direct via les serveurs MCP configurés
1. L'agent analyse le problème et :
+ Affiche les conclusions et les recommandations directement dans le numéro
+ Crée une pull request avec des modifications de code (pour l'instrumentation ou les corrections)
1. Vous pouvez consulter les résultats et poursuivre la conversation en mentionnant à nouveau @awsapm avec des questions de suivi
## Sécurité
Cette action donne la priorité à la sécurité grâce à des contrôles d'accès stricts, à une AWS authentification basée sur l'OIDC et à des protections intégrées contre les attaques par injection rapide. Seuls les utilisateurs disposant d'un accès en écriture ou supérieur peuvent déclencher l'action, et toutes les opérations sont limitées au référentiel spécifique.
Pour obtenir des informations de sécurité détaillées, notamment :
+ Contrôles d'accès et exigences en matière d'autorisation
+ AWS Autorisations IAM et configuration OIDC
+ Risques liés à l'injection rapide et mesures d'atténuation
+ Bonnes pratiques de sécurité
Consultez la [documentation de sécurité](https://github.com/aws-actions/application-observability-for-aws/blob/main/docs/security.md).
## Configuration
### Autorisations nécessaires
Le rôle IAM assumé par GitHub Actions doit disposer des autorisations suivantes.
**Remarque** : `bedrock:InvokeModel` et ne `bedrock:InvokeModelWithResponseStream` sont obligatoires que si vous utilisez des modèles Amazon Bedrock
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-signals:ListServices",
"application-signals:GetService",
"application-signals:ListServiceOperations",
"application-signals:ListServiceLevelObjectives",
"application-signals:GetServiceLevelObjective",
"application-signals:ListAuditFindings",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"logs:DescribeLogGroups",
"logs:DescribeQueryDefinitions",
"logs:ListLogAnomalyDetectors",
"logs:ListAnomalies",
"logs:StartQuery",
"logs:StopQuery",
"logs:GetQueryResults",
"logs:FilterLogEvents",
"xray:GetTraceSummaries",
"xray:GetTraceSegmentDestination",
"xray:BatchGetTraces",
"xray:ListRetrievedTraces",
"xray:StartTraceRetrieval",
"servicequotas:GetServiceQuota",
"synthetics:GetCanary",
"synthetics:GetCanaryRuns",
"s3:GetObject",
"s3:ListBucket",
"iam:GetRole",
"iam:ListAttachedRolePolicies",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*"
}
]
}
```
## Documentation
Pour plus d'informations, consultez :
+ [CloudWatch Documentation sur les signaux d'application](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Intro.html) - En savoir plus sur les fonctionnalités et les capacités des signaux d' CloudWatch application
+ [Observabilité des applications pour AWS Action Public Documentation](https://github.com/marketplace/actions/application-observability-for-aws) - Guides et didacticiels détaillés
# Exemple : utilisation d’Application Signals pour résoudre un problème d’état de fonctionnement
Le scénario suivant fournit un exemple de la manière dont Application Signals peuvent être utilisés pour surveiller vos services et identifier les problèmes de qualité de service. Effectuez une analyse approfondie pour identifier les causes profondes potentielles et prendre les mesures nécessaires pour résoudre le problème. Cet exemple se concentre sur une application de clinique pour animaux de compagnie composée de plusieurs microservices qui font appel, par Services AWS exemple, à DynamoDB.
Jane fait partie d'une DevOps équipe qui supervise la santé opérationnelle d'une application de clinique pour animaux de compagnie. L’équipe de Jane s’engage à faire en sorte que l’application soit hautement disponible et réactive. Ils utilisent des [objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md) pour mesurer les performances des applications par rapport à ces engagements commerciaux. Elle reçoit une alerte concernant plusieurs indicateurs de niveau de service défaillants (SLIs). Elle ouvre la CloudWatch console et accède à la page Services, où elle constate que plusieurs services ne fonctionnent pas correctement.
![\[Services pour personnes malsaines SLIs\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/example-scenario-services-page.jpg)
En haut de la page, Jane constate que `visits-service` est le service qui enregistre le plus grand nombre de défaillances. Elle sélectionne le lien dans le graphique, qui ouvre la page Détails du service correspondant. Elle constate qu’il y a une opération non saine dans le tableau des opérations du service. Elle sélectionne cette opération et constate dans le graphique du volume et de la disponibilité qu’il existe des pics de volume d’appels périodiques qui semblent être liés à des baisses de disponibilité.
![\[Volume des opérations et disponibilité des services\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/example-scenario-unhealthy-operation.png)
Afin d’examiner de plus près les baisses de disponibilité des services, Jane sélectionne l’un des points de données de disponibilité dans le graphique. Un tiroir s’ouvre et affiche les suivis X-Ray corrélés au point de données sélectionné. Elle constate qu’il existe de multiples suivis contenant des défaillances.
![\[Disponibilité du service et suivis corrélés\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/example-scenario-correlated-traces.jpg)
Jane sélectionne l’un des suivis corrélés présentant un état de défaut, ce qui ouvre la page détaillée de suivi X-Ray pour le suivi sélectionné. Jane fait défiler la page jusqu’à la section Chronologie des segments et suit le chemin des appels jusqu’à ce qu’elle constate que les appels à une table DynamoDB renvoient des erreurs. Elle sélectionne le segment DynamoDB et accède à l’onglet Exceptions du tiroir de droite.
![\[Segment de suivi contenant des erreurs DynamoDB\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/example-scenario-DDB-segment.jpg)
Jane constate qu’une ressource DynamoDB est mal configurée, ce qui entraîne des erreurs lors des pics de demandes des clients. Le niveau de débit provisionné de la table DynamoDB est régulièrement dépassé, ce qui entraîne des problèmes de disponibilité du service et un mauvais fonctionnement. SLIs Sur la base de ces informations, son équipe est en mesure de configurer un niveau supérieur de débit provisionné et de garantir une haute disponibilité de l’application.
# Exemple : utiliser les signaux d'application pour résoudre les problèmes liés aux applications d'IA génératives interagissant avec Amazon Bedrock les modèles
Vous pouvez utiliser les signaux d'application pour dépanner vos applications d'IA générative qui interagissent avec les Amazon Bedrock modèles. Application Signals rationalise ce processus en fournissant des données de out-of-the-box télémétrie, offrant ainsi des informations plus approfondies sur les interactions de votre application avec les modèles LLM. Il permet de traiter des cas d’utilisation clés tels que :
+ Problèmes de configuration du modèle
+ Coûts d’utilisation du modèle
+ Latence du modèle
+ Raisons de l’arrêt de la génération de réponses du modèle
[L'activation des signaux d'application](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable.html) grâce à l' LLM/GenAI observabilité fournit une visibilité en temps réel des interactions de votre application avec les services Amazon Bedrock. Application Signals génère et met en corrélation automatiquement des mesures de performance et des traces pour les appels Amazon Bedrock d'API.
La vigie applicative prend actuellement en charge les modèles LLM suivants de Amazon Bedrock.
+ AI21 Jamba
+ Amazon Titan
+ Anthropic Claude
+ Cohere Command
+ Meta Llama
+ Mistral AI
+ Nova
## Métriques et traces détaillées
Pour chaque appel Amazon Bedrock d'API, Application Signals génère des mesures de performance détaillées au niveau des ressources, notamment :
+ ID du modèle
+ ID de barrières de protection
+ ID de base de connaissances
+ ID d’agent Bedrock
De plus, les portées corrélées au même niveau permettent d’obtenir une vue d’ensemble de l’exécution des requêtes et des dépendances.
![\[Métriques de performance utilisant la vigie applicative.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample.png)
## OpenTelemetry Support des attributs GenAI
Application Signals génère les attributs GenAI suivants pour les appels d' Amazon Bedrock API selon une convention OpenTelemetry sémantique. Ces attributs permettent d’analyser l’utilisation du modèle, le coût et la qualité de la réponse, et peuvent être exploités via [Recherche de transactions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) pour obtenir des informations plus approfondies.
+ gen\$1ai.system
+ gen\$1ai.request.model
+ gen\$1ai.request.max\$1tokens
+ gen\$1ai.request.temperature
+ gen\$1ai.request.top\$1p
+ gen\$1ai.usage.input\$1tokens
+ gen\$1ai.usage.output\$1tokens
+ gen\$1ai.response.finish\$1reasons
![\[Attributs GenAI utilisant la vigie applicative.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_1.png)
Par exemple, vous pouvez exploiter la capacité d’analyse de la recherche de transactions pour comparer l’utilisation et le coût des jetons entre différents modèles LLM pour la même invite, ce qui permet une sélection de modèle rentable.
![\[Attributs GenAI utilisant la vigie applicative.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_2.png)
Pour plus d'informations, voir [Améliorer l' Amazon Bedrock observabilité avec les signaux CloudWatch d'application](https://aws.amazon.com/blogs/mt/improve-amazon-bedrock-observability-with-amazon-cloudwatch-appsignals/).