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.
# Application Signals
CloudWatch Application Signals vous aide à surveiller et à améliorer les performances des applications sur AWS. Il collecte automatiquement les données de vos applications exécutées sur des services tels qu’Amazon EC2, Amazon ECS et Lambda. Vous pouvez utiliser les signaux CloudWatch d'application pour les opérations suivantes :
+ Surveiller l’état des applications en temps réel
+ Suivre les performances par rapport aux objectifs commerciaux
+ Afficher les relations entre les services et les dépendances
+ Identifier et résoudre rapidement les problèmes de performances
+ Activez Application Signals pour collecter automatiquement les métriques et les suivis de vos applications, et afficher les métriques clés telles que le volume des appels, la disponibilité, la latence, les pannes et les erreurs. Visualisez et triez rapidement l’état de fonctionnement actuel, et vérifiez si vos applications atteignent leurs objectifs de performance à long terme, sans écrire de code personnalisé ni créer de tableaux de bord.
+ Créez et surveillez les [objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md) avec Application Signals. Créez et suivez facilement l'état des CloudWatch métriques SLOs associées, y compris les nouvelles métriques d'application standard collectées par Application Signals. Consultez et suivez l’état de l’[indicateur de niveau de service (SLI)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-concepts) de vos services d’application dans une liste de services et une carte topologique. Créez des alarmes pour suivre vos SLOs métriques d'application standard collectées par Application Signals et suivez les nouvelles mesures standard collectées par Application Signals.
+ Consultez une carte de la topologie de votre application découverte automatiquement par Application Signals, qui vous donne une représentation visuelle de vos applications, de leurs dépendances et de leur connectivité.
+ Application Signals fonctionne avec [CloudWatch RUM](CloudWatch-RUM.md), [CloudWatchSynthetics](CloudWatch_Synthetics_Canaries.md) canaries Amazon EC2 Auto Scaling et pour afficher les pages de vos clients [AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html), les canaris Synthetics et les noms des applications dans les tableaux de bord et les cartes.
**Langages et architectures pris en charge**
La vigie applicative prend en charge les applications Java, Python, Node.js et .NET.
Application Signals est pris en charge et testé sur Amazon EKS, Amazon ECS et Amazon EC2. Sur les clusters Amazon EKS, il découvre automatiquement les noms de vos services et clusters. Sur les autres architectures, vous devez fournir les noms des services et des environnements lorsque vous activez ces services pour Application Signals.
Les instructions d'activation des signaux d'application sur Amazon EC2 doivent fonctionner sur toute architecture prenant en charge l' CloudWatch agent et AWS la distribution pour. OpenTelemetry Toutefois, les instructions n’ont pas été testées sur des architectures autres qu’Amazon ECS et Amazon EC2.
**Régions prises en charge**
La vigie applicative est prise en charge dans toutes les régions commerciales, à l’exception de Canada-Ouest (Calgary).
**Topics**
+ [Caractéristiques](#application-signals-features)
+ [Autorisations requises pour Application Signals](Application_Signals_Permissions.md)
+ [Systèmes pris en charge](CloudWatch-Application-Signals-supportmatrix.md)
+ [Configurations d’instrumentation prises en charge](Getting-Started-App-Signals.md)
+ [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md)
+ [(Facultatif) Tester la vigie applicative avec un exemple d’application](CloudWatch-Application-Signals-Enable-EKS-sample.md)
+ [Activation de vos applications sur des clusters Amazon EKS](CloudWatch-Application-Signals-Enable-EKS.md)
+ [Activation des applications sur Amazon EC2](CloudWatch-Application-Signals-Enable-EC2Main.md)
+ [Activation des applications sur Amazon ECS](CloudWatch-Application-Signals-Enable-ECSMain.md)
+ [Activer vos applications sur Kubernetes](CloudWatch-Application-Signals-Enable-KubernetesMain.md)
+ [Activer vos applications sur Lambda](CloudWatch-Application-Signals-Enable-LambdaMain.md)
+ [Résolution des problèmes liés à l’installation d’Application Signals](CloudWatch-Application-Signals-Enable-Troubleshoot.md)
+ [(Facultatif) Configuration de la vigie applicative](CloudWatch-Application-Signals-Configure.md)
+ [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md)
+ [Métriques collectées par la vigie applicative](AppSignals-MetricsCollected.md)
+ [Métriques personnalisées avec la vigie applicative](AppSignals-CustomMetrics.md)
## Caractéristiques
+ **Utiliser les signaux d'application pour la surveillance quotidienne des applications** — Utilisez les signaux d'application dans la CloudWatch console, dans le cadre de la surveillance quotidienne des applications :
1. Si vous avez créé des objectifs de niveau de service (SLOs) pour vos services, commencez par la page des [objectifs de niveau de service (SLO)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-Triage). Cela vous permet d’avoir une vue immédiate de l’état de leurs services, opérations et dépendances les plus critiques. Sélectionnez le nom du service, de l’opération ou de la dépendance pour un SLO afin d’ouvrir la page [Détails du service](ServiceDetail.md) et d’afficher des informations détaillées sur le service pendant que vous résolvez les problèmes.
1. Ouvrez la page [Services](Services-page.md) pour voir un résumé de tous vos services et voir rapidement les services présentant le taux de défaillance ou le temps de latence le plus élevé. Si vous l'avez créé SLOs, consultez le tableau Services pour voir quels services présentent des indicateurs de niveau de service défaillants (SLIs). Si un service particulier est dans un état non sain, sélectionnez-le pour ouvrir la page [Détail du service](ServiceDetail.md) et voir les opérations du service, les dépendances, les scripts canary Synthetics et les demandes des clients. Sélectionnez un point dans un graphique pour voir les suivis corrélés afin de pouvoir résoudre et identifier la cause première des problèmes opérationnels.
1. Si de nouveaux services ont été déployés ou si les dépendances ont changé, ouvrez la [Carte d’application](ServiceMap.md) pour inspecter la topologie de votre application. Consultez une carte de vos applications qui montre la relation entre les clients, les scripts canary Synthetics, les services et les dépendances. Consultez rapidement l’état du SLI, les métriques clés telles que le volume d’appels, le taux de défaillance et la latence, et effectuez une analyse approfondie pour obtenir des informations plus détaillées dans la page de [Détails du service](ServiceDetail.md).
L’utilisation d’Application Signals entraîne des frais. Pour plus d'informations sur CloudWatch les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing).
**Note**
Il n'est pas nécessaire d'activer Application Signals pour utiliser CloudWatch Synthetics ou RUM. CloudWatch Cependant, Synthetics CloudWatch et RUM fonctionnent avec Application Signals pour offrir des avantages lorsque vous utilisez ces fonctionnalités ensemble.
+ **Signaux d'application entre comptes** — Grâce à l'observabilité entre comptes des signaux d'application, vous pouvez surveiller et dépanner vos applications qui concernent plusieurs AWS comptes au sein d'une même région.
Vous pouvez utiliser Amazon CloudWatch Observability Access Manager pour configurer un ou plusieurs de vos AWS comptes en tant que compte de surveillance. Vous allez permettre au compte de surveillance de consulter les données de votre compte source en créant un récepteur dans votre compte de surveillance. Vous utilisez le récepteur pour créer un lien entre votre compte source et votre compte de surveillance. Pour de plus amples informations, veuillez consulter [CloudWatch observabilité entre comptes](CloudWatch-Unified-Cross-Account.md).
Pour garantir le bon fonctionnement de l'observabilité entre comptes des signaux d'application, assurez-vous que les types de télémétrie suivants sont partagés via le gestionnaire d'accès à l' CloudWatch observabilité.
+ Services de signaux d'application et objectifs de niveau de service (SLOs)
+ Métriques sur Amazon CloudWatch
+ Groupes de journaux dans Amazon CloudWatch Logs
+ Traces dans [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ **Regroupement et filtrage dynamiques des services** : regroupez et filtrez les services grâce aux capacités de regroupement dynamique de la vigie applicative. Agrégez automatiquement les métriques et SLIs les services au sein des groupes, ce qui vous permet de partir d'une vue de groupe et d'approfondir des domaines problématiques spécifiques. Application Signals propose deux groupements par défaut : le groupe « Environnement » organisé par environnement de service et le groupe « Services associés » qui regroupe les services en fonction de leurs dépendances. Par exemple, dans le regroupement des services connexes, si le service A appelle le service B, qui appelle le service C, ils sont regroupés sous le service A. Au-delà des groupements par défaut, créez des groupes personnalisés en sélectionnant des services correspondant aux besoins de votre organisation, tels que l'unité commerciale ou l'équipe.
Créez des regroupements personnalisés à l'aide de AWS balises ou d' OpenTelemetry attributs adaptés à la structure de votre équipe, à vos domaines d'activité ou à vos exigences opérationnelles. Les regroupements personnalisés vous permettent d’organiser les services en fonction de vos flux de travail spécifiques de surveillance et de dépannage. Pour de plus amples informations, veuillez consulter [Configuration de groupes personnalisés](ServiceMap.md#Application-Map-Configure-Custom-Groups).
![\[CloudWatch carte des applications avec regroupement par services associés.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/application-map.png)
![\[CloudWatch page de liste de services avec filtrage.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/services-page.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 Amazon EKS, la détection du déploiement nécessite que les services Amazon EKS soient équipés du SDK d'instrumentation Application Signals.
Les événements de changement sont pris en charge pour les ressources suivantes :
+ Groupe Autoscaling
+ Cluster EKS
+ Charge de travail EKS (uniquement pour les déploiements)
+ Cluster et service ECS
+ Équilibreur de charge ELB et groupe cible
+ Fonction Lambda
+ BedrockAgentCore Durée d'exécution et RuntimeEndpoint
![\[CloudWatch carte des applications avec filtrage du déploiement et événements de modification dans le tiroir du groupe.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/application-map-with-drawer.png)
![\[CloudWatch présentation de l'application avec tableau des événements de modification.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/application-overview.png)
+ **Résultats d'audit automatisés — Découvrez des informations critiques grâce aux résultats** d'audit automatisés d'Application Signals. 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.
La vigie applicative utilise des analytiques avancées pour détecter des tendances, mettre en évidence les inefficacités en matière de ressources et formuler une suggestion d’opportunités d’optimisation. Les résultats sont classés par ordre de priorité en fonction de leur gravité et de leur impact potentiel sur l’activité, ce qui permet aux équipes de se concentrer en premier lieu sur les problèmes les plus critiques. Obtenez des recommandations exploitables pour améliorer la fiabilité et les performances du service sans analyse manuelle.
![\[CloudWatch aperçu des services avec les résultats de l'audit.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/images/service-overview.png)
# Autorisations requises pour Application Signals
Cette section explique les autorisations nécessaires pour activer, gérer et utiliser Application Signals.
## Autorisations pour activer et gérer Application Signals
Pour gérer la vigie applicative, vous devez être connecté avec les autorisations requises. Pour consulter le contenu de la **CloudWatchApplicationSignalsFullAccess**politique, voir [CloudWatchApplicationSignalsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchApplicationSignalsFullAccess.html).
Pour activer la vigie applicative sur Amazon EC2 ou des architectures personnalisées, consultez [Activer la vigie applicative sur Amazon EC2](CloudWatch-Application-Signals-Enable-EC2Main.md). Pour activer et gérer les signaux d'application sur Amazon EKS à l'aide du [module complémentaire Amazon CloudWatch Observability EKS](install-CloudWatch-Observability-EKS-addon.md), vous devez disposer des autorisations suivantes.
**Important**
Ces autorisations incluent `iam:PassRole` avec `Resource "*”` et `eks:CreateAddon` avec `Resource “*”`. Ces autorisations sont puissantes et vous devez faire preuve de prudence lorsque vous les accordez.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudWatchApplicationSignalsEksAddonManagementPermissions",
"Effect": "Allow",
"Action": [
"eks:AccessKubernetesApi",
"eks:CreateAddon",
"eks:DescribeAddon",
"eks:DescribeAddonConfiguration",
"eks:DescribeAddonVersions",
"eks:DescribeCluster",
"eks:DescribeUpdate",
"eks:ListAddons",
"eks:ListClusters",
"eks:ListUpdates",
"iam:ListRoles",
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"eks.amazonaws.com",
"application-signals.cloudwatch.amazonaws.com"
]
}
}
},
{
"Sid": "CloudWatchApplicationSignalsEksCloudWatchObservabilityAddonManagementPermissions",
"Effect": "Allow",
"Action": [
"eks:DeleteAddon",
"eks:UpdateAddon"
],
"Resource": "arn:aws:eks:*:*:addon/*/amazon-cloudwatch-observability/*"
}
]
}
```
------
Le tableau de bord des signaux d'application affiche les AWS Service Catalog AppRegistry applications auxquelles vous SLOs êtes associé. Pour voir ces applications dans les pages SLO, vous devez disposer des autorisations suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudWatchApplicationSignalsTaggingReadPermissions",
"Effect": "Allow",
"Action": "tag:GetResources",
"Resource": "*"
}
]
}
```
------
## Exploitation d’Application Signals
Les opérateurs de services qui utilisent les signaux d'application pour surveiller les services et SLOs doivent être connectés à un compte avec des autorisations de lecture seule. Pour consulter le contenu de la **CloudWatchApplicationSignalsReadOnlyAccess**politique, voir [CloudWatchApplicationSignalsReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchApplicationSignalsReadOnlyAccess.html).
Pour voir à quelles AWS Service Catalog AppRegistry applications vous SLOs êtes associées dans le tableau de bord des signaux d'application, vous devez disposer des autorisations suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudWatchApplicationSignalsTaggingReadPermissions",
"Effect": "Allow",
"Action": "tag:GetResources",
"Resource": "*"
}
]
}
```
------
Pour vérifier si les signaux d'application sur Amazon EKS utilisant le [module complémentaire Amazon CloudWatch Observability EKS](install-CloudWatch-Observability-EKS-addon.md) sont activés, vous devez disposer des autorisations suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudWatchApplicationSignalsResourceExplorerReadPermissions",
"Effect": "Allow",
"Action": [
"resource-explorer-2:ListIndexes",
"resource-explorer-2:Search"
],
"Resource": "*"
},
{
"Sid": "CloudWatchApplicationSignalsResourceExplorerSLRPermissions",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"resource-explorer-2.amazonaws.com"
]
}
}
},
{
"Sid": "CloudWatchApplicationSignalsResourceExplorerCreateIndexPermissions",
"Effect": "Allow",
"Action": [
"resource-explorer-2:CreateIndex"
],
"Resource": "arn:aws:resource-explorer-2:*:*:index/*"
}
]
}
```
------
# Systèmes pris en charge
La vigie applicative est prise en charge et testé sur Amazon EKS, Kubernetes natif, Amazon ECS et Amazon EC2. Les instructions d'activation des signaux d'application sur Amazon EC2 doivent fonctionner sur toutes les plateformes prenant en charge l' CloudWatch agent et AWS la distribution pour. OpenTelemetry
**Topics**
+ [Java compatibility](#CloudWatch-Application-Signals-supportmatrix-java)
+ [Compatibilité .NET](#CloudWatch-Application-Signals-supportmatrix-dotnet)
+ [Compatibilité PHP](#php-compatibility)
+ [Compatibilité Ruby](#ruby-compatibility)
+ [Compatibilité Python](#CloudWatch-Application-Signals-supportmatrix-python)
+ [Compatibilité Node.js](#CloudWatch-Application-Signals-supportmatrix-node)
+ [GoLang compatibilité](#golang-compatibility)
+ [Matrice de prise en charge des versions d’exécution](#rumtime-version-matix)
+ [Problèmes connus](#AppSignals-Issues)
## Java compatibility
Application Signals prend en charge les applications Java et prend en charge les mêmes bibliothèques et frameworks Java que AWS Distro for OpenTelemetry . Pour plus d'informations, consultez [Bibliothèques, frameworks, serveurs d'applications et JVMs](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md).
## Compatibilité .NET
Application Signals prend en charge les mêmes bibliothèques et frameworks .NET que AWS Distro for OpenTelemetry . Pour plus d’informations, consultez la section [Instrumentations prises en charge](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/internal/instrumentation-libraries.md).
Application Signals prend en charge les applications .NET exécutées sur x86-64 ou ARM64 CPUs, et prend en charge Linux x64, Linux ARM64 et Microsoft Windows Server 2022 x64.
**Note**
Le SDK ADOT ( AWS Distro for Open Telemetry) pour .NET ne prend pas en charge le SDK pour .NET V4. AWS Utilisez le AWS SDK .NET V3 pour une prise en charge complète des signaux d'application.
## Compatibilité PHP
Application Signals prend en charge les applications PHP dotées d'une instrumentation OpenTelemetry Zero Code. Aucun SDK ADOT ( AWS Distro for Open Telemetry) n'est disponible à cette fin. Vous devez utiliser le SDK OpenTelemetry d'instrumentation standard avec la [recherche de transactions](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) activée. Pour commencer à utiliser l'instrumentation zéro code en PHP, suivez les étapes décrites dans la documentation OpenTelemetry PHP Instrumentation, [instrumentation code zéro PHP](https://opentelemetry.io/docs/zero-code/php/). L’instrumentation automatique est disponible pour un certain nombre de bibliothèques PHP couramment utilisées. Pour plus d'informations, consultez le [OpenTelemetry registre](https://packagist.org/search/?query=open-telemetry%3Dinstrumentation).
## Compatibilité Ruby
Application Signals prend en charge les applications Ruby dotées d'une instrumentation OpenTelemetry Zero Code. Aucun SDK ADOT ( AWS Distro for Open Telemetry) n'est disponible à cette fin. Vous devez utiliser le SDK OpenTelemetry d'instrumentation standard avec la [recherche de transactions](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) activée. Pour commencer à utiliser l'instrumentation zéro code dans Ruby, suivez les étapes décrites dans la documentation OpenTelemetry Ruby Instrumentation, [Ruby zero-code instrumentation](https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation). Pour obtenir la liste des bibliothèques d’instrumentation publiées, consultez [Registre](https://opentelemetry.io/ecosystem/registry/?language=rubycomponent=instrumentation).
## Compatibilité Python
Application Signals prend en charge les mêmes bibliothèques et frameworks que AWS Distro for OpenTelemetry . Pour plus d'informations, consultez la section **Packages pris en charge** à l'adresse [ opentelemetry-python-contrib](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation/README.md).
Avant d’activer la vigie applicative pour vos applications Python, tenez compte des considérations suivantes.
+ Dans certaines applications conteneurisées, l’absence de la variable d’environnement `PYTHONPATH` peut empêcher l’application de démarrer. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Cela est dû à un problème connu lié à l' OpenTelemetry auto-instrumentation. Pour plus d’informations sur ce problème, consultez la section [Le paramètre d’instrumentation automatique Python pour PYTHONPATH n’est pas conforme](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
+ Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la [documentation OpenTelemetry Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html).
+ Utilisez le paramètre `--noreload` pour empêcher le rechargement automatique.
+ Définissez la variable d’environnement `DJANGO_SETTINGS_MODULE` sur l’emplacement du fichier `settings.py` de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.
## Compatibilité Node.js
Application Signals prend en charge les mêmes bibliothèques et frameworks Node.js que AWS Distro for OpenTelemetry . Pour plus d’informations, consultez la section [Instrumentations prises en charge](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main).
### Limitations connues concernant Node.js avec ESM
La AWS distribution pour Opentelemetry Node.js prend en charge deux systèmes de ECMAScript modules : Modules (ESM) et CommonJS (CJS). Pour activer les signaux d'application, nous vous recommandons d'utiliser le format du module CJS car OpenTelemetry JavaScript le support d'ESM est expérimental et en cours de développement. Pour plus de détails, voir [ ECMAScript Modules vs CommonJS](https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/doc/esm-support.md) on GitHub.
Pour déterminer si votre application utilise CJS et non ESM, assurez-vous qu’elle ne remplit pas les conditions requises pour activer ESM. Pour plus d’informations sur ces conditions, consultez [Activation](https://nodejs.org/api/esm.html#enabling) dans la documentation Node.js.
The AWS Distro for Opentelemetry Node.js fournit un support limité pour ESM sur la base OpenTelemetry JavaScript du support expérimental pour ESM. Cela signifie que :
+ La version Node.js doit être 18.19.0 ou ultérieure.
+ L’application Node.js que vous voulez instrumenter doit inclure `@aws/aws-distro-opentelemetry-node-autoinstrumentation` et `@opentelemetry/instrumentation` en tant que dépendances.
+ L’application Node.js que vous voulez instrumenter doit démarrer avec l’option du nœud suivante :
```
NODE_OPTIONS=' --import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs'
```
Pour activer la vigie applicative avec le format de module ESM Node.js, nous proposons différentes configurations pour différentes plateformes :
+ **Amazon EKS** : [Configuration d’une application Node.js utilisant le format de module ESM](CloudWatch-Application-Signals-Enable-EKS.md#EKS-NodeJs-ESM)
+ **Amazon ECS avec stratégie sidecar** : [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Sidecar.md#ECS-NodeJs-ESM)
+ **Amazon ECS avec stratégie daemon** : [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-ECS-Daemon.md#ECSDaemon-NodeJs-ESM)
+ **Amazon ECS avec AWS CDK**
+ **Amazon EC2** : [Setting up a Node.js application with the ESM module format](CloudWatch-Application-Signals-Enable-EC2Main.md#EC2-NodeJs-ESM)
+ **Kubernetes** : [Configuration d’une application Node.js utilisant le format de module ESM](CloudWatch-Application-Signals-Enable-KubernetesMain.md#Kubernetes-NodeJs-ESM)
## GoLang compatibilité
Application Signals prend en charge GoLang les applications dotées d'une instrumentation OpenTelemetry Zero Code. Aucun SDK ADOT ( AWS Distro for Open Telemetry) n'est disponible à cette fin. Vous devez utiliser le SDK OpenTelemetry d'instrumentation standard avec la [recherche de transactions](AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) activée. Pour commencer à utiliser une instrumentation zéro code dans GoLang, suivez les étapes décrites dans la documentation d' OpenTelemetry GoLang instrumentation, [Getting Started with OpenTelemetry Go Automatic Instrumentation](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/getting-started.md).
### Considérations relatives à la mise GoLang en
Découvrez les détails importants relatifs à la mise en œuvre de l' GoLang instrumentation. Ce guide explique comment implémenter une propagation contextuelle explicite dans GoLang les applications et configurer les signaux d'application. La mise en œuvre correcte de l' GoLang instrumentation vous aide à suivre et à analyser efficacement les performances de votre application.
#### Instrumentation du SDK AWS
La bibliothèque d'auto-instrumentation Golang ne prend pas en charge l'instrumentation du AWS SDK prête à l'emploi. Vous devez utiliser l’instrumentation de la bibliothèque `otelaws` avec l’agent d’instrumentation automatique :
1. Installez la dépendance requise :
```
go get go.opentelemetry.io/contrib/instrumentation/github.com/aws/aws-sdk-go-v2/otelaws
```
1. Ajoutez la ligne suivante à l’application :
```
otelaws.AppendMiddlewares(&cfg.APIOptions)
```
1. Créez les AWS clients suivants avec l'`aws.Config`objet précédent :
```
s3Client := s3.NewFromConfig(cfg)
```
L'exemple suivant générera des intervalles pour les AWS appels et s'intègre à l'instrumentation automatique.
```
func handleRequest(ctx context.Context) error {
cfg, err := config.LoadDefaultConfig(ctx)
if err != nil {
return err
}
// Add OpenTelemetry instrumentation middleware to the AWS config
otelaws.AppendMiddlewares(&cfg.APIOptions)
// Create S3 client with the instrumented config
s3Client := s3.NewFromConfig(cfg)
// Now any operations with this client will be traced
// with the context from the upstream call
_, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
return err
}
```
Pour plus d’informations sur la configuration de l’exécutable d’instrumentation automatique, consultez [Méthodes de configuration](https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/main/docs/configuration.md).
#### Instrumentation des appels HTTP
Les appels HTTP peuvent diviser les traces lorsque le contexte n’est pas transmis entre les requêtes. Les clients HTTP doivent utiliser `NewRequestWithContext()` au lieu de `NewRequest()` pour s’assurer que le service en aval utilise le même contexte. Lorsque les deux services disposent d'agents d'instrumentation, les spans se connectent avec le même identifiant de trace pour garantir la end-to-end visibilité.
```
func makeDownstreamCall(ctx context.Context, url string) ([]byte, error) {
client := &http.Client{}
// Create request with context from the upstream call
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return nil, err
}
// Execute the request
resp, err := client.Do(req)
if err != nil {
return nil, err
}
defer resp.Body.Close()
}
```
#### Instrumentation des appels SQL
Les portées SQL peuvent être déconnectées de leur portée parent, ce qui entraîne l’interprétation des appels clients comme des portées serveur. Cela se produit lorsque les appels SQL ne reçoivent pas le contexte de leurs gestionnaires en amont. Les appels SQL standard tels que `Query` et `Exec` utilisent `context.Background()` par défaut, et non le contexte de l’appelant en amont. Remplacez les appels SQL standard par leurs équivalents sensibles au contexte :
+ Utilisez `QueryContext` au lieu de `Query`
+ Utilisez `ExecContext` au lieu de `Exec`
Ces méthodes transmettent le contexte de la requête en amont aux appels de base de données, ce qui permet de maintenir une continuité de trace appropriée.
```
func queryDatabase(ctx context.Context, db *sql.DB, userID string) (*sql.Rows, error) {
// This breaks the trace context
// row := db.Query("SELECT name FROM users WHERE id = $1", userID)
// This passes the context from the upstream call for trace continuity
rows, err := db.QueryContext(ctx, "SELECT name FROM users WHERE id = $1", userID)
return rows, error
}
```
**Note**
L’attribut `db.system` n’est actuellement pas pris en charge pour les appels SQL. Cette limitation affecte la CloudWatch capacité à identifier avec précision les clients de base de données. Par conséquent, les dépendances s'afficheront à la **UnknownRemoteService**place du nom du client de base de données effectuant la requête.
#### Détecteurs de ressources
L’instrumentation automatique Go ne prend actuellement pas en charge la configuration des détecteurs de ressources lors de l’exécution. La OpenTelemetry communauté travaille sur une fonctionnalité permettant de configurer les détecteurs de ressources à l'aide de variables d'environnement. Cette fonctionnalité sera disponible dans une prochaine mise à jour. Dans l'intervalle, vous pouvez utiliser l' CloudWatch agent avec une instrumentation automatique pour générer automatiquement les attributs des ressources de l'hôte.
## Matrice de prise en charge des versions d’exécution
| Language | Version d'environnement d'exécution |
| --- | --- |
| Java | Versions JVM 8, 11, 17, 21 et 23 |
| Python | Les versions Python 3.9 et supérieures sont prises en charge |
| .NET | La version 1.6.0 et les versions antérieures prennent en charge .NET 6, 8 et .NET Framework 4.6.2 et supérieures La version 1.7.0 et les versions supérieures prennent en charge .NET 8, 9 et .NET Framework 4.6.2 et supérieures |
| Node.js | Versions Node.js 14, 16, 18, 20 et 22 |
| PHP | Versions PHP 8.0 et supérieures |
| Ruby | CRuby >= 3,1, JRuby >= 9.3.2.0, ou >= 22,1 TruffleRuby |
| GoLang | Versions Golang 1.18 et supérieures |
## Problèmes connus
La collecte de métriques d'exécution dans la version v1.32.5 du SDK Java est connue pour ne pas fonctionner avec les applications utilisant Wildfly. JBoss Ce problème s'étend au module complémentaire Amazon CloudWatch Observability EKS, affectant les `2.3.0-eksbuild.1` versions `2.6.0-eksbuild.1` suivantes. Le problème est résolu dans la version du SDK Java `v1.32.6` et dans la version complémentaire Amazon CloudWatch Observability EKS. `v3.0.0-eksbuild.1`
Si vous êtes concerné, mettez à niveau la version du kit SDK Java ou désactivez la collecte des métriques d’exécution en ajoutant la variable d’environnement `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` à votre application.
# Configurations d’instrumentation prises en charge
Vous pouvez activer les signaux CloudWatch d'application avec différentes configurations d'instrumentation. Cette rubrique décrit chacune des méthodes de configuration et les recommandations en fonction de la méthode que vous choisissez.
## Utiliser AWS Distro pour utiliser OpenTelemetry l'agent CloudWatch
L'expérience de surveillance des performances des applications (APM) la plus intégrée qui CloudWatch soit est fournie via AWS Distro for OpenTelemetry (ADOT) SDKs et est utilisée avec l' CloudWatch agent pour collecter des métriques et des traces d'applications. Cette option est idéale si vous souhaitez démarrer CloudWatch rapidement avec l'APM et tirer parti des intégrations de out-of-the box avec des fonctionnalités telles que Container Insights et CloudWatch Logs. Pour plus d’informations, consultez [Activer la vigie applicative sur les clusters Amazon EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-EKS.html) et [Activer la vigie applicative sur Amazon EC2, Amazon ECS ou Kubernetes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-Other.html).
## Utiliser le OpenTelemetry SDK et le collecteur
Cette configuration convient aux cas d’utilisation suivants :
1. Vous avez instrumenté votre application ou votre plan avec Collector OpenTelemetry SDKs et vous utilisez actuellement OpenTelemetry Collector.
1. Vous utilisez des langages, tels que Erlang et Rust, qui ne sont pas pris en charge par AWS Distro for OpenTelemetry (ADOT).
Pour plus d'informations, reportez-vous à la section [OpenTelemetry avec CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-OpenTelemetry-Sections.html).
## Utiliser le AWS X-Ray SDK et le daemon
Cette option est préférable si vous avez instrumenté votre application à l'aide de X-Ray SDKs et que vous n'avez pas migré SDKs ADOT ou. OpenTelemetry SDKs
Pour plus d’informations, consultez [Recherche de transactions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html).
## Comparaison des fonctionnalités
| Fonctionnalité | ADOT SDK \$1 Agent CloudWatch | Ouvrez le SDK de télémétrie \$1 Collector OpenTelemetry | X-Ray SDKs |
| --- | --- | --- | --- |
| AWS Support | Oui | Uniquement pour les données envoyées à AWS | Oui |
| Prise en charge des langages non standard | Non | Oui | Non |
| Intégration Container Insights | Oui | Non | Non |
| Journalisation prête à l'emploi avec CloudWatch Logs | Oui | Non | Non |
| Métriques d’exécution prêtes à l’emploi | Oui | Non | Non |
| Obtient toujours des métriques sur 100 % du trafic | Oui | Uniquement à un taux d’échantillonnage de 100 % | Uniquement à un taux d’échantillonnage de 100 % |
# Activation de la vigie applicative dans votre compte
Si vous n’avez pas encore activé Application Signals dans ce compte, vous devez accorder à Application Signals les autorisations nécessaires pour découvrir vos services. Cette opération ne doit être effectuée qu’une seule fois par compte.
**Pour activer les signaux CloudWatch d'application, procédez comme suit.**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Services**.
1. Choisissez **Commencer à découvrir vos services**.
1. Cochez la case et choisissez **Commencer à découvrir les services**.
Si vous effectuez cette étape pour la première fois dans votre compte, le rôle **AWSServiceRoleForCloudWatchApplicationSignals**lié au service est créé. Ce rôle accorde à Application Signals les autorisations suivantes :
+ `xray:GetServiceGraph`
+ `logs:StartQuery`
+ `logs:GetQueryResults`
+ `cloudwatch:GetMetricData`
+ `cloudwatch:ListMetrics`
+ `tag:GetResources`
Pour plus d’informations sur ce rôle, consultez [Autorisations de rôle liées au service pour les signaux d'application CloudWatch](using-service-linked-roles.md#service-linked-role-signals).
1. Choisissez **Activer Application Signals**.
# (Facultatif) Tester la vigie applicative avec un exemple d’application
Pour tester CloudWatch Application Signals sur un exemple d'application avant de l'utiliser pour vos propres applications, suivez les instructions de cette section. Ces instructions utilisent des scripts pour vous aider à créer un cluster Amazon EKS, à installer un exemple d’application et à équiper l’exemple d’application pour qu’il fonctionne avec Application Signals.
L’exemple d’application est une application Spring « Pet Clinic » composée de quatre microservices. Ces services s’exécutent sur Amazon EKS sur Amazon EC2 et utilisent les scripts d’activation de la vigie applicative pour activer le cluster avec l’agent d’instrumentation automatique Java, Python ou .NET.
**Exigences**
+ La vigie applicative surveille uniquement les applications Java, Python ou .NET.
+ Vous devez l'avoir AWS CLI installé sur l'instance. Nous recommandons AWS CLI la version 2, mais la version 1 devrait également fonctionner. Pour plus d'informations sur l'installation du AWS CLI, voir [Installer ou mettre à jour la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ Les scripts de cette section sont destinés à être exécutés dans des environnements Linux et macOS. Pour les instances Windows, nous vous recommandons d'utiliser un AWS Cloud9 environnement pour exécuter ces scripts. Pour plus d'informations AWS Cloud9, voir [Qu'est-ce que c'est AWS Cloud9 ?](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) .
+ Installez une version prise en charge de `kubectl`. Vous devez utiliser une version de `kubectl` qui se situe à une différence de version mineure près de celle du plan de contrôle de votre cluster Amazon EKS. Par exemple, un client `kubectl` 1.26 fonctionne avec les clusters Kubernetes 1.25, 1.26 et 1.27. Si vous possédez déjà un cluster Amazon EKS, vous devrez peut-être configurer les AWS informations d'identification pour`kubectl`. Pour plus d’informations, veuillez consulter la rubrique [Création ou mise à jour d’un fichier `kubeconfig` pour un cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html).
+ Installez`eksctl`. `eksctl`utilise le AWS CLI pour interagir avec AWS, ce qui signifie qu'il utilise les mêmes AWS informations d'identification que le AWS CLI. Pour plus d’informations, veuillez consulter la rubrique [Installation ou mise à jour de `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html).
+ Installez `jq`. `jq` est nécessaire pour exécuter les scripts d’activation d’Application Signals. Pour plus d’informations, veuillez consulter la rubrique [Télécharger jq](https://jqlang.github.io/jq/download/).
## Étape 1 : télécharger les scripts
Pour télécharger les scripts permettant de configurer CloudWatch Application Signals avec un exemple d'application, vous pouvez télécharger et décompresser le fichier de GitHub projet compressé sur un lecteur local, ou vous pouvez cloner le GitHub projet.
Pour cloner le projet, ouvrez une fenêtre de terminal et saisissez la commande Git suivante dans un répertoire de travail donné.
```
git clone https://github.com/aws-observability/application-signals-demo.git
```
## Étape 2 : générer et déployer l’exemple d’application
Pour générer et diffuser les exemples d’images d’application, [suivez ces instructions](https://github.com/aws-observability/application-signals-demo?tab=readme-ov-file#build-the-sample-application-images-and-push-to-ecr).
### Étape 3 : déployer et activer Application Signals et l’exemple d’application
Assurez-vous d’avoir rempli les exigences listées dans [(Facultatif) Tester la vigie applicative avec un exemple d’application](#CloudWatch-Application-Signals-Enable-EKS-sample) avant de suivre les étapes suivantes.
**Pour déployer et activer Application Signals et l’exemple d’application**
1. Entrez la commande suivante. *new-cluster-name*Remplacez-le par le nom que vous souhaitez utiliser pour le nouveau cluster. Remplacez *region-name* par le nom de la AWS région, tel que`us-west-1`.
Cette commande configure l’exemple d’application s’exécutant dans un nouveau cluster Amazon EKS avec Application Signals activés.
```
# this script sets up a new cluster, enables Application Signals, and deploys the
# sample application
cd application-signals-demo/scripts/eks/appsignals/one-step && ./setup.sh new-cluster-name region-name
```
L’exécution du script d’installation prend environ 30 minutes et effectue les opérations suivantes :
+ création d’un cluster Amazon EKS dans la région spécifiée ;
+ création des autorisations IAM nécessaires pour Application Signals (`arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess` et `arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy`) ;
+ Active les signaux d'application en installant l' CloudWatch agent et en instrumentant automatiquement l'exemple d'application pour les CloudWatch métriques et les traces X-Ray.
+ Déploie l'exemple d'application PetClinic Spring dans le même cluster Amazon EKS.
+ Crée cinq CloudWatch canaris Synthetics, `pc-add-vist` nommés`pc-create-owners`,,,,. `pc-visit-pet` `pc-visit-vet` `pc-clinic-traffic` Ces scripts canary fonctionneront à une fréquence d’une minute afin de générer du trafic synthétique pour l’exemple d’application et de montrer comment les scripts canary Synthetics apparaissent dans Application Signals ;
+ Crée quatre objectifs de niveau de service (SLOs) pour l' PetClinic application portant les noms suivants :
+ **Disponibilité pour la recherche d’un propriétaire**
+ **Latence lors de la recherche d’un propriétaire**
+ **Disponibilité pour l’enregistrement d’un propriétaire**
+ **Latence lors de l’enregistrement d’un propriétaire**
+ création du rôle IAM requis avec une politique de confiance personnalisée accordant à Application Signals les autorisations suivantes :
+ `cloudwatch:PutMetricData`
+ `cloudwatch:GetMetricData`
+ `xray:GetServiceGraph`
+ `logs:StartQuery`
+ `logs:GetQueryResults`
1. (Facultatif) Si vous souhaitez consulter le code source de l' PetClinic exemple d'application, vous pouvez le trouver dans le dossier racine.
```
- application-signals-demo
- spring-petclinic-admin-server
- spring-petclinic-api-gateway
- spring-petclinic-config-server
- spring-petclinic-customers-service
- spring-petclinic-discovery-server
- spring-petclinic-vets-service
- spring-petclinic-visits-service
```
1. Pour afficher l' PetClinic exemple d'application déployé, exécutez la commande suivante pour trouver l'URL :
```
kubectl get ingress
```
### Étape 4 : surveiller l’exemple d’application
Après avoir effectué les étapes décrites dans la section précédente pour créer le cluster Amazon EKS et déployer l’exemple d’application, vous pouvez utiliser Application Signals pour surveiller l’application.
**Note**
Pour que la console Application Signals commence à se remplir, une partie du trafic doit atteindre l’exemple d’application. Les étapes précédentes ont notamment permis de créer des canaris CloudWatch Synthetics qui génèrent du trafic vers l'exemple d'application.
#### Surveillance de l’intégrité du service
Une fois activé, CloudWatch Application Signals découvre et remplit automatiquement une liste de services sans nécessiter de configuration supplémentaire.
**Pour consulter la liste des services découverts et surveiller leur état**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation du service, choisissez **Application Signals**, **Services**.
1. Pour afficher un service, ses opérations et ses dépendances, choisissez le nom de l’un des services de la liste.
Cette vue unifiée centrée sur les applications permet d’avoir une vision complète de la manière dont les utilisateurs interagissent avec votre service. Cela peut vous aider à trier les problèmes en cas d’anomalies de performances. Pour plus de détails sur la vue **Services**, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
1. Choisissez l’onglet **Opérations de service** pour voir les métriques d’application standard pour les opérations de ce service. Les opérations sont, par exemple, les opérations d’API que le service appelle.
Ensuite, pour afficher les graphiques d’une seule opération de ce service, choisissez le nom de cette opération.
1. Cliquez sur l’onglet **Dépendances** pour voir les dépendances de votre application, ainsi que les mesures d’application critiques pour chaque dépendance. Les dépendances incluent AWS les services et les services tiers appelés par votre application.
1. Pour afficher les suivis corrélés depuis la page des détails du service, choisissez un point de données dans l’un des trois graphiques situés au-dessus du tableau. Cela remplit un nouveau volet avec les suivis filtrés de la période. Ces suivis sont triés et filtrés en fonction du graphique que vous avez choisi. Par exemple, si vous avez choisi le graphique de **latence**, les suivis sont triés en fonction du temps de réponse du service.
1. Dans le volet de navigation de la CloudWatch console, choisissez **SLOs**. Vous voyez SLOs ce que le script a créé pour l'exemple d'application. Pour plus d'informations sur SLOs, voir[Objectifs de niveau de service (SLOs)](CloudWatch-ServiceLevelObjectives.md).
### (Facultatif) Étape 5 : nettoyage
Lorsque vous avez terminé de tester Application Signals, vous pouvez utiliser un script fourni par Amazon pour nettoyer et supprimer les artefacts créés dans votre compte pour l’exemple d’application. Pour effectuer le nettoyage, saisissez la commande suivante. Remplacez *new-cluster-name* par le nom du cluster que vous avez créé pour l'exemple d'application, et remplacez *region* -name par le nom de la AWS région, tel que`us-west-1`.
```
cd application-signals-demo/scripts/eks/appsignals/one-step && ./cleanup.sh new-cluster-name region-name
```
# Activation de vos applications sur des clusters Amazon EKS
CloudWatch Application Signals est pris en charge pour les applications Java, Python, Node.js et .NET. Pour activer les signaux d'application pour vos applications sur un cluster Amazon EKS existant, vous pouvez utiliser la AWS Management Console configuration avancée Auto monitor du module complémentaire CloudWatch Observability. AWS CDK
**Topics**
+ [Activation de la vigie applicative sur un cluster Amazon EKS à l’aide de la console](#CloudWatch-Application-Signals-Enable-EKS-Console)
+ [Activez les signaux d'application sur un cluster Amazon EKS à l'aide de la configuration avancée du module complémentaire CloudWatch Observability](#CloudWatch-Application-Signals-Enable-EKS-Addon)
+ [Activez les signaux d'application sur Amazon EKS à l'aide de AWS CDK](#CloudWatch-Application-Signals-EKS-CDK)
+ [Activez les signaux d'application sur Amazon EKS à l'aide du protocole MCP (Model Context Protocol)](#CloudWatch-Application-Signals-EKS-MCP)
## Activation de la vigie applicative sur un cluster Amazon EKS à l’aide de la console
Pour activer les signaux CloudWatch d'application sur vos applications sur un cluster Amazon EKS existant, suivez les instructions de cette section.
**Important**
Si vous utilisez OpenTelemetry déjà une application que vous avez l'intention d'activer pour les signaux d'application, consultez la section [Systèmes pris en charge](CloudWatch-Application-Signals-supportmatrix.md) avant d'activer les signaux d'application.
**Pour activer Application Signals pour vos applications sur un cluster Amazon EKS existant**
**Note**
Si vous n’avez pas encore activé la vigie applicative, suivez d’abord les instructions indiquées dans la section [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md), puis suivez la procédure ci-dessous.
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Sélectionnez **Vigie applicative**.
1. Pour **Spécifier la plateforme**, choisissez **EKS**.
1. Pour **Sélectionner un cluster EKS**, sélectionnez le cluster dans lequel vous souhaitez activer Application Signals.
1. Si le module complémentaire Amazon CloudWatch Observability EKS n'est pas encore activé sur ce cluster, vous êtes invité à l'activer. Dans ce cas, vous pouvez procéder de l’une des façons suivantes :
1. Choisissez **Ajouter le module complémentaire CloudWatch Observability EKS**. La console Amazon EKS apparaît.
1. Cochez la case **Amazon CloudWatch Observability** et choisissez **Next**.
Le module complémentaire CloudWatch Observability EKS active à la fois les signaux d'application et les informations sur les CloudWatch conteneurs avec une observabilité améliorée pour Amazon EKS. Pour plus d'informations sur Container Insights, consultez [Container Insights](ContainerInsights.md).
1. Sélectionnez la version la plus récente du module complémentaire à installer.
1. Sélectionnez un rôle IAM à utiliser pour le module complémentaire. Si vous choisissez **Hériter du nœud**, attachez les autorisations appropriées au rôle IAM utilisé par vos composants master. Remplacez *my-worker-node-role* par le rôle IAM utilisé par vos composants master Kubernetes.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--policy-arn arn:aws:iam::aws:policy/AWSXRayWriteOnlyAccess
```
1. Si vous souhaitez créer une fonction du service pour utiliser le module complémentaire, veuillez consulter [Installez l' CloudWatch agent avec le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm](install-CloudWatch-Observability-EKS-addon.md).
1. Choisissez **Suivant**, confirmez les informations affichées à l’écran, puis choisissez **Créer**.
1. Dans l'écran suivant, choisissez **Enable CloudWatch Application Signals** pour revenir à la CloudWatch console et terminer le processus.
1. Il existe deux options pour activer vos applications pour la vigie applicative. Pour plus de cohérence, il est recommandé de choisir une seule option par cluster.
+ L’option **Console** est plus simple. L’utilisation de cette méthode entraîne le redémarrage immédiat de vos pods.
+ La méthode **Fichier manifeste annoté** vous permet de mieux contrôler le moment où vos pods redémarrent et peut également vous aider à gérer votre surveillance de manière plus décentralisée si vous ne souhaitez pas la centraliser.
**Note**
Si vous activez la vigie applicative pour une application Node.js utilisant le format ESM, passez directement à [Configuration d’une application Node.js utilisant le format de module ESM](#EKS-NodeJs-ESM).
------
#### [ Console ]
L'option **Console** utilise la configuration avancée du module complémentaire Amazon CloudWatch Observability EKS pour configurer les signaux d'application pour vos services. Pour plus d’informations sur le module complémentaire, consultez [(Facultatif) Configuration supplémentaire](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration).
Si la liste des charges de travail et des espaces de noms ne s’affiche pas, assurez-vous de disposer des autorisations appropriées pour accéder à ces ressources dans ce cluster. Pour plus de détails, consultez la section [Autorisations requises](https://docs.aws.amazon.com/eks/latest/userguide/view-kubernetes-resources.html#view-kubernetes-resources-permissions).
Vous pouvez soit surveiller toutes les charges de travail des services en cochant la case **Surveillance automatique**, soit sélectionner des charges de travail et des espaces de noms spécifiques à surveiller.
Pour activer la surveillance automatique de toutes les charges de travail, procédez comme suit :
1. Cochez la case **Surveillance automatique** pour sélectionner automatiquement toutes les charges de travail du service dans le cluster.
1. Choisissez **Auto restart pour redémarrer** tous les pods de charge de travail afin d'activer immédiatement les signaux d'application grâce à l' SDKs injection de AWS Distro for OpenTelemetry Auto-Instrumentation (ADOT) dans vos pods.
1. Sélectionnez **Exécuté**. Lorsque le **redémarrage automatique** est sélectionné, le module complémentaire CloudWatch Observability EKS active immédiatement les signaux d'application. Sinon, la vigie applicative sera activé lors du prochain déploiement de chaque charge de travail.
Vous pouvez surveiller une charge de travail unique ou un espace de noms entier.
Pour surveiller une seule charge de travail :
1. Cochez la case correspondant à la charge de travail que vous souhaitez surveiller.
1. Utilisez la liste déroulante **Sélectionner langage(s)** pour sélectionner le langage de la charge de travail. Sélectionnez le ou les langages pour lesquels vous souhaitez activer la vigie applicative, puis cliquez sur l’icône en forme de coche (✓) pour enregistrer votre sélection.
Pour les applications Python, assurez-vous que votre application répond aux prérequis avant de continuer. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
1. Sélectionnez **Exécuté**. Le module complémentaire Amazon CloudWatch Observability EKS injectera immédiatement AWS Distro for OpenTelemetry autoinstrumentation (ADOT) SDKs dans vos pods et déclenchera le redémarrage des pods pour permettre la collecte de métriques et de traces d'applications.
Pour surveiller un espace de noms complet :
1. Cochez la case correspondant à l’espace de noms que vous souhaitez surveiller.
1. Utilisez la liste déroulante **Sélectionner langage(s)** pour sélectionner le langage de l’espace de noms. Sélectionnez le ou les langages pour lesquels vous souhaitez activer la vigie applicative, puis cliquez sur l’icône en forme de coche (✓) pour enregistrer votre sélection. Cela s’applique à toutes les charges de travail de cet espace de noms, qu’elles soient actuellement déployées ou déployées ultérieurement.
Pour les applications Python, assurez-vous que votre application répond aux prérequis avant de continuer. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
1. Sélectionnez **Exécuté**. Le module complémentaire Amazon CloudWatch Observability EKS injectera immédiatement AWS Distro for OpenTelemetry autoinstrumentation (ADOT) SDKs dans vos pods et déclenchera le redémarrage des pods pour permettre la collecte de métriques et de traces d'applications.
Pour activer Application Signals dans un autre cluster Amazon EKS, choisissez **Activer Application Signals** dans l’écran **Services**.
------
#### [ Annotate manifest file ]
Dans la CloudWatch console, la section **Monitor Services** explique que vous devez ajouter une annotation à un manifeste YAML du cluster. L’ajout de cette annotation permet à l’application d’envoyer automatiquement des métriques, des suivis et des journaux à Application Signals.
Vous avez deux options pour l’annotation :
+ **Annoter une charge de travail** instrumente automatiquement une seule charge de travail dans le cluster.
+ **Annoter l’espace de noms** permet d’instrumenter automatiquement toutes les charges de travail déployées dans l’espace de noms sélectionné.
Choisissez l’une de ces options, puis suivez les étapes appropriées :
+ Pour annoter une seule charge de travail :
1. Choisissez **Annoter la charge de travail**.
1. Collez l’une des lignes suivantes dans la section `PodTemplate` du fichier manifeste de la charge de travail :
+ **Pour les charges de travail Java :** `annotations: instrumentation.opentelemetry.io/inject-java: "true"`
+ **Pour les charges de travail Python :** `annotations: instrumentation.opentelemetry.io/inject-python: "true"`
Pour les applications Python, des configurations supplémentaires sont requises. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
+ **Pour les charges de travail .NET** `annotations: instrumentation.opentelemetry.io/inject-dotnet: "true"`
**Note**
Pour activer la vigie applicative pour une charge de travail .NET exécutée sur des images basées sur Alpine Linux (`linux-musl-x64`), ajoutez l’annotation suivante :
```
instrumentation.opentelemetry.io/otel-dotnet-auto-runtime: "linux-musl-x64"
```
+ **Pour les charges de travail Node.js :** `annotations: instrumentation.opentelemetry.io/inject-nodejs: "true"`
1. Dans votre terminal, saisissez `kubectl apply -f your_deployment_yaml` pour appliquer la modification.
+ Pour annoter toutes les charges de travail dans un espace de noms :
1. Choisissez **Annoter l’espace de noms**.
1. Collez l’une des lignes suivantes dans la section des métadonnées du fichier manifeste de l’espace de noms. Si l’espace de noms contient des charges de travail Java, Python, .NET ou Node.js, insérez toutes les lignes suviantes dans le fichier manifeste de l’espace de noms :
+ **Si l’espace de noms contient des charges de travail Java :** `annotations: instrumentation.opentelemetry.io/inject-java: "true"`
+ **Si l’espace de noms contient des charges de travail Python :** `annotations: instrumentation.opentelemetry.io/inject-python: "true"`
Pour les applications Python, des configurations supplémentaires sont requises. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
+ **Si l’espace de noms contient des charges de travail .NET :** `annotations: instrumentation.opentelemetry.io/inject-dotnet: "true"`
+ **Si l’espace de noms contient des charges de travail Node.js :** `annotations: instrumentation.opentelemetry.io/inject-nodejs: "true"`
1. Dans votre terminal, saisissez `kubectl apply -f your_namespace_yaml` pour appliquer la modification.
1. Dans votre terminal, saisissez une commande pour redémarrer tous les pods de l’espace de noms. Voici un exemple de commande pour redémarrer les charges de travail de déploiement : `kubectl rollout restart deployment -n namespace_name`
------
1. Choisissez **Afficher les services lorsque vous avez terminé**. Cela vous amène à la vue Services d’Application Signals, où vous pouvez voir les données collectées par Application Signals. Les données peuvent prendre quelques minutes pour s’afficher.
Pour activer Application Signals dans un autre cluster Amazon EKS, choisissez **Activer Application Signals** dans l’écran **Services**.
Pour plus d’informations sur la vue **Services**, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
**Note**
Si vous utilisez un serveur WSGI pour votre application Python, consultez [Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-Python-WSGI) pour connaître les étapes nécessaires à la compatibilité avec la vigie applicative.
D’autres points importants concernant la configuration des applications Python pour la vigie applicative sont également détaillés dans cette documentation. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
### Configuration d’une application Node.js utilisant le format de module ESM
Un support limité est disponible pour les applications Node.js utilisant le format de module ESM. Pour en savoir plus, consultez [Limitations connues concernant Node.js avec ESM](CloudWatch-Application-Signals-supportmatrix.md#ESM-limitations).
Pour le format du module ESM, l’activation de la vigie applicative via la console ou par annotation du fichier manifeste n’est pas prise en charge. Ignorez l’étape 8 de la procédure précédente et procédez plutôt comme suit.
**Pour activer la vigie applicative pour une application Node.js avec ESM**
1. Installez les dépendances nécessaires à l’instrumentation automatique dans votre application Node.js :
```
npm install @aws/aws-distro-opentelemetry-node-autoinstrumentation
npm install @opentelemetry/instrumentation@0.54.0
```
1. Ajoutez les variables d’environnement suivantes au Dockerfile de votre application, puis construisez l’image.
```
...
ENV OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true
ENV OTEL_TRACES_SAMPLER_ARG='endpoint=http://cloudwatch-agent.amazon-cloudwatch:2000'
ENV OTEL_TRACES_SAMPLER='xray'
ENV OTEL_EXPORTER_OTLP_PROTOCOL='http/protobuf'
ENV OTEL_EXPORTER_OTLP_TRACES_ENDPOINT='http://cloudwatch-agent.amazon-cloudwatch:4316/v1/traces'
ENV OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT='http://cloudwatch-agent.amazon-cloudwatch:4316/v1/metrics'
ENV OTEL_METRICS_EXPORTER='none'
ENV OTEL_LOGS_EXPORTER='none'
ENV NODE_OPTIONS='--import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs'
ENV OTEL_SERVICE_NAME='YOUR_SERVICE_NAME' #replace with a proper service name
ENV OTEL_PROPAGATORS='tracecontext,baggage,b3,xray'
...
# command to start the application
# for example
# CMD ["node", "index.mjs"]
```
1. Ajoutez les variables d’environnement `OTEL_RESOURCE_ATTRIBUTES_POD_NAME`, `OTEL_RESOURCE_ATTRIBUTES_NODE_NAME`, `OTEL_RESOURCE_ATTRIBUTES_DEPLOYMENT_NAME`, `POD_NAMESPACE` et `OTEL_RESOURCE_ATTRIBUTES` au fichier YAML de déploiement de votre application. Par exemple :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nodejs-app
labels:
app: nodejs-app
spec:
replicas: 2
selector:
matchLabels:
app: nodejs-app
template:
metadata:
labels:
app: nodejs-app
# annotations:
# make sure this annotation doesn't exit
# instrumentation.opentelemetry.io/inject-nodejs: 'true'
spec:
containers:
- name: nodejs-app
image:your-nodejs-application-image #replace with a proper image uri
imagePullPolicy: Always
ports:
- containerPort: 8000
env:
- name: OTEL_RESOURCE_ATTRIBUTES_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: OTEL_RESOURCE_ATTRIBUTES_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: OTEL_RESOURCE_ATTRIBUTES_DEPLOYMENT_NAME
valueFrom:
fieldRef:
fieldPath: metadata.labels['app'] # Assuming 'app' label is set to the deployment name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: OTEL_RESOURCE_ATTRIBUTES
value: "k8s.deployment.name=$(OTEL_RESOURCE_ATTRIBUTES_DEPLOYMENT_NAME),k8s.namespace.name=$(POD_NAMESPACE),k8s.node.name=$(OTEL_RESOURCE_ATTRIBUTES_NODE_NAME),k8s.pod.name=$(OTEL_RESOURCE_ATTRIBUTES_POD_NAME)"
```
1. Déployez l’application Node.js sur le cluster.
Une fois vos applications activées sur les clusters Amazon EKS, vous pouvez surveiller leur état. Pour de plus amples informations, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
## Activez les signaux d'application sur un cluster Amazon EKS à l'aide de la configuration avancée du module complémentaire CloudWatch Observability
Par défaut, la surveillance des performances des applications OpenTelemetry (APM) basée sur (OTEL) est activée via les signaux d'application lors de l'installation du module complémentaire CloudWatch Observability EKS (V5.0.0 ou supérieur) ou du graphique Helm. Vous pouvez ensuite personnaliser certains paramètres spécifiques à l’aide de la configuration avancée du module complémentaire Amazon EKS ou en remplaçant certaines valeurs dans les Charts de Helm.
**Note**
Si vous utilisez une solution APM basée sur OpenTelemetry (OTEL), l'activation des signaux d'application affecte votre configuration d'observabilité existante. Passez en revue votre implémentation actuelle avant de continuer. Pour conserver votre configuration APM existante après la mise à niveau vers la version 5.0.0 ou ultérieure, consultez. [Désactiver les signaux d'application](install-CloudWatch-Observability-EKS-addon.md#Opting-out-App-Signals)
CloudWatch Le module complémentaire Observability fournit également un contrôle précis supplémentaire pour inclure ou exclure des services spécifiques selon les besoins dans la nouvelle configuration avancée. Pour plus d’informations, consultez [Activation de l'APM via des signaux d'application pour votre cluster Amazon EKS](install-CloudWatch-Observability-EKS-addon.md#Container-Insights-setup-EKS-appsignalsconfiguration).
## Activez les signaux d'application sur Amazon EKS à l'aide de AWS CDK
Si vous n’avez pas encore activé Application Signals dans ce compte, vous devez accorder à Application Signals les autorisations nécessaires pour découvrir vos services. Consultez [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md).
1. Activation de la vigie applicative pour vos applications.
```
import { aws_applicationsignals as applicationsignals } from 'aws-cdk-lib';
const cfnDiscovery = new applicationsignals.CfnDiscovery(this,
'ApplicationSignalsServiceRole', { }
);
```
La CloudFormation ressource Discovery accorde à Application Signals les autorisations suivantes :
+ `xray:GetServiceGraph`
+ `logs:StartQuery`
+ `logs:GetQueryResults`
+ `cloudwatch:GetMetricData`
+ `cloudwatch:ListMetrics`
+ `tag:GetResources`
Pour plus d’informations sur ce rôle, consultez [Autorisations de rôle liées au service pour les signaux d'application CloudWatch](using-service-linked-roles.md#service-linked-role-signals).
1. Installez le module complémentaire `amazon-cloudwatch-observability`.
1. Créez un rôle IAM avec la `CloudWatchAgentServerPolicy` et l’OIDC associés au cluster.
```
const cloudwatchRole = new Role(this, 'CloudWatchAgentAddOnRole', {
assumedBy: new OpenIdConnectPrincipal(cluster.openIdConnectProvider),
managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('CloudWatchAgentServerPolicy')],
});
```
1. Installez le module complémentaire avec le rôle IAM créé ci-dessus.
```
new CfnAddon(this, 'CloudWatchAddon', {
addonName: 'amazon-cloudwatch-observability',
clusterName: cluster.clusterName,
serviceAccountRoleArn: cloudwatchRole.roleArn
});
```
1. Ajoutez l’une des lignes suivantes dans la section `PodTemplate` du fichier manifeste de votre charge de travail.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-EKS.html)
```
const deployment = {
apiVersion: "apps/v1",
kind: "Deployment",
metadata: { name: "sample-app" },
spec: {
replicas: 3,
selector: {
matchLabels: {
"app": "sample-app"
}
},
template: {
metadata: {
labels: {
"app": "sample-app"
},
annotations: {
"instrumentation.opentelemetry.io/inject-$LANG": "true"
}
},
spec: {...},
},
},
};
cluster.addManifest('sample-app', deployment)
```
## Activez les signaux d'application sur Amazon EKS à l'aide du protocole MCP (Model Context Protocol)
Vous pouvez utiliser le serveur MCP ( CloudWatch Application Signals Model Context Protocol) pour activer les signaux d'application sur vos clusters Amazon EKS par le biais d'interactions conversationnelles avec l'IA. Cela fournit une interface en langage naturel pour configurer la surveillance des signaux d'application.
Le serveur MCP automatise le processus d'activation en comprenant vos besoins et en générant la configuration appropriée. Au lieu de suivre manuellement les étapes de la console ou d'écrire du code CDK, vous pouvez simplement décrire ce que vous souhaitez activer.
### Conditions préalables
Avant d'utiliser le serveur MCP pour activer les signaux d'application, assurez-vous d'avoir :
+ Un environnement de développement compatible avec MCP (tel que Kiro, Claude Desktop, VSCode avec des extensions MCP ou d'autres outils compatibles avec MCP)
+ Le serveur MCP CloudWatch Application Signals configuré dans votre IDE. Pour obtenir des instructions de configuration détaillées, consultez la [documentation du serveur MCP CloudWatch Application Signals](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
### Utilisation du serveur MCP
Une fois que vous avez configuré le serveur MCP CloudWatch Application Signals dans votre IDE, vous pouvez demander des conseils d'activation à l'aide d'instructions en langage naturel. Bien que l'assistant de codage puisse déduire le contexte à partir de la structure de votre projet, le fait de fournir des informations spécifiques dans vos instructions permet de garantir des conseils plus précis et plus pertinents. Incluez des informations telles que la langue de votre application, le nom du cluster Amazon EKS et les chemins absolus vers votre infrastructure et votre code d'application.
**Instructions relatives aux meilleures pratiques (spécifiques et complètes) :**
```
"Enable Application Signals for my Python service running on EKS.
My app code is in /home/user/flask-api and IaC is in /home/user/flask-api/terraform"
"I want to add observability to my Node.js application on EKS cluster 'production-cluster'.
The application code is at /Users/dev/checkout-service and
the Kubernetes manifests are at /Users/dev/checkout-service/k8s"
"Help me instrument my Java Spring Boot application on EKS with Application Signals.
Application directory: /opt/apps/payment-api
CDK infrastructure: /opt/apps/payment-api/cdk"
```
**Des instructions moins efficaces :**
```
"Enable monitoring for my app"
→ Missing: platform, language, paths
"Enable Application Signals. My code is in ./src and IaC is in ./infrastructure"
→ Problem: Relative paths instead of absolute paths
"Enable Application Signals for my EKS service at /home/user/myapp"
→ Missing: programming language
```
**Modèle rapide :**
```
"Enable Application Signals for my [LANGUAGE] service on EKS.
App code: [ABSOLUTE_PATH_TO_APP]
IaC code: [ABSOLUTE_PATH_TO_IAC]"
```
### Avantages de l'utilisation du serveur MCP
L'utilisation du serveur MCP CloudWatch Application Signals présente plusieurs avantages :
+ **Interface en langage naturel :** décrivez ce que vous souhaitez activer sans mémoriser les commandes ou la syntaxe de configuration
+ **Conseils contextuels :** le serveur MCP comprend votre environnement spécifique et fournit des recommandations personnalisées
+ **Réduction des erreurs :** la génération automatique de configuration minimise les erreurs de saisie manuelle
+ **Configuration plus rapide : passez** plus rapidement de l'intention à la mise en œuvre
+ **Outil d'apprentissage :** découvrez les configurations générées et comprenez le fonctionnement des signaux d'application
### Ressources supplémentaires
Pour plus d'informations sur la configuration et l'utilisation du serveur CloudWatch Application Signals MCP, consultez la documentation du [serveur MCP](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
# Activation des applications sur Amazon EC2
Activez les signaux d' CloudWatch application sur Amazon EC2 en suivant les étapes de configuration personnalisées décrites dans cette section.
Pour les applications exécutées sur Amazon EC2, vous devez installer et configurer vous-même l' CloudWatch agent et AWS Distro. OpenTelemetry Sur ces architectures activées avec une configuration personnalisée d’Application Signals, Application Signals ne découvre pas automatiquement les noms de vos services ni les hôtes ou clusters sur lesquels ils s’exécutent. Vous devez spécifier ces noms lors de la configuration personnalisée, et les noms que vous spécifiez sont ceux qui sont affichés sur les tableaux de bord d’Application Signals.
Les instructions de cette section concernent les applications Java, Python et .NET. Les étapes ont été testées sur des instances Amazon EC2, mais elles devraient également fonctionner sur d'autres architectures compatibles avec AWS Distro for. OpenTelemetry
**Exigences**
+ Pour obtenir de l'aide pour Application Signals, vous devez utiliser la version la plus récente de l' CloudWatchagent et de la AWS distribution pour l' OpenTelemetry agent.
+ Vous devez l'avoir AWS CLI installé sur l'instance. Nous recommandons AWS CLI la version 2, mais la version 1 devrait également fonctionner. Pour plus d'informations sur l'installation du AWS CLI, voir [Installer ou mettre à jour la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Important**
Si vous utilisez OpenTelemetry déjà une application que vous avez l'intention d'activer pour les signaux d'application, consultez la section [Systèmes pris en charge](CloudWatch-Application-Signals-supportmatrix.md) avant d'activer les signaux d'application.
## Étape 1 : activer Application Signals dans votre compte
Vous devez d’abord activer la vigie applicative dans votre compte. Si ce n’est pas déjà fait, consultez [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md).
## Étape 2 : télécharger et démarrer l' CloudWatch agent
**Pour installer l' CloudWatch agent dans le cadre de l'activation des signaux d'application sur une instance Amazon EC2 ou un hôte sur site**
1. Téléchargez la dernière version de l' CloudWatch agent sur l'instance. Si l' CloudWatch agent est déjà installé sur l'instance, vous devrez peut-être le mettre à jour. Seules les versions de l'agent publiées le 30 novembre 2023 ou ultérieurement prennent en charge les signaux CloudWatch d'application.
1. Avant de démarrer l' CloudWatch agent, configurez-le pour activer les signaux d'application. L'exemple suivant est une configuration d' CloudWatch agent qui active les signaux d'application pour les métriques et les traces sur un hôte EC2.
Nous vous recommandons de placer ce fichier à l’emplacement `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json` sur les systèmes Linux.
```
{
"traces": {
"traces_collected": {
"application_signals": {}
}
},
"logs": {
"metrics_collected": {
"application_signals": {}
}
}
}
```
1. Associez la politique **CloudWatchAgentServerPolicy**IAM au rôle IAM de votre instance Amazon EC2. Pour connaître les autorisations requises pour les hôtes sur site, consultez [Autorisations pour les serveurs sur site](#Enable-OnPremise-Permissions).
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Choisissez **Rôles** et recherchez le rôle utilisé par votre instance Amazon EC2. Choisissez ensuite le nom de ce rôle.
1. Sous l’onglet **Autorisations**, choisissez **Ajouter des autorisations**, **Attacher des politiques**.
1. Trouvez **CloudWatchAgentServerPolicy**. Utilisez le champ de recherche si nécessaire. Cochez la case correspondant à la politique, puis choisissez **Ajouter des autorisations**.
1. Démarrez l' CloudWatch agent en saisissant les commandes suivantes. Remplacez *agent-config-file-path* par le chemin d'accès au fichier de configuration de l' CloudWatch agent, tel que`./amazon-cloudwatch-agent.json`. Vous devez inclure le préfixe `file:` comme indiqué.
```
export CONFIG_FILE_PATH=./amazon-cloudwatch-agent.json
```
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config \
-m ec2 -s -c file:agent-config-file-path
```
### Autorisations pour les serveurs sur site
Pour un hôte sur site, vous devez fournir une AWS autorisation à votre appareil.
**Pour configurer les autorisations pour un hôte sur site**
1. Créer l’utilisateur IAM destiné à fournir les autorisations à votre hôte sur site :
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Sélectionnez **Utilisateurs**, **Créer un utilisateur**.
1. Dans **Détails de l’utilisateur**, pour **Nom d’utilisateur**, saisissez un nom pour le nouvel utilisateur IAM. Il s'agit du nom de connexion AWS qui sera utilisé pour authentifier votre hôte. Ensuite, sélectionnez **Next**
1. Sur la page **Définir les autorisations**, pour les **Options des autorisations**, sélectionnez **Attacher directement les politiques**.
1. Dans la liste des **politiques d'autorisation**, sélectionnez la **CloudWatchAgentServerPolicy**politique à ajouter à votre utilisateur. Ensuite, sélectionnez **Suivant**.
1. Sur la page **Réviser et créer**, assurez-vous que vous êtes satisfait du nom d'utilisateur et que la **CloudWatchAgentServerPolicy**politique figure dans le **résumé des autorisations**.
1. Sélectionnez **Créer un utilisateur**
1. Créez et récupérez votre clé AWS d'accès et votre clé secrète :
1. Dans le volet de navigation de la console IAM, sélectionnez **Utilisateurs**, puis le nom d’utilisateur que vous avez créé à l’étape précédente.
1. Sur la page de l’utilisateur, ouvrez l’onglet **Informations d’identification de sécurité**. Ensuite, dans la section **Clés d’accès**, sélectionnez **Créer une clé d’accès**.
1. Pour **Créer une clé d’accès – Étape 1**, sélectionnez **Interface de ligne de commande (CLI)**.
1. Pour **Créer une clé d’accès – Étape 2**, ajoutez éventuellement une balise puis cliquez sur **Suivant**.
1. Pour **Créer une clé d’accès – Étape 3**, sélectionnez **Télécharger le fichier .csv** pour enregistrer un fichier .csv avec la clé d’accès et la clé d’accès secrète de votre utilisateur IAM. Vous aurez besoin de ces informations pour l’étape suivante.
1. Sélectionnez **Exécuté**.
1. Configurez vos AWS informations d'identification sur votre hôte local en saisissant la commande suivante. Remplacez *ACCESS\$1KEY\$1ID* et *SECRET\$1ACCESS\$1ID* par votre clé d'accès et votre clé d'accès secrète nouvellement générées à partir du fichier .csv que vous avez téléchargé à l'étape précédente.
```
$ aws configure
AWS Access Key ID [None]: ACCESS_KEY_ID
AWS Secret Access Key [None]: SECRET_ACCESS_ID
Default region name [None]: MY_REGION
Default output format [None]: json
```
## Étape 3 : instrumenter votre application et la démarrer
L'étape suivante consiste à instrumenter votre application pour les signaux CloudWatch d'application.
------
#### [ Java ]
**Pour instrumenter vos applications Java dans le cadre de l’activation de la vigie applicative sur une instance Amazon EC2 ou un hôte sur site**
1. Téléchargez la dernière version de l'agent d'auto-instrumentation de AWS Distro pour OpenTelemetry Java. Vous pouvez télécharger la version la plus récente en utilisant [ce lien](https://github.com/aws-observability/aws-otel-java-instrumentation/releases/latest/download/aws-opentelemetry-agent.jar). Vous pouvez consulter les informations relatives à toutes les versions publiées dans la section [ aws-otel-java-instrumentationReleases](https://github.com/aws-observability/aws-otel-java-instrumentation/releases).
1. Pour optimiser vos avantages d’Application Signals, utilisez des variables d’environnement pour fournir des informations supplémentaires avant de démarrer votre application. Ces informations seront affichées dans les tableaux de bord d’Application Signals.
1. Pour la variable `OTEL_RESOURCE_ATTRIBUTES`, spécifiez les informations suivantes sous forme de paires clé-valeur :
+ (Facultatif) `service.name` définit le nom du service. Ce nom s’affichera dans les tableaux de bord de la vigie applicative comme nom du service de votre application. Si vous ne fournissez pas de valeur pour cette clé, la valeur par défaut `UnknownService` est utilisée.
+ (Facultatif) `deployment.environment` définit l’environnement d’exécution de l’application. Cet environnement sera affiché comme l’environnement **hébergé** de votre application dans les tableaux de bord Application Signals. Si vous ne le spécifiez pas, l’une des valeurs par défaut suivantes est utilisée :
+ S’il s’agit d’une instance qui fait partie d’un groupe Auto Scaling, la valeur est `ec2:name-of-Auto-Scaling-group`
+ S’il s’agit d’une instance Amazon EC2 qui ne fait pas partie d’un groupe Auto Scaling, la valeur est `ec2:default`
+ S’il s’agit d’un hôte sur site, la valeur est `generic:default`
Cette variable d'environnement est utilisée uniquement par Application Signals et est convertie en annotations de trace X-Ray et en dimensions CloudWatch métriques.
+ Pour la variable `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`, spécifiez l’URL du point de terminaison de base vers lequel les suivis doivent être exportés. L' CloudWatch agent expose 4316 comme port OTLP. Sur Amazon EC2, étant donné que les applications communiquent avec l' CloudWatch agent local, vous devez définir cette valeur sur `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces`
+ Pour la variable `OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT`, spécifiez l’URL du point de terminaison de base vers lequel les métriques doivent être exportées. L' CloudWatch agent expose 4316 comme port OTLP. Sur Amazon EC2, étant donné que les applications communiquent avec l' CloudWatch agent local, vous devez définir cette valeur sur `OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics`
+ Pour la `JAVA_TOOL_OPTIONS` variable, spécifiez le chemin où l'agent d'auto-instrumentation de AWS Distro for OpenTelemetry Java est stocké.
```
export JAVA_TOOL_OPTIONS=" -javaagent:$AWS_ADOT_JAVA_INSTRUMENTATION_PATH"
```
Par exemple :
```
export AWS_ADOT_JAVA_INSTRUMENTATION_PATH=./aws-opentelemetry-agent.jar
```
+ Pour la variable `OTEL_METRICS_EXPORTER`, nous vous recommandons de définir la valeur sur `none`. Cela désactive les autres exportateurs de métriques afin que seul l’exportateur d’Application Signals soit utilisé.
+ Définissez `OTEL_AWS_APPLICATION_SIGNALS_ENABLED` sur `true`. Cela génère des métriques d’Application Signals à partir des suivis.
1. Démarrez votre application avec les variables d’environnement mentionnées à l’étape précédente. Voici un exemple de script de démarrage.
**Note**
La configuration suivante ne prend en charge que les versions 1.32.2 et ultérieures de l'agent d' OpenTelemetry auto-instrumentation AWS Distro pour Java.
```
JAVA_TOOL_OPTIONS=" -javaagent:$AWS_ADOT_JAVA_INSTRUMENTATION_PATH" \
OTEL_METRICS_EXPORTER=none \
OTEL_LOGS_EXPORTER=none \
OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true \
OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces \
OTEL_RESOURCE_ATTRIBUTES="service.name=$YOUR_SVC_NAME" \
java -jar $MY_JAVA_APP.jar
```
1. (Facultatif) Pour activer la corrélation des journaux, ajoutez dans `OTEL_RESOURCE_ATTRIBUTES` une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
L’exemple suivant montre un script de démarrage qui permet d’activer la corrélation des journaux.
```
JAVA_TOOL_OPTIONS=" -javaagent:$AWS_ADOT_JAVA_INSTRUMENTATION_PATH" \
OTEL_METRICS_EXPORTER=none \
OTEL_LOGS_EXPORT=none \
OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true \
OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces \
OTEL_RESOURCE_ATTRIBUTES="aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$YOUR_SVC_NAME" \
java -jar $MY_JAVA_APP.jar
```
------
#### [ Python ]
**Note**
Si vous utilisez un serveur WSGI pour votre application Python, en plus des étapes décrites dans cette section, consultez [Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-Python-WSGI) pour savoir comment configurer la vigie applicative afin qu’elle fonctionne correctement.
**Pour instrumenter vos applications Python dans le cadre de l’activation de la vigie applicative sur une instance Amazon EC2**
1. Téléchargez la dernière version de l'agent d'auto-instrumentation AWS Distro for OpenTelemetry Python. Pour l'installer, exécutez la commande d' ci-dessous.
```
pip install aws-opentelemetry-distro
```
Vous pouvez consulter des informations sur toutes les versions publiées sur [AWS Distro pour l'instrumentation OpenTelemetry Python](https://github.com/aws-observability/aws-otel-python-instrumentation/releases).
1. Pour optimiser vos avantages d’Application Signals, utilisez des variables d’environnement pour fournir des informations supplémentaires avant de démarrer votre application. Ces informations seront affichées dans les tableaux de bord d’Application Signals.
1. Pour la variable `OTEL_RESOURCE_ATTRIBUTES`, spécifiez les informations suivantes sous forme de paires clé-valeur :
+ `service.name` défini le nom du service. Il sera affiché comme nom de service pour votre application dans les tableaux de bord d’Application Signals. Si vous ne fournissez pas de valeur pour cette clé, la valeur par défaut `UnknownService` est utilisée.
+ `deployment.environment` définit l’environnement dans lequel l’application s’exécute. Cet environnement sera affiché comme l’environnement **hébergé** de votre application dans les tableaux de bord Application Signals. Si vous ne le spécifiez pas, l’une des valeurs par défaut suivantes est utilisée :
+ S’il s’agit d’une instance qui fait partie d’un groupe Auto Scaling, la valeur est `ec2:name-of-Auto-Scaling-group`.
+ S’il s’agit d’une instance Amazon EC2 qui ne fait pas partie d’un groupe Auto Scaling, la valeur est `ec2:default`
+ S’il s’agit d’un hôte sur site, la valeur est `generic:default`
Cette clé d'attribut est utilisée uniquement par Application Signals et est convertie en annotations de trace X-Ray et en dimensions CloudWatch métriques.
1. Pour la `OTEL_EXPORTER_OTLP_PROTOCOL` variable, spécifiez d'`http/protobuf`exporter les données de télémétrie via HTTP vers les points de terminaison de l' CloudWatch agent répertoriés dans les étapes suivantes.
1. Pour la variable `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`, spécifiez l’URL du point de terminaison de base vers lequel les suivis doivent être exportés. L' CloudWatch agent expose 4316 comme port OTLP sur HTTP. Sur Amazon EC2, étant donné que les applications communiquent avec l' CloudWatch agent local, vous devez définir cette valeur sur `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces`
1. Pour la variable `OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT`, spécifiez l’URL du point de terminaison de base vers lequel les métriques doivent être exportées. L' CloudWatch agent expose 4316 comme port OTLP sur HTTP. Sur Amazon EC2, étant donné que les applications communiquent avec l' CloudWatch agent local, vous devez définir cette valeur sur `OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics`
1. Pour la variable `OTEL_METRICS_EXPORTER`, nous vous recommandons de définir la valeur sur `none`. Cela désactive les autres exportateurs de métriques afin que seul l’exportateur d’Application Signals soit utilisé.
1. Définissez la `OTEL_AWS_APPLICATION_SIGNALS_ENABLED` variable sur `true` pour que votre conteneur commence à envoyer des traces et des CloudWatch métriques X-Ray à Application Signals.
1. Démarrez votre application avec les variables d’environnement décrites à l’étape précédente. Voici un exemple de script de démarrage.
+ Remplacez `$SVC_NAME` par le nom de votre application. Ce nom apparaîtra comme nom de l’application dans les tableaux de bord de la vigie applicative.
+ Remplacez `$PYTHON_APP` par l’emplacement et le nom de votre application.
```
OTEL_METRICS_EXPORTER=none \
OTEL_LOGS_EXPORTER=none \
OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true \
OTEL_PYTHON_DISTRO=aws_distro \
OTEL_PYTHON_CONFIGURATOR=aws_configurator \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_TRACES_SAMPLER=xray \
OTEL_TRACES_SAMPLER_ARG="endpoint=http://localhost:2000" \
OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces \
OTEL_RESOURCE_ATTRIBUTES="service.name=$SVC_NAME" \
opentelemetry-instrument python $MY_PYTHON_APP.py
```
Avant d’activer la vigie applicative pour vos applications Python, tenez compte des considérations suivantes.
+ Dans certaines applications conteneurisées, l’absence de la variable d’environnement `PYTHONPATH` peut empêcher l’application de démarrer. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Cela est dû à un problème connu lié à l' OpenTelemetry auto-instrumentation. Pour plus d’informations sur ce problème, consultez la section [Le paramètre d’instrumentation automatique Python pour PYTHONPATH n’est pas conforme](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
+ Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la [documentation OpenTelemetry Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html).
+ Utilisez le paramètre `--noreload` pour empêcher le rechargement automatique.
+ Définissez la variable d’environnement `DJANGO_SETTINGS_MODULE` sur l’emplacement du fichier `settings.py` de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.
1. (Facultatif) Pour activer la corrélation des journaux, ajoutez dans `OTEL_RESOURCE_ATTRIBUTES` une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
L’exemple suivant montre un script de démarrage qui permet d’activer la corrélation des journaux.
```
OTEL_METRICS_EXPORTER=none \
OTEL_LOGS_EXPORTER=none \
OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true \
OTEL_PYTHON_DISTRO=aws_distro \
OTEL_PYTHON_CONFIGURATOR=aws_configurator \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_TRACES_SAMPLER=xray \
OTEL_TRACES_SAMPLER_ARG="endpoint=http://localhost:2000" \
OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces \
OTEL_RESOURCE_ATTRIBUTES="aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$YOUR_SVC_NAME" \
java -jar $MY_PYTHON_APP.jar
```
------
#### [ .NET ]
**Pour instrumenter vos applications .NET dans le cadre de l’activation de la vigie applicative sur une instance Amazon EC2 ou un hôte sur site**
1. Téléchargez la dernière version du package d'auto-instrumentation AWS Distro pour OpenTelemetry .NET. Vous pouvez télécharger la dernière version sur [ aws-otel-dotnet-instrumentationReleases](https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases).
1. Pour activer la vigie applicative, définissez les variables d’environnement ci-dessous afin de fournir des informations supplémentaires avant de démarrer votre application. Ces variables sont nécessaires pour configurer le hook de démarrage pour l’instrumentation .NET avant le lancement de votre application .NET. Remplacez `dotnet-service-name` dans la variable d’environnement `OTEL_RESOURCE_ATTRIBUTES` par le nom du service de votre choix.
+ Voici un exemple pour Linux.
```
export INSTALL_DIR=OpenTelemetryDistribution
export CORECLR_ENABLE_PROFILING=1
export CORECLR_PROFILER={918728DD-259F-4A6A-AC2B-B85E1B658318}
export CORECLR_PROFILER_PATH=${INSTALL_DIR}/linux-x64/OpenTelemetry.AutoInstrumentation.Native.so
export DOTNET_ADDITIONAL_DEPS=${INSTALL_DIR}/AdditionalDeps
export DOTNET_SHARED_STORE=${INSTALL_DIR}/store
export DOTNET_STARTUP_HOOKS=${INSTALL_DIR}/net/OpenTelemetry.AutoInstrumentation.StartupHook.dll
export OTEL_DOTNET_AUTO_HOME=${INSTALL_DIR}
export OTEL_DOTNET_AUTO_PLUGINS="AWS.Distro.OpenTelemetry.AutoInstrumentation.Plugin, AWS.Distro.OpenTelemetry.AutoInstrumentation"
export OTEL_RESOURCE_ATTRIBUTES=service.name=dotnet-service-name
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4316
export OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://127.0.0.1:4316/v1/metrics
export OTEL_METRICS_EXPORTER=none
export OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true
export OTEL_TRACES_SAMPLER=xray
export OTEL_TRACES_SAMPLER_ARG=http://127.0.0.1:2000
```
+ Voici un exemple de configuration pour Windows Server.
```
$env:INSTALL_DIR = "OpenTelemetryDistribution"
$env:CORECLR_ENABLE_PROFILING = 1
$env:CORECLR_PROFILER = "{918728DD-259F-4A6A-AC2B-B85E1B658318}"
$env:CORECLR_PROFILER_PATH = Join-Path $env:INSTALL_DIR "win-x64/OpenTelemetry.AutoInstrumentation.Native.dll"
$env:DOTNET_ADDITIONAL_DEPS = Join-Path $env:INSTALL_DIR "AdditionalDeps"
$env:DOTNET_SHARED_STORE = Join-Path $env:INSTALL_DIR "store"
$env:DOTNET_STARTUP_HOOKS = Join-Path $env:INSTALL_DIR "net/OpenTelemetry.AutoInstrumentation.StartupHook.dll"
$env:OTEL_DOTNET_AUTO_HOME = $env:INSTALL_DIR
$env:OTEL_DOTNET_AUTO_PLUGINS = "AWS.Distro.OpenTelemetry.AutoInstrumentation.Plugin, AWS.Distro.OpenTelemetry.AutoInstrumentation"
$env:OTEL_RESOURCE_ATTRIBUTES = "service.name=dotnet-service-name"
$env:OTEL_EXPORTER_OTLP_PROTOCOL = "http/protobuf"
$env:OTEL_EXPORTER_OTLP_ENDPOINT = "http://127.0.0.1:4316"
$env:OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT = "http://127.0.0.1:4316/v1/metrics"
$env:OTEL_METRICS_EXPORTER = "none"
$env:OTEL_AWS_APPLICATION_SIGNALS_ENABLED = "true"
$env:OTEL_TRACES_SAMPLER = "xray"
$env:OTEL_TRACES_SAMPLER_ARG = "http://127.0.0.1:2000"
```
1. Démarrez votre application avec les variables d’environnement mentionnées à l’étape précédente.
(Facultatif) Vous pouvez également utiliser les scripts d'installation fournis pour faciliter l'installation et la configuration du package d'instrumentation automatique AWS Distro for OpenTelemetry .NET.
Pour Linux, téléchargez et installez le script d'installation de Bash depuis la page des GitHub versions :
```
# Download and Install
curl -L -O https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases/latest/download/aws-otel-dotnet-install.sh
chmod +x ./aws-otel-dotnet-install.sh
./aws-otel-dotnet-install.sh
# Instrument
. $HOME/.otel-dotnet-auto/instrument.sh
export OTEL_RESOURCE_ATTRIBUTES=service.name=dotnet-service-name
```
Pour Windows Server, téléchargez et installez le script PowerShell d'installation depuis la page GitHub des versions :
```
# Download and Install
$module_url = "https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases/latest/download/AWS.Otel.DotNet.Auto.psm1"
$download_path = Join-Path $env:temp "AWS.Otel.DotNet.Auto.psm1"
Invoke-WebRequest -Uri $module_url -OutFile $download_path
Import-Module $download_path
Install-OpenTelemetryCore
# Instrument
Import-Module $download_path
Register-OpenTelemetryForCurrentSession -OTelServiceName "dotnet-service-name"
Register-OpenTelemetryForIIS
```
Vous pouvez trouver le NuGet package du package d'auto-instrumentation AWS Distro pour OpenTelemetry .NET dans le dépôt [officiel NuGet ](https://www.nuget.org/packages/AWS.Distro.OpenTelemetry.AutoInstrumentation). Assurez-vous de consulter le [fichier README](https://github.com/aws-observability/aws-otel-dotnet-instrumentation/blob/main/src/AWS.Distro.OpenTelemetry.AutoInstrumentation/nuget-readme.md) pour des instructions.
------
#### [ Node.js ]
**Note**
Si vous activez la vigie applicative pour une application Node.js utilisant le format ESM, consultez [Setting up a Node.js application with the ESM module format](#EC2-NodeJs-ESM) avant de commencer ces étapes.
**Pour instrumenter vos applications Node.js dans le cadre de l’activation de la vigie applicative sur une instance Amazon EC2**
1. Téléchargez la dernière version de l'agent AWS Distro for OpenTelemetry JavaScript Auto-Instrumentation pour Node.js. Pour l'installer, exécutez la commande d' ci-dessous.
```
npm install @aws/aws-distro-opentelemetry-node-autoinstrumentation
```
Vous pouvez consulter des informations sur toutes les versions publiées sur [AWS Distro pour l' OpenTelemetry JavaScript instrumentation](https://github.com/aws-observability/aws-otel-js-instrumentation/releases).
1. Pour optimiser vos avantages d’Application Signals, utilisez des variables d’environnement pour fournir des informations supplémentaires avant de démarrer votre application. Ces informations seront affichées dans les tableaux de bord d’Application Signals.
1. Pour la variable `OTEL_RESOURCE_ATTRIBUTES`, spécifiez les informations suivantes sous forme de paires clé-valeur :
+ `service.name` défini le nom du service. Il sera affiché comme nom de service pour votre application dans les tableaux de bord d’Application Signals. Si vous ne fournissez pas de valeur pour cette clé, la valeur par défaut `UnknownService` est utilisée.
+ `deployment.environment` définit l’environnement dans lequel l’application s’exécute. Cet environnement sera affiché comme l’environnement **hébergé** de votre application dans les tableaux de bord Application Signals. Si vous ne le spécifiez pas, l’une des valeurs par défaut suivantes est utilisée :
+ S’il s’agit d’une instance qui fait partie d’un groupe Auto Scaling, la valeur est `ec2:name-of-Auto-Scaling-group`.
+ S’il s’agit d’une instance Amazon EC2 qui ne fait pas partie d’un groupe Auto Scaling, la valeur est `ec2:default`
+ S’il s’agit d’un hôte sur site, la valeur est `generic:default`
Cette clé d'attribut est utilisée uniquement par Application Signals et est convertie en annotations de trace X-Ray et en dimensions CloudWatch métriques.
1. Pour la `OTEL_EXPORTER_OTLP_PROTOCOL` variable, spécifiez d'`http/protobuf`exporter les données de télémétrie via HTTP vers les points de terminaison de l' CloudWatch agent répertoriés dans les étapes suivantes.
1. Pour la variable `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`, spécifiez l’URL du point de terminaison de base vers lequel les suivis doivent être exportés. L' CloudWatch agent expose 4316 comme port OTLP sur HTTP. Sur Amazon EC2, étant donné que les applications communiquent avec l' CloudWatch agent local, vous devez définir cette valeur sur `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces`
1. Pour la variable `OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT`, spécifiez l’URL du point de terminaison de base vers lequel les métriques doivent être exportées. L' CloudWatch agent expose 4316 comme port OTLP sur HTTP. Sur Amazon EC2, étant donné que les applications communiquent avec l' CloudWatch agent local, vous devez définir cette valeur sur `OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics`
1. Pour la variable `OTEL_METRICS_EXPORTER`, nous vous recommandons de définir la valeur sur `none`. Cela désactive les autres exportateurs de métriques afin que seul l’exportateur d’Application Signals soit utilisé.
1. Définissez la `OTEL_AWS_APPLICATION_SIGNALS_ENABLED` variable sur `true` pour que votre conteneur commence à envoyer des traces et des CloudWatch métriques X-Ray à Application Signals.
1. Démarrez votre application avec les variables d’environnement décrites à l’étape précédente. Voici un exemple de script de démarrage.
+ Remplacez `$SVC_NAME` par le nom de votre application. Ce nom apparaîtra comme nom de l’application dans les tableaux de bord de la vigie applicative.
```
OTEL_METRICS_EXPORTER=none \
OTEL_LOGS_EXPORTER=none \
OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_TRACES_SAMPLER=xray \
OTEL_TRACES_SAMPLER_ARG="endpoint=http://localhost:2000" \
OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces \
OTEL_RESOURCE_ATTRIBUTES="service.name=$SVC_NAME" \
node --require '@aws/aws-distro-opentelemetry-node-autoinstrumentation/register' your-application.js
```
1. (Facultatif) Pour activer la corrélation des journaux, ajoutez dans `OTEL_RESOURCE_ATTRIBUTES` une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
L’exemple suivant montre un script de démarrage qui permet d’activer la corrélation des journaux.
```
export OTEL_METRICS_EXPORTER=none \
export OTEL_LOGS_EXPORTER=none \
export OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true \
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
export OTEL_TRACES_SAMPLER=xray \
export OTEL_TRACES_SAMPLER_ARG=endpoint=http://localhost:2000 \
export OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT=http://localhost:4316/v1/metrics \
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4316/v1/traces \
export OTEL_RESOURCE_ATTRIBUTES="aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$SVC_NAME" \
node --require '@aws/aws-distro-opentelemetry-node-autoinstrumentation/register' your-application.js
```
**Configuration d’une application Node.js utilisant le format de module ESM**
Un support limité est disponible pour les applications Node.js utilisant le format de module ESM. Pour en savoir plus, consultez [Limitations connues concernant Node.js avec ESM](CloudWatch-Application-Signals-supportmatrix.md#ESM-limitations).
Pour activer la vigie applicative pour une application Node.js utilisant le format ESM, vous devez adapter les étapes de la procédure précédente.
Tout d’abord, installez `@opentelemetry/instrumentation` pour votre application Node.js :
```
npm install @opentelemetry/instrumentation@0.54.0
```
Ensuite, aux étapes 3 et 4 de la procédure précédente, modifiez les options du nœud :
```
--require '@aws/aws-distro-opentelemetry-node-autoinstrumentation/register'
```
par :
```
--import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs
```
------
## Activez les signaux d'application sur Amazon EC2 à l'aide du protocole MCP (Model Context Protocol)
Vous pouvez utiliser le serveur MCP ( CloudWatch Application Signals Model Context Protocol) pour activer les signaux d'application sur vos instances Amazon EC2 par le biais d'interactions conversationnelles basées sur l'IA. Cela fournit une interface en langage naturel pour configurer la surveillance des signaux d'application.
Le serveur MCP automatise le processus d'activation en comprenant vos besoins et en générant la configuration appropriée. Au lieu de suivre manuellement les étapes de configuration, vous pouvez simplement décrire ce que vous souhaitez activer.
### Conditions préalables
Avant d'utiliser le serveur MCP pour activer les signaux d'application, assurez-vous d'avoir :
+ Un environnement de développement compatible avec MCP (tel que Kiro, Claude Desktop, VSCode avec des extensions MCP ou d'autres outils compatibles avec MCP)
+ Le serveur MCP CloudWatch Application Signals configuré dans votre IDE. Pour des instructions de configuration détaillées, consultez la [documentation du serveur MCP CloudWatch Application Signals](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
### Utilisation du serveur MCP
Une fois que vous avez configuré le serveur MCP CloudWatch Application Signals dans votre IDE, vous pouvez demander des conseils d'activation à l'aide d'instructions en langage naturel. Bien que l'assistant de codage puisse déduire le contexte à partir de la structure de votre projet, le fait de fournir des informations spécifiques dans vos instructions permet de garantir des conseils plus précis et plus pertinents. Incluez des informations telles que la langue de votre application, les détails de l'instance et les chemins absolus vers votre infrastructure et votre code d'application.
**Instructions relatives aux meilleures pratiques (spécifiques et complètes) :**
```
"Enable Application Signals for my Python service running on EC2.
My app code is in /home/ec2-user/flask-api and IaC is in /home/ec2-user/flask-api/terraform"
"I want to add observability to my Java application on EC2.
The application code is at /opt/apps/checkout-service and
the infrastructure code is at /opt/apps/checkout-service/cloudformation"
"Help me instrument my Node.js application on EC2 with Application Signals.
Application directory: /home/ubuntu/payment-api
Terraform code: /home/ubuntu/payment-api/terraform"
```
**Des instructions moins efficaces :**
```
"Enable monitoring for my app"
→ Missing: platform, language, paths
"Enable Application Signals. My code is in ./src and IaC is in ./infrastructure"
→ Problem: Relative paths instead of absolute paths
"Enable Application Signals for my EC2 service at /home/user/myapp"
→ Missing: programming language
```
**Modèle rapide :**
```
"Enable Application Signals for my [LANGUAGE] service on EC2.
App code: [ABSOLUTE_PATH_TO_APP]
IaC code: [ABSOLUTE_PATH_TO_IAC]"
```
### Avantages de l'utilisation du serveur MCP
L'utilisation du serveur MCP CloudWatch Application Signals présente plusieurs avantages :
+ **Interface en langage naturel :** décrivez ce que vous souhaitez activer sans mémoriser les commandes ou la syntaxe de configuration
+ **Conseils contextuels :** le serveur MCP comprend votre environnement spécifique et fournit des recommandations personnalisées
+ **Réduction des erreurs :** la génération automatique de configuration minimise les erreurs de saisie manuelle
+ **Configuration plus rapide : passez** plus rapidement de l'intention à la mise en œuvre
+ **Outil d'apprentissage :** découvrez les configurations générées et comprenez le fonctionnement des signaux d'application
### Ressources supplémentaires
Pour plus d'informations sur la configuration et l'utilisation du serveur CloudWatch Application Signals MCP, consultez la documentation du [serveur MCP](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
## (Facultatif) Surveiller l’état de votre application
Une fois vos applications activées sur Amazon EC2, vous pouvez surveiller leur état directement dans la vigie applicative. Pour de plus amples informations, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
# Activation des applications sur Amazon ECS
Activez les signaux d' CloudWatch application sur Amazon ECS en suivant les étapes de configuration personnalisées décrites dans cette section.
Pour les applications exécutées sur Amazon ECS, vous devez installer et configurer OpenTelemetry vous-même l' CloudWatch agent et AWS Distro. Sur ces architectures activées avec une configuration personnalisée d’Application Signals, Application Signals ne découvre pas automatiquement les noms de vos services ni les hôtes ou clusters sur lesquels ils s’exécutent. Vous devez spécifier ces noms lors de la configuration personnalisée, et les noms que vous spécifiez sont ceux qui sont affichés sur les tableaux de bord d’Application Signals.
## Utilisation d’une configuration personnalisée pour activer Application Signals sur Amazon ECS
Utilisez ces instructions de configuration personnalisées pour intégrer vos applications sur Amazon ECS à CloudWatch Application Signals. Vous installez et configurez OpenTelemetry vous-même l' CloudWatch agent et AWS Distro.
Il existe deux méthodes pour déployer la vigie applicative sur Amazon ECS. Choisissez celle qui convient le mieux à votre environnement.
+ [Déploiement à l’aide de la stratégie sidecar](CloudWatch-Application-Signals-ECS-Sidecar.md)— Vous ajoutez un conteneur annexe d' CloudWatch agent à chaque définition de tâche du cluster.
Avantages :
+ Compatible avec les types de lancement `ec2` et `Fargate`.
+ Vous pouvez toujours utiliser `localhost` comme adresse IP lors de la configuration des variables d’environnement.
Inconvénients :
+ Vous devez configurer le conteneur annexe de l' CloudWatch agent pour chaque tâche de service exécutée dans le cluster.
+ Seul le mode réseau `awsvpc` est pris en charge.
+ [Déploiement en utilisant la stratégie démon](CloudWatch-Application-Signals-ECS-Daemon.md)— Vous n'ajoutez une tâche d' CloudWatch agent qu'une seule fois dans le cluster, et la [stratégie de planification des démons Amazon ECS la](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html#service_scheduler_daemon) déploie selon les besoins. Cette méthode que chaque instance reçoit en continu les suivis et les métriques, offrant ainsi une visibilité centralisée sans qu’il soit nécessaire d’exécuter l’agent comme conteneur sidecar avec chaque définition de tâche d’application.
Avantages :
+ Vous ne devez configurer le service daemon pour l' CloudWatch agent qu'une seule fois dans le cluster.
Inconvénients :
+ Non compatible avec le type de lancement Fargate.
+ Si vous utilisez les modes réseau `awsvpc` ou `bridge`, vous devez spécifier manuellement l’adresse IP privée de chaque instance de conteneur dans les variables d’environnement.
Quelle que soit la méthode utilisée, sur les clusters Amazon ECS, la vigie applicative ne détecte pas automatiquement les noms de vos services. Vous devez donc spécifier ces noms lors de la configuration personnalisée, et ce sont ces noms qui seront affichés dans les tableaux de bord de la vigie applicative.
# Déploiement à l’aide de la stratégie sidecar
## Étape 1 : activer Application Signals dans votre compte
Vous devez d’abord activer la vigie applicative dans votre compte. Si ce n’est pas déjà fait, consultez [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md).
## Étape 2 : créer un rôle IAM
Vous devez créer un rôle IAM. Si vous avez déjà créé ce rôle, il se peut que vous deviez lui ajouter des autorisations.
+ **Rôle de tâche ECS** : les conteneurs utilisent ce rôle pour s'exécuter. Les autorisations doivent également correspondre aux besoins de vos applications **CloudWatchAgentServerPolicy**.
Pour plus d'informations sur la création de rôles IAM, consultez [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html).
## Étape 3 : Préparation de la configuration de CloudWatch l'agent
Préparez d’abord la configuration de l’agent avec Application Signals activé. Pour ce faire, créez un fichier local nommé `/tmp/ecs-cwagent.json`.
```
{
"traces": {
"traces_collected": {
"application_signals": {}
}
},
"logs": {
"metrics_collected": {
"application_signals": {}
}
}
}
```
Chargez ensuite la configuration de l’agent dans le magasin de paramètres SSM. Pour ce faire, entrez la commande suivante : Dans le fichier, remplacez-le *\$1REGION* par le nom réel de votre région.
```
aws ssm put-parameter \
--name "ecs-cwagent" \
--type "String" \
--value "`cat /tmp/ecs-cwagent.json`" \
--region "$REGION"
```
## Étape 4 : Instrumenter votre application avec l' CloudWatch agent
L'étape suivante consiste à instrumenter votre application pour les signaux CloudWatch d'application.
------
#### [ Java ]
**Pour instrumenter votre application sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation"
}
]
```
1. Ajoutez une définition de sidecar d' CloudWatch agent. Pour ce faire, ajoutez un nouveau conteneur appelé `ecs-cwagent` à la définition de tâche de votre application. *\$1REGION*Remplacez-le par le nom actuel de votre région. *\$1IMAGE*Remplacez-le par le chemin d'accès à la dernière image de CloudWatch conteneur sur Amazon Elastic Container Registry. Pour plus d’informations, consultez [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR.
Si vous souhaitez plutôt activer l' CloudWatch agent avec une stratégie daemon, consultez les instructions sur[Déploiement en utilisant la stratégie démon](CloudWatch-Application-Signals-ECS-Daemon.md).
```
{
"name": "ecs-cwagent",
"image": "$IMAGE",
"essential": true,
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "/ecs/ecs-cwagent",
"awslogs-region": "$REGION",
"awslogs-stream-prefix": "ecs"
}
}
}
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java)
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"/javaagent.jar",
"/otel-auto-instrumentation/javaagent.jar"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application. Vous devez utiliser la version 1.32.2 ou ultérieure de l'agent AWS Distro for OpenTelemetry [Auto-Instrumentation pour Java](https://opentelemetry.io/docs/zero-code/java/agent/).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Sidecar.html)
1. Montez le volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure. Si vous n’avez pas besoin d’activer la corrélation des journaux avec les métriques et les suivis, utilisez l’exemple fourni pour une application Java. Si vous souhaitez activer la corrélation des journaux, reportez-vous à l’étape suivante.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "JAVA_TOOL_OPTIONS",
"value": " -javaagent:/otel-auto-instrumentation/javaagent.jar"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_PROPAGATORS",
"value": "tracecontext,baggage,b3,xray"
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
------
#### [ Python ]
Avant d’activer la vigie applicative pour vos applications Python, tenez compte des considérations suivantes.
+ Dans certaines applications conteneurisées, l’absence de la variable d’environnement `PYTHONPATH` peut empêcher l’application de démarrer. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Cela est dû à un problème connu lié à l' OpenTelemetry auto-instrumentation. Pour plus d’informations sur ce problème, consultez la section [Le paramètre d’instrumentation automatique Python pour PYTHONPATH n’est pas conforme](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
+ Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la [documentation OpenTelemetry Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html).
+ Utilisez le paramètre `--noreload` pour empêcher le rechargement automatique.
+ Définissez la variable d’environnement `DJANGO_SETTINGS_MODULE` sur l’emplacement du fichier `settings.py` de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.
+ Si vous utilisez un serveur WSGI pour votre application Python, en plus des étapes décrites dans cette section, consultez [Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-Python-WSGI) pour savoir comment configurer la vigie applicative afin qu’elle fonctionne correctement.
**Pour instrumenter votre application Python sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation-python"
}
]
```
1. Ajoutez une définition de sidecar d' CloudWatch agent. Pour ce faire, ajoutez un nouveau conteneur appelé `ecs-cwagent` à la définition de tâche de votre application. *\$1REGION*Remplacez-le par le nom actuel de votre région. *\$1IMAGE*Remplacez-le par le chemin d'accès à la dernière image de CloudWatch conteneur sur Amazon Elastic Container Registry. Pour plus d’informations, consultez [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR.
Si vous souhaitez plutôt activer l' CloudWatch agent avec une stratégie daemon, consultez les instructions sur[Déploiement en utilisant la stratégie démon](CloudWatch-Application-Signals-ECS-Daemon.md).
```
{
"name": "ecs-cwagent",
"image": "$IMAGE",
"essential": true,
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "/ecs/ecs-cwagent",
"awslogs-region": "$REGION",
"awslogs-stream-prefix": "ecs"
}
}
}
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-python)
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"-a",
"/autoinstrumentation/.",
"/otel-auto-instrumentation-python"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-python",
"containerPath": "/otel-auto-instrumentation-python",
"readOnly": false
}
]
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Sidecar.html)
1. Montez le volume `opentelemetry-auto-instrumentation-python` que vous avez défini à l’étape 1 de cette procédure. Si vous n’avez pas besoin d’activer la corrélation des journaux avec les métriques et les suivis, utilisez l’exemple fourni pour une application Python. Si vous souhaitez activer la corrélation des journaux, reportez-vous à l’étape suivante.
```
{
"name": "my-app",
...
"environment": [
{
"name": "PYTHONPATH",
"value": "/otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation:$APP_PATH:/otel-auto-instrumentation-python"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://localhost:2000"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_PYTHON_DISTRO",
"value": "aws_distro"
},
{
"name": "OTEL_PYTHON_CONFIGURATOR",
"value": "aws_configurator"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "DJANGO_SETTINGS_MODULE",
"value": "$PATH_TO_SETTINGS.settings"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-python",
"containerPath": "/otel-auto-instrumentation-python",
"readOnly": false
}
]
}
```
1. (Facultatif) Pour activer la corrélation des journaux, procédez comme suit avant de monter le volume. Dans `OTEL_RESOURCE_ATTRIBUTES`, définissez une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
Voici un exemple. Pour activer la corrélation des journaux, utilisez cet exemple lorsque vous montez le volume `opentelemetry-auto-instrumentation-python` que vous avez défini à l’étape 1 de cette procédure.
```
{
"name": "my-app",
...
"environment": [
{
"name": "PYTHONPATH",
"value": "/otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation:$APP_PATH:/otel-auto-instrumentation-python"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://localhost:2000"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_PYTHON_DISTRO",
"value": "aws_distro"
},
{
"name": "OTEL_PYTHON_CONFIGURATOR",
"value": "aws_configurator"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$SVC_NAME"
},
{
"name": "DJANGO_SETTINGS_MODULE",
"value": "$PATH_TO_SETTINGS.settings"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-python",
"containerPath": "/otel-auto-instrumentation-python",
"readOnly": false
}
]
}
```
------
#### [ .NET ]
**Pour instrumenter votre application sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation"
}
]
```
1. Ajoutez une définition de sidecar d' CloudWatch agent. Pour ce faire, ajoutez un nouveau conteneur appelé `ecs-cwagent` à la définition de tâche de votre application. *\$1REGION*Remplacez-le par le nom actuel de votre région. *\$1IMAGE*Remplacez-le par le chemin d'accès à la dernière image de CloudWatch conteneur sur Amazon Elastic Container Registry. Pour plus d’informations, consultez [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR.
Si vous souhaitez plutôt activer l' CloudWatch agent avec une stratégie daemon, consultez les instructions sur[Déploiement en utilisant la stratégie démon](CloudWatch-Application-Signals-ECS-Daemon.md).
```
{
"name": "ecs-cwagent",
"image": "$IMAGE",
"essential": true,
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "/ecs/ecs-cwagent",
"awslogs-region": "$REGION",
"awslogs-stream-prefix": "ecs"
}
}
}
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-dotnet)
Pour une instance de conteneur Linux, utilisez ce qui suit.
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"-a",
"autoinstrumentation/.",
"/otel-auto-instrumentation"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
Pour une instance de conteneur Windows Server, utilisez ce qui suit.
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"CMD",
"/c",
"xcopy",
"/e",
"C:\\autoinstrumentation\\*",
"C:\\otel-auto-instrumentation",
"&&",
"icacls",
"C:\\otel-auto-instrumentation",
"/grant",
"*S-1-1-0:R",
"/T"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "C:\\otel-auto-instrumentation",
"readOnly": false
}
]
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application. Vous devez utiliser la version 1.1.0 ou une version ultérieure de l'[agent AWS Distro for OpenTelemetry Auto-Instrumentation](https://opentelemetry.io/docs/zero-code/net/) pour .NET.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Sidecar.html)
1. Montez le volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure. Pour Linux, utilisez ce qui suit.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "CORECLR_ENABLE_PROFILING",
"value": "1"
},
{
"name": "CORECLR_PROFILER",
"value": "{918728DD-259F-4A6A-AC2B-B85E1B658318}"
},
{
"name": "CORECLR_PROFILER_PATH",
"value": "/otel-auto-instrumentation/linux-x64/OpenTelemetry.AutoInstrumentation.Native.so"
},
{
"name": "DOTNET_ADDITIONAL_DEPS",
"value": "/otel-auto-instrumentation/AdditionalDeps"
},
{
"name": "DOTNET_SHARED_STORE",
"value": "/otel-auto-instrumentation/store"
},
{
"name": "DOTNET_STARTUP_HOOKS",
"value": "/otel-auto-instrumentation/net/OpenTelemetry.AutoInstrumentation.StartupHook.dll"
},
{
"name": "OTEL_DOTNET_AUTO_HOME",
"value": "/otel-auto-instrumentation"
},
{
"name": "OTEL_DOTNET_AUTO_PLUGINS",
"value": "AWS.Distro.OpenTelemetry.AutoInstrumentation.Plugin, AWS.Distro.OpenTelemetry.AutoInstrumentation"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=aws-dotnet-service-name"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_EXPORTER_OTLP_ENDPOINT",
"value": "http://localhost:4316"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://localhost:2000"
},
{
"name": "OTEL_PROPAGATORS",
"value": "tracecontext,baggage,b3,xray"
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
Pour Windows Server, utilisez ce qui suit.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "CORECLR_ENABLE_PROFILING",
"value": "1"
},
{
"name": "CORECLR_PROFILER",
"value": "{918728DD-259F-4A6A-AC2B-B85E1B658318}"
},
{
"name": "CORECLR_PROFILER_PATH",
"value": "C:\\otel-auto-instrumentation\\win-x64\\OpenTelemetry.AutoInstrumentation.Native.dll"
},
{
"name": "DOTNET_ADDITIONAL_DEPS",
"value": "C:\\otel-auto-instrumentation\\AdditionalDeps"
},
{
"name": "DOTNET_SHARED_STORE",
"value": "C:\\otel-auto-instrumentation\\store"
},
{
"name": "DOTNET_STARTUP_HOOKS",
"value": "C:\\otel-auto-instrumentation\\net\\OpenTelemetry.AutoInstrumentation.StartupHook.dll"
},
{
"name": "OTEL_DOTNET_AUTO_HOME",
"value": "C:\\otel-auto-instrumentation"
},
{
"name": "OTEL_DOTNET_AUTO_PLUGINS",
"value": "AWS.Distro.OpenTelemetry.AutoInstrumentation.Plugin, AWS.Distro.OpenTelemetry.AutoInstrumentation"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=dotnet-service-name"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_EXPORTER_OTLP_ENDPOINT",
"value": "http://localhost:4316"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://localhost:2000"
},
{
"name": "OTEL_PROPAGATORS",
"value": "tracecontext,baggage,b3,xray"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "C:\\otel-auto-instrumentation",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
------
#### [ Node.js ]
**Note**
Si vous activez la vigie applicative pour une application Node.js utilisant le format ESM, consultez [Setting up a Node.js application with the ESM module format](#ECS-NodeJs-ESM) avant de commencer ces étapes.
**Pour instrumenter votre application sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation-node"
}
]
```
1. Ajoutez une définition de sidecar d' CloudWatch agent. Pour ce faire, ajoutez un nouveau conteneur appelé `ecs-cwagent` à la définition de tâche de votre application. *\$1REGION*Remplacez-le par le nom actuel de votre région. *\$1IMAGE*Remplacez-le par le chemin d'accès à la dernière image de CloudWatch conteneur sur Amazon Elastic Container Registry. Pour plus d’informations, consultez [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR.
Si vous souhaitez plutôt activer l' CloudWatch agent avec une stratégie daemon, consultez les instructions sur[Déploiement en utilisant la stratégie démon](CloudWatch-Application-Signals-ECS-Daemon.md).
```
{
"name": "ecs-cwagent",
"image": "$IMAGE",
"essential": true,
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "/ecs/ecs-cwagent",
"awslogs-region": "$REGION",
"awslogs-stream-prefix": "ecs"
}
}
}
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-node)
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"-a",
"/autoinstrumentation/.",
"/otel-auto-instrumentation-node"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
],
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Sidecar.html)
1. Montez le volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure. Si vous n’avez pas besoin d’activer la corrélation des journaux avec les métriques et les suivis, utilisez l’exemple suivant pour une application Node.js. Si vous souhaitez activer la corrélation des journaux, reportez-vous à l’étape suivante.
Dans le conteneur de votre application, ajoutez une dépendance sur le conteneur `init` afin de vous assurer que ce dernier se termine avant le démarrage de votre conteneur d’application.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://localhost:2000"
},
{
"name": "NODE_OPTIONS",
"value": "--require /otel-auto-instrumentation-node/autoinstrumentation.js"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
1. (Facultatif) Pour activer la corrélation des journaux, procédez comme suit avant de monter le volume. Dans `OTEL_RESOURCE_ATTRIBUTES`, définissez une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
Voici un exemple. Utilisez cet exemple pour activer la corrélation des journaux lors du montage du volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$SVC_NAME"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://localhost:4316/v1/traces"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://localhost:2000"
},
{
"name": "NODE_OPTIONS",
"value": "--require /otel-auto-instrumentation-node/autoinstrumentation.js"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
**Configuration d’une application Node.js utilisant le format de module ESM**
Un support limité est disponible pour les applications Node.js utilisant le format de module ESM. Pour en savoir plus, consultez [Limitations connues concernant Node.js avec ESM](CloudWatch-Application-Signals-supportmatrix.md#ESM-limitations).
Pour le format du module ESM, l’utilisation du conteneur `init` pour injecter le kit SDK d’instrumentation Node.js ne s’applique pas. Pour activer la vigie applicative pour Node.js avec ESM, ignorez les étapes 1 et 3 de la procédure précédente et procédez comme suit.
**Pour activer la vigie applicative pour une application Node.js avec ESM**
1. Installez les dépendances nécessaires à l’instrumentation automatique dans votre application Node.js :
```
npm install @aws/aws-distro-opentelemetry-node-autoinstrumentation
npm install @opentelemetry/instrumentation@0.54.0
```
1. Dans les étapes 5 et 6 de la procédure précédente, supprimez le montage du volume `opentelemetry-auto-instrumentation-node` :
```
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
]
```
Remplacez les options du nœud par les options suivantes.
```
{
"name": "NODE_OPTIONS",
"value": "--import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs"
}
```
------
## Étape 5 : déployer votre application
Créez une nouvelle révision de votre définition de tâche et déployez-la dans votre cluster d’applications. Vous devriez voir trois conteneurs dans la tâche nouvellement créée :
+ `init` : conteneur requis pour l’initialisation de la vigie applicative.
+ `ecs-cwagent`— Un conteneur exécutant l' CloudWatch agent
+ `my-app` : exemple de conteneur d’application dans notre documentation. Dans vos charges de travail réelles, ce conteneur spécifique n’existe peut-être pas ou peut être remplacé par vos propres conteneurs de service.
## (Facultatif) Étape 6 : surveiller l’état de votre application
Une fois vos applications activées sur Amazon ECS, vous pouvez surveiller leur état directement dans la vigie applicative. Pour de plus amples informations, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
# Déploiement en utilisant la stratégie démon
## Étape 1 : activer Application Signals dans votre compte
Vous devez d’abord activer la vigie applicative dans votre compte. Si ce n’est pas déjà fait, consultez [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md).
## Étape 2 : créer un rôle IAM
Vous devez créer un rôle IAM. Si vous avez déjà créé ce rôle, il se peut que vous deviez lui ajouter des autorisations.
+ **Rôle de tâche ECS** : les conteneurs utilisent ce rôle pour s'exécuter. Les autorisations doivent également correspondre aux besoins de vos applications **CloudWatchAgentServerPolicy**.
Pour plus d'informations sur la création de rôles IAM, consultez [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html).
## Étape 3 : Préparation de la configuration de CloudWatch l'agent
Préparez d’abord la configuration de l’agent avec Application Signals activé. Pour ce faire, créez un fichier local nommé `/tmp/ecs-cwagent.json`.
```
{
"traces": {
"traces_collected": {
"application_signals": {}
}
},
"logs": {
"metrics_collected": {
"application_signals": {}
}
}
}
```
Chargez ensuite la configuration de l’agent dans le magasin de paramètres SSM. Pour ce faire, entrez la commande suivante : Dans le fichier, remplacez-le *\$1REGION* par le nom réel de votre région.
```
aws ssm put-parameter \
--name "ecs-cwagent" \
--type "String" \
--value "`cat /tmp/ecs-cwagent.json`" \
--region "$REGION"
```
## Étape 4 : Déployer le CloudWatch service agent daemon
Créez la définition de tâche suivante, puis déployez-la dans votre cluster d’applications. *\$1REGION*Remplacez-le par le nom actuel de votre région. Remplacez *\$1TASK\$1ROLE\$1ARN* et *\$1EXECUTION\$1ROLE\$1ARN* par les rôles IAM que vous avez préparés. [Étape 2 : créer un rôle IAM](#Application-Signals-Enable-ECS-IAM-Daemon) *\$1IMAGE*Remplacez-le par le chemin d'accès à la dernière image de CloudWatch conteneur sur Amazon Elastic Container Registry. Pour plus d’informations, consultez [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR.
**Note**
Le service daemon expose deux ports sur l'hôte, le 4316 étant utilisé comme point de terminaison pour la réception des métriques et des traces et le port 2000 comme point de terminaison de l'échantillonneur de CloudWatch traces. Cette configuration permet à l’agent de collecter et transmettre les données de télémétrie provenant de toutes les tâches d’application exécutées sur l’hôte. Assurez-vous que ces ports ne sont pas déjà utilisés par d’autres services sur l’hôte afin d’éviter tout conflit.
```
{
"family": "ecs-cwagent-daemon",
"taskRoleArn": "$TASK_ROLE_ARN",
"executionRoleArn": "$EXECUTION_ROLE_ARN",
"networkMode": "bridge",
"containerDefinitions": [
{
"name": "ecs-cwagent",
"image": "$IMAGE",
"essential": true,
"portMappings": [
{
"containerPort": 4316,
"hostPort": 4316
},
{
"containerPort": 2000,
"hostPort": 2000
}
],
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "/ecs/ecs-cwagent",
"awslogs-region": "$REGION",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"requiresCompatibilities": [
"EC2"
],
"cpu": "128",
"memory": "64"
}
```
## Étape 5 : instrumenter votre application
L’étape suivante consiste à instrumenter votre application pour la vigie applicative.
------
#### [ Java ]
**Pour instrumenter votre application sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation"
}
]
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java)
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"/javaagent.jar",
"/otel-auto-instrumentation/javaagent.jar"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application. Vous devez utiliser la version 1.32.2 ou ultérieure de l'agent AWS Distro for OpenTelemetry [Auto-Instrumentation pour Java](https://opentelemetry.io/docs/zero-code/java/agent/).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Daemon.html)
1. Montez le volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure. Si vous n’avez pas besoin d’activer la corrélation des journaux avec les métriques et les suivis, utilisez l’exemple fourni pour une application Java. Si vous souhaitez activer la corrélation des journaux, reportez-vous à l’étape suivante.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "JAVA_TOOL_OPTIONS",
"value": " -javaagent:/otel-auto-instrumentation/javaagent.jar"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_PROPAGATORS",
"value": "tracecontext,baggage,b3,xray"
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
------
#### [ Python ]
Avant d’activer la vigie applicative pour vos applications Python, tenez compte des considérations suivantes.
+ Dans certaines applications conteneurisées, l’absence de la variable d’environnement `PYTHONPATH` peut empêcher l’application de démarrer. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Cela est dû à un problème connu lié à l' OpenTelemetry auto-instrumentation. Pour plus d’informations sur ce problème, consultez la section [Le paramètre d’instrumentation automatique Python pour PYTHONPATH n’est pas conforme](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
+ Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la [documentation OpenTelemetry Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html).
+ Utilisez le paramètre `--noreload` pour empêcher le rechargement automatique.
+ Définissez la variable d’environnement `DJANGO_SETTINGS_MODULE` sur l’emplacement du fichier `settings.py` de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.
+ Si vous utilisez un serveur WSGI pour votre application Python, en plus des étapes décrites dans cette section, consultez [Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-Python-WSGI) pour savoir comment configurer la vigie applicative afin qu’elle fonctionne correctement.
**Pour instrumenter votre application Python sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation-python"
}
]
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-python)
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"-a",
"/autoinstrumentation/.",
"/otel-auto-instrumentation-python"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-python",
"containerPath": "/otel-auto-instrumentation-python",
"readOnly": false
}
]
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Daemon.html)
1. Montez le volume `opentelemetry-auto-instrumentation-python` que vous avez défini à l’étape 1 de cette procédure. Si vous n’avez pas besoin d’activer la corrélation des journaux avec les métriques et les suivis, utilisez l’exemple fourni pour une application Python. Si vous souhaitez activer la corrélation des journaux, reportez-vous à l’étape suivante.
```
{
"name": "my-app",
...
"environment": [
{
"name": "PYTHONPATH",
"value": "/otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation:$APP_PATH:/otel-auto-instrumentation-python"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://CW_CONTAINER_IP:2000"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_PYTHON_DISTRO",
"value": "aws_distro"
},
{
"name": "OTEL_PYTHON_CONFIGURATOR",
"value": "aws_configurator"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/metrics"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "DJANGO_SETTINGS_MODULE",
"value": "$PATH_TO_SETTINGS.settings"
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-python",
"containerPath": "/otel-auto-instrumentation-python",
"readOnly": false
}
]
}
```
1. (Facultatif) Pour activer la corrélation des journaux, procédez comme suit avant de monter le volume. Dans `OTEL_RESOURCE_ATTRIBUTES`, définissez une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
Voici un exemple. Pour activer la corrélation des journaux, utilisez cet exemple lorsque vous montez le volume `opentelemetry-auto-instrumentation-python` que vous avez défini à l’étape 1 de cette procédure.
```
{
"name": "my-app",
...
"environment": [
{
"name": "PYTHONPATH",
"value": "/otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation:$APP_PATH:/otel-auto-instrumentation-python"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://CW_CONTAINER_IP:2000"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_PYTHON_DISTRO",
"value": "aws_distro"
},
{
"name": "OTEL_PYTHON_CONFIGURATOR",
"value": "aws_configurator"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/metrics"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$SVC_NAME"
},
{
"name": "DJANGO_SETTINGS_MODULE",
"value": "$PATH_TO_SETTINGS.settings"
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-python",
"containerPath": "/otel-auto-instrumentation-python",
"readOnly": false
}
]
}
```
------
#### [ .NET ]
**Pour instrumenter votre application sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation"
}
]
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-dotnet)
Pour une instance de conteneur Linux, utilisez ce qui suit.
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"-a",
"autoinstrumentation/.",
"/otel-auto-instrumentation"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
]
}
```
Pour une instance de conteneur Windows Server, utilisez ce qui suit.
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"CMD",
"/c",
"xcopy",
"/e",
"C:\\autoinstrumentation\\*",
"C:\\otel-auto-instrumentation",
"&&",
"icacls",
"C:\\otel-auto-instrumentation",
"/grant",
"*S-1-1-0:R",
"/T"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "C:\\otel-auto-instrumentation",
"readOnly": false
}
]
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que le conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application. Vous devez utiliser la version 1.1.0 ou une version ultérieure de l'[agent AWS Distro for OpenTelemetry Auto-Instrumentation](https://opentelemetry.io/docs/zero-code/net/) pour .NET.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Daemon.html)
1. Montez le volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure. Pour Linux, utilisez ce qui suit.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "CORECLR_ENABLE_PROFILING",
"value": "1"
},
{
"name": "CORECLR_PROFILER",
"value": "{918728DD-259F-4A6A-AC2B-B85E1B658318}"
},
{
"name": "CORECLR_PROFILER_PATH",
"value": "/otel-auto-instrumentation/linux-x64/OpenTelemetry.AutoInstrumentation.Native.so"
},
{
"name": "DOTNET_ADDITIONAL_DEPS",
"value": "/otel-auto-instrumentation/AdditionalDeps"
},
{
"name": "DOTNET_SHARED_STORE",
"value": "/otel-auto-instrumentation/store"
},
{
"name": "DOTNET_STARTUP_HOOKS",
"value": "/otel-auto-instrumentation/net/OpenTelemetry.AutoInstrumentation.StartupHook.dll"
},
{
"name": "OTEL_DOTNET_AUTO_HOME",
"value": "/otel-auto-instrumentation"
},
{
"name": "OTEL_DOTNET_AUTO_PLUGINS",
"value": "AWS.Distro.OpenTelemetry.AutoInstrumentation.Plugin, AWS.Distro.OpenTelemetry.AutoInstrumentation"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=dotnet-service-name"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://localhost:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_EXPORTER_OTLP_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://CW_CONTAINER_IP:2000"
},
{
"name": "OTEL_PROPAGATORS",
"value": "tracecontext,baggage,b3,xray"
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "/otel-auto-instrumentation",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
Pour Windows Server, utilisez ce qui suit.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "CORECLR_ENABLE_PROFILING",
"value": "1"
},
{
"name": "CORECLR_PROFILER",
"value": "{918728DD-259F-4A6A-AC2B-B85E1B658318}"
},
{
"name": "CORECLR_PROFILER_PATH",
"value": "C:\\otel-auto-instrumentation\\win-x64\\OpenTelemetry.AutoInstrumentation.Native.dll"
},
{
"name": "DOTNET_ADDITIONAL_DEPS",
"value": "C:\\otel-auto-instrumentation\\AdditionalDeps"
},
{
"name": "DOTNET_SHARED_STORE",
"value": "C:\\otel-auto-instrumentation\\store"
},
{
"name": "DOTNET_STARTUP_HOOKS",
"value": "C:\\otel-auto-instrumentation\\net\\OpenTelemetry.AutoInstrumentation.StartupHook.dll"
},
{
"name": "OTEL_DOTNET_AUTO_HOME",
"value": "C:\\otel-auto-instrumentation"
},
{
"name": "OTEL_DOTNET_AUTO_PLUGINS",
"value": "AWS.Distro.OpenTelemetry.AutoInstrumentation.Plugin, AWS.Distro.OpenTelemetry.AutoInstrumentation"
},
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=dotnet-service-name"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_EXPORTER_OTLP_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://CW_CONTAINER_IP:2000"
},
{
"name": "OTEL_PROPAGATORS",
"value": "tracecontext,baggage,b3,xray"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation",
"containerPath": "C:\\otel-auto-instrumentation",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
------
#### [ Node.js ]
**Note**
Si vous activez la vigie applicative pour une application Node.js utilisant le format ESM, consultez [Setting up a Node.js application with the ESM module format](#ECSDaemon-NodeJs-ESM) avant de commencer ces étapes.
**Pour instrumenter votre application sur Amazon ECS avec l' CloudWatch agent**
1. Spécifiez d’abord un montage lié. Le volume sera utilisé pour partager des fichiers entre conteneurs au cours des prochaines étapes. Vous utiliserez ce montage lié plus tard dans cette procédure.
```
"volumes": [
{
"name": "opentelemetry-auto-instrumentation-node"
}
]
```
1. Ajoutez un nouveau conteneur `init` à la définition de tâche de votre application. *\$1IMAGE*Remplacez-la par la dernière image du référentiel d'images [AWS Distro for OpenTelemetry Amazon ECR.](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-node)
```
{
"name": "init",
"image": "$IMAGE",
"essential": false,
"command": [
"cp",
"-a",
"/autoinstrumentation/.",
"/otel-auto-instrumentation-node"
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
],
}
```
1. Ajoutez une dépendance au conteneur `init` afin de vous assurer que ce conteneur se termine avant le démarrage du conteneur de votre application.
```
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
```
1. Ajoutez les variables d’environnement suivantes à votre conteneur d’application.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-ECS-Daemon.html)
1. Montez le volume `opentelemetry-auto-instrumentation-node` que vous avez défini à l’étape 1 de cette procédure. Si vous n’avez pas besoin d’activer la corrélation des journaux avec les métriques et les suivis, utilisez l’exemple suivant pour une application Node.js. Si vous souhaitez activer la corrélation des journaux, reportez-vous à l’étape suivante.
Dans le conteneur de votre application, ajoutez une dépendance sur le conteneur `init` afin de vous assurer que ce dernier se termine avant le démarrage de votre conteneur d’application.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$SVC_NAME"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://CW_CONTAINER_IP:2000"
},
{
"name": "NODE_OPTIONS",
"value": "--require /otel-auto-instrumentation-node/autoinstrumentation.js"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
1. (Facultatif) Pour activer la corrélation des journaux, procédez comme suit avant de monter le volume. Dans `OTEL_RESOURCE_ATTRIBUTES`, définissez une variable d’environnement supplémentaire `aws.log.group.names` pour les groupes de journaux de votre application. Cela permet de corréler les suivis et les métriques de votre application avec les entrées de journaux correspondantes. Pour cette variable, remplacez *\$1YOUR\$1APPLICATION\$1LOG\$1GROUP* par les noms des groupes de journaux de votre application. Si vous avez plusieurs groupes de journaux, vous pouvez les séparer à l’aide d’un esperluette (`&`), comme dans l’exemple suivant : `aws.log.group.names=log-group-1&log-group-2`. Pour activer la corrélation entre les métriques et les journaux, la définition de cette variable suffit. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md). Pour activer la corrélation entre les suivis et les journaux, vous devez également modifier la configuration de journalisation de votre application. Pour de plus amples informations, veuillez consulter [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md).
Voici un exemple. Utilisez cet exemple pour activer la corrélation des journaux lors du montage du volume `opentelemetry-auto-instrumentation` que vous avez défini à l’étape 1 de cette procédure.
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "aws.log.group.names=$YOUR_APPLICATION_LOG_GROUP,service.name=$SVC_NAME"
},
{
"name": "OTEL_LOGS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_METRICS_EXPORTER",
"value": "none"
},
{
"name": "OTEL_EXPORTER_OTLP_PROTOCOL",
"value": "http/protobuf"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_ENABLED",
"value": "true"
},
{
"name": "OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/metrics"
},
{
"name": "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT",
"value": "http://CW_CONTAINER_IP:4316/v1/traces"
},
{
"name": "OTEL_TRACES_SAMPLER",
"value": "xray"
},
{
"name": "OTEL_TRACES_SAMPLER_ARG",
"value": "endpoint=http://CW_CONTAINER_IP:2000"
},
{
"name": "NODE_OPTIONS",
"value": "--require /otel-auto-instrumentation-node/autoinstrumentation.js"
}
],
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
],
"dependsOn": [
{
"containerName": "init",
"condition": "SUCCESS"
}
]
}
```
**Configuration d’une application Node.js utilisant le format de module ESM**
Un support limité est disponible pour les applications Node.js utilisant le format de module ESM. Pour en savoir plus, consultez [Limitations connues concernant Node.js avec ESM](CloudWatch-Application-Signals-supportmatrix.md#ESM-limitations).
Pour le format du module ESM, l’utilisation du conteneur `init` pour injecter le kit SDK d’instrumentation Node.js ne s’applique pas. Pour activer la vigie applicative pour Node.js avec ESM, ignorez les étapes 1 et 2 de la procédure précédente et procédez comme suit.
**Pour activer la vigie applicative pour une application Node.js avec ESM**
1. Installez les dépendances nécessaires à l’instrumentation automatique dans votre application Node.js :
```
npm install @aws/aws-distro-opentelemetry-node-autoinstrumentation
npm install @opentelemetry/instrumentation@0.54.0
```
1. Dans les étapes 4 et 5 de la procédure précédente, supprimez le montage du volume `opentelemetry-auto-instrumentation-node` :
```
"mountPoints": [
{
"sourceVolume": "opentelemetry-auto-instrumentation-node",
"containerPath": "/otel-auto-instrumentation-node",
"readOnly": false
}
]
```
Remplacez les options du nœud par les options suivantes.
```
{
"name": "NODE_OPTIONS",
"value": "--import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs"
}
```
------
## Étape 6 : Déployez votre application
Créez une nouvelle révision de votre définition de tâche et déployez-la dans votre cluster d’applications. Vous devriez voir deux conteneurs dans la tâche nouvellement créée :
+ `init` : conteneur requis pour l’initialisation de la vigie applicative
+ `my-app` : exemple de conteneur d’application dans notre documentation. Dans vos charges de travail réelles, ce conteneur spécifique n’existe peut-être pas ou peut être remplacé par vos propres conteneurs de service.
## (Facultatif) Étape 7 : surveiller l’état de votre application
Une fois vos applications activées sur Amazon ECS, vous pouvez surveiller leur état directement dans la vigie applicative. Pour de plus amples informations, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
# Activez les signaux d'application sur Amazon ECS à l'aide de AWS CDK
Pour activer les signaux d'application sur Amazon ECS à l'aide de AWS CDK, procédez comme suit.
1. Activation d’la vigie applicative pour vos applications : si la vigie applicative n’est pas encore activé dans ce compte, vous devez accorder à ce service les autorisations nécessaires pour découvrir vos services.
```
import { aws_applicationsignals as applicationsignals } from 'aws-cdk-lib';
const cfnDiscovery = new applicationsignals.CfnDiscovery(this,
'ApplicationSignalsServiceRole', { }
);
```
La CloudFormation ressource Discovery accorde à Application Signals les autorisations suivantes :
+ `xray:GetServiceGraph`
+ `logs:StartQuery`
+ `logs:GetQueryResults`
+ `cloudwatch:GetMetricData`
+ `cloudwatch:ListMetrics`
+ `tag:GetResources`
Pour plus d’informations sur ce rôle, consultez [Autorisations de rôle liées au service pour les signaux d'application CloudWatch](using-service-linked-roles.md#service-linked-role-signals).
1. Instrumentez votre application avec la [bibliothèque AWS::Application Signals Construct](https://www.npmjs.com/package/@aws-cdk/aws-applicationsignals-alpha) du AWS CDK. Les extraits de code contenus dans ce document sont fournis dans. *TypeScript* Pour d'autres alternatives spécifiques à un langage, voir [Langages de programmation pris en charge pour le AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/languages.html).
+ **Activation de la vigie applicative sur Amazon ECS en mode sidecar**
1. Configurez `instrumentation` pour instrumenter l'application avec l' AWS agent du SDK Distro for OpenTelemetry (ADOT). L’exemple suivant illustre l’instrumentation d’une application Java. Consultez toutes [InstrumentationVersion](https://docs.aws.amazon.com/cdk/api/v2/docs/@aws-cdk_aws-applicationsignals-alpha.InstrumentationVersion.html)les versions linguistiques prises en charge.
1. Spécifiez `cloudWatchAgentSidecar` de configurer l' CloudWatch agent en tant que conteneur annexe.
```
import { Construct } from 'constructs';
import * as appsignals from '@aws-cdk/aws-applicationsignals-alpha';
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
class MyStack extends cdk.Stack {
public constructor(scope?: Construct, id?: string, props: cdk.StackProps = {}) {
super();
const vpc = new ec2.Vpc(this, 'TestVpc', {});
const cluster = new ecs.Cluster(this, 'TestCluster', { vpc });
const fargateTaskDefinition = new ecs.FargateTaskDefinition(this, 'SampleAppTaskDefinition', {
cpu: 2048,
memoryLimitMiB: 4096,
});
fargateTaskDefinition.addContainer('app', {
image: ecs.ContainerImage.fromRegistry('test/sample-app'),
});
new appsignals.ApplicationSignalsIntegration(this, 'ApplicationSignalsIntegration', {
taskDefinition: fargateTaskDefinition,
instrumentation: {
sdkVersion: appsignals.JavaInstrumentationVersion.V2_10_0,
},
serviceName: 'sample-app',
cloudWatchAgentSidecar: {
containerName: 'ecs-cwagent',
enableLogging: true,
cpu: 256,
memoryLimitMiB: 512,
}
});
new ecs.FargateService(this, 'MySampleApp', {
cluster: cluster,
taskDefinition: fargateTaskDefinition,
desiredCount: 1,
});
}
}
```
+ **Activation de la vigie applicative sur Amazon ECS en mode démon**
**Note**
La stratégie de déploiement en mode démon n’est pas prise en charge sur Amazon ECS Fargate et est uniquement compatible avec Amazon ECS sur Amazon EC2.
1. Exécutez CloudWatch l'agent en tant que service daemon en mode `HOST` réseau.
1. Configurez `instrumentation` pour instrumenter l’application à l’aide de l’agent ADOT pour Python.
```
import { Construct } from 'constructs';
import * as appsignals from '@aws-cdk/aws-applicationsignals-alpha';
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
class MyStack extends cdk.Stack {
public constructor(scope?: Construct, id?: string, props: cdk.StackProps = {}) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, 'TestVpc', {});
const cluster = new ecs.Cluster(this, 'TestCluster', { vpc });
// Define Task Definition for CloudWatch agent (Daemon)
const cwAgentTaskDefinition = new ecs.Ec2TaskDefinition(this, 'CloudWatchAgentTaskDefinition', {
networkMode: ecs.NetworkMode.HOST,
});
new appsignals.CloudWatchAgentIntegration(this, 'CloudWatchAgentIntegration', {
taskDefinition: cwAgentTaskDefinition,
containerName: 'ecs-cwagent',
enableLogging: false,
cpu: 128,
memoryLimitMiB: 64,
portMappings: [
{
containerPort: 4316,
hostPort: 4316,
},
{
containerPort: 2000,
hostPort: 2000,
},
],
});
// Create the CloudWatch Agent daemon service
new ecs.Ec2Service(this, 'CloudWatchAgentDaemon', {
cluster,
taskDefinition: cwAgentTaskDefinition,
daemon: true, // Runs one container per EC2 instance
});
// Define Task Definition for user application
const sampleAppTaskDefinition = new ecs.Ec2TaskDefinition(this, 'SampleAppTaskDefinition', {
networkMode: ecs.NetworkMode.HOST,
});
sampleAppTaskDefinition.addContainer('app', {
image: ecs.ContainerImage.fromRegistry('test/sample-app'),
cpu: 0,
memoryLimitMiB: 512,
});
// No CloudWatch Agent sidecar is needed as application container communicates to CloudWatch Agent daemon through host network
new appsignals.ApplicationSignalsIntegration(this, 'ApplicationSignalsIntegration', {
taskDefinition: sampleAppTaskDefinition,
instrumentation: {
sdkVersion: appsignals.PythonInstrumentationVersion.V0_8_0
},
serviceName: 'sample-app'
});
new ecs.Ec2Service(this, 'MySampleApp', {
cluster,
taskDefinition: sampleAppTaskDefinition,
desiredCount: 1,
});
}
}
```
+ **Activation de la vigie applicative sur Amazon ECS en mode réplica**
**Note**
CloudWatch L'exécution du service Agent en mode réplique nécessite des configurations de groupes de sécurité spécifiques pour permettre la communication avec d'autres services. Pour la fonctionnalité de la vigie applicative, configurez le groupe de sécurité avec les règles de trafic entrant minimales : port 2000 (HTTP) et port 4316 (HTTP). Cette configuration garantit une connectivité adéquate entre l' CloudWatch agent et les services dépendants.
1. Exécutez CloudWatch l'agent en tant que service de réplication avec Service Connect.
1. Configurez `instrumentation` pour instrumenter l’application à l’aide de l’agent ADOT pour Python.
1. Remplacez les variables d'environnement en les configurant `overrideEnvironments` de manière à utiliser les points de terminaison Service Connect pour communiquer avec le serveur de l' CloudWatch agent.
```
import { Construct } from 'constructs';
import * as appsignals from '@aws-cdk/aws-applicationsignals-alpha';
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { PrivateDnsNamespace } from 'aws-cdk-lib/aws-servicediscovery';
class MyStack extends cdk.Stack {
public constructor(scope?: Construct, id?: string, props: cdk.StackProps = {}) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, 'TestVpc', {});
const cluster = new ecs.Cluster(this, 'TestCluster', { vpc });
const dnsNamespace = new PrivateDnsNamespace(this, 'Namespace', {
vpc,
name: 'local',
});
const securityGroup = new ec2.SecurityGroup(this, 'ECSSG', { vpc });
securityGroup.addIngressRule(securityGroup, ec2.Port.tcpRange(0, 65535));
// Define Task Definition for CloudWatch agent (Replica)
const cwAgentTaskDefinition = new ecs.FargateTaskDefinition(this, 'CloudWatchAgentTaskDefinition', {});
new appsignals.CloudWatchAgentIntegration(this, 'CloudWatchAgentIntegration', {
taskDefinition: cwAgentTaskDefinition,
containerName: 'ecs-cwagent',
enableLogging: false,
cpu: 128,
memoryLimitMiB: 64,
portMappings: [
{
name: 'cwagent-4316',
containerPort: 4316,
hostPort: 4316,
},
{
name: 'cwagent-2000',
containerPort: 2000,
hostPort: 2000,
},
],
});
// Create the CloudWatch Agent replica service with service connect
new ecs.FargateService(this, 'CloudWatchAgentService', {
cluster: cluster,
taskDefinition: cwAgentTaskDefinition,
securityGroups: [securityGroup],
serviceConnectConfiguration: {
namespace: dnsNamespace.namespaceArn,
services: [
{
portMappingName: 'cwagent-4316',
dnsName: 'cwagent-4316-http',
port: 4316,
},
{
portMappingName: 'cwagent-2000',
dnsName: 'cwagent-2000-http',
port: 2000,
},
],
},
desiredCount: 1,
});
// Define Task Definition for user application
const sampleAppTaskDefinition = new ecs.FargateTaskDefinition(this, 'SampleAppTaskDefinition', {});
sampleAppTaskDefinition.addContainer('app', {
image: ecs.ContainerImage.fromRegistry('test/sample-app'),
cpu: 0,
memoryLimitMiB: 512,
});
// Overwrite environment variables to connect to the CloudWatch Agent service just created
new appsignals.ApplicationSignalsIntegration(this, 'ApplicationSignalsIntegration', {
taskDefinition: sampleAppTaskDefinition,
instrumentation: {
sdkVersion: appsignals.PythonInstrumentationVersion.V0_8_0,
},
serviceName: 'sample-app',
overrideEnvironments: [
{
name: appsignals.CommonExporting.OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT,
value: 'http://cwagent-4316-http:4316/v1/metrics',
},
{
name: appsignals.TraceExporting.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
value: 'http://cwagent-4316-http:4316/v1/traces',
},
{
name: appsignals.TraceExporting.OTEL_TRACES_SAMPLER_ARG,
value: 'endpoint=http://cwagent-2000-http:2000',
},
],
});
// Create ECS Service with service connect configuration
new ecs.FargateService(this, 'MySampleApp', {
cluster: cluster,
taskDefinition: sampleAppTaskDefinition,
serviceConnectConfiguration: {
namespace: dnsNamespace.namespaceArn,
},
desiredCount: 1,
});
}
}
```
1. Configuration d’une application Node.js utilisant le format de module ESM. La prise en charge des applications Node.js utilisant le format de module ESM est limitée. Pour plus d’informations, consultez la section [Limitations connues des applications Node.js avec ESM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-supportmatrix.html#ESM-limitations).
Dans le cas du format ESM, l’activation de la vigie applicative à l’aide du conteneur `init` pour injecter le kit SDK d’instrumentation Node.js ne s’applique pas. Ignorez l’étape 2 de cette procédure et procédez plutôt comme suit.
+ Installez les dépendances nécessaires à l’instrumentation automatique dans votre application Node.js.
```
npm install @aws/aws-distro-opentelemetry-node-autoinstrumentation
npm install @opentelemetry/instrumentation@0.54.
```
+ Mettre à jour TaskDefinition.
1. Ajoutez une configuration supplémentaire à votre conteneur d’applications.
1. Configuration `NODE_OPTIONS`.
1. (Facultatif) Ajoutez CloudWatch un agent si vous choisissez le mode sidecar.
```
import { Construct } from 'constructs';
import * as appsignals from '@aws-cdk/aws-applicationsignals-alpha';
import * as ecs from 'aws-cdk-lib/aws-ecs';
class MyStack extends cdk.Stack {
public constructor(scope?: Construct, id?: string, props: cdk.StackProps = {}) {
super(scope, id, props);
const fargateTaskDefinition = new ecs.FargateTaskDefinition(stack, 'TestTaskDefinition', {
cpu: 256,
memoryLimitMiB: 512,
});
const appContainer = fargateTaskDefinition.addContainer('app', {
image: ecs.ContainerImage.fromRegistry('docker/cdk-test'),
});
const volumeName = 'opentelemetry-auto-instrumentation'
fargateTaskDefinition.addVolume({name: volumeName});
// Inject additional configurations
const injector = new appsignals.NodeInjector(volumeName, appsignals.NodeInstrumentationVersion.V0_5_0);
injector.renderDefaultContainer(fargateTaskDefinition);
// Configure NODE_OPTIONS
appContainer.addEnvironment('NODE_OPTIONS', '--import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs')
// Optional: add CloudWatch agent
const cwAgent = new appsignals.CloudWatchAgentIntegration(stack, 'AddCloudWatchAgent', {
containerName: 'ecs-cwagent',
taskDefinition: fargateTaskDefinition,
memoryReservationMiB: 50,
});
appContainer.addContainerDependencies({
container: cwAgent.agentContainer,
condition: ecs.ContainerDependencyCondition.START,
});
}
```
1. Déploiement de la pile mise à jour : exécutez la commande `cdk synth` dans le répertoire principal de l’application. Pour déployer le service dans votre AWS compte, exécutez la `cdk deploy` commande dans le répertoire principal de votre application.
Si vous avez utilisé la stratégie sidecar, un seul service sera créé :
+ *APPLICATION\$1SERVICE*est le service de votre application. Il comprend les trois conteneurs suivants :
+ `init` : conteneur requis pour l’initialisation de la vigie applicative.
+ `ecs-cwagent`— Un conteneur exécutant l' CloudWatch agent
+ `my-app` : exemple de conteneur d’application dans notre documentation. Dans vos charges de travail réelles, ce conteneur spécifique n’existe peut-être pas ou peut être remplacé par vos propres conteneurs de service.
Si vous avez utilisé la stratégie démon, deux services seront créés :
+ *CloudWatchAgentDaemon *est le service CloudWatch agent daemon.
+ *APPLICATION\$1SERVICE*est le service de votre application. Il comprend les deux conteneurs suivants :
+ `init` : conteneur requis pour l’initialisation de la vigie applicative.
+ `my-app` : exemple de conteneur d’application dans notre documentation. Dans vos charges de travail réelles, ce conteneur spécifique n’existe peut-être pas ou peut être remplacé par vos propres conteneurs de service.
Si vous avez utilisé la stratégie de réplication, deux services seront créés :
+ *CloudWatchAgentService*est le service de réplication de l' CloudWatch agent.
+ *APPLICATION\$1SERVICE*est le service de votre application. Il comprend les deux conteneurs suivants :
+ `init` : conteneur requis pour l’initialisation de la vigie applicative.
+ `my-app` : exemple de conteneur d’application dans notre documentation. Dans vos charges de travail réelles, ce conteneur spécifique n’existe peut-être pas ou peut être remplacé par vos propres conteneurs de service.
## Activez les signaux d'application sur Amazon ECS à l'aide du protocole MCP (Model Context Protocol)
Vous pouvez utiliser le serveur MCP ( CloudWatch Application Signals Model Context Protocol) pour activer les signaux d'application sur vos clusters Amazon ECS par le biais d'interactions conversationnelles avec l'IA. Cela fournit une interface en langage naturel pour configurer la surveillance des signaux d'application.
Le serveur MCP automatise le processus d'activation en comprenant vos besoins et en générant la configuration appropriée. Au lieu de suivre manuellement les étapes de la console ou d'écrire du code CDK, vous pouvez simplement décrire ce que vous souhaitez activer.
### Conditions préalables
Avant d'utiliser le serveur MCP pour activer les signaux d'application, assurez-vous d'avoir :
+ Un environnement de développement compatible avec MCP (tel que Kiro, Claude Desktop, VSCode avec des extensions MCP ou d'autres outils compatibles avec MCP)
+ Le serveur MCP CloudWatch Application Signals configuré dans votre IDE. Pour obtenir des instructions de configuration détaillées, consultez la [documentation du serveur MCP CloudWatch Application Signals](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
### Utilisation du serveur MCP
Une fois que vous avez configuré le serveur MCP CloudWatch Application Signals dans votre IDE, vous pouvez demander des conseils d'activation à l'aide d'instructions en langage naturel. Bien que l'assistant de codage puisse déduire le contexte à partir de la structure de votre projet, le fait de fournir des informations spécifiques dans vos instructions permet de garantir des conseils plus précis et plus pertinents. Incluez des informations telles que la langue de votre application, le nom du cluster Amazon ECS, la stratégie de déploiement (sidecar ou daemon) et les chemins absolus vers votre infrastructure et votre code d'application.
**Instructions relatives aux meilleures pratiques (spécifiques et complètes) :**
```
"Enable Application Signals for my Python service running on ECS.
My app code is in /home/user/flask-api and IaC is in /home/user/flask-api/terraform"
"I want to add observability to my Node.js application on ECS cluster 'production-cluster' using sidecar deployment.
The application code is at /Users/dev/checkout-service and
the task definitions are at /Users/dev/checkout-service/ecs"
"Help me instrument my Java Spring Boot application on ECS with Application Signals using daemon strategy.
Application directory: /opt/apps/payment-api
CDK infrastructure: /opt/apps/payment-api/cdk"
```
**Des instructions moins efficaces :**
```
"Enable monitoring for my app"
→ Missing: platform, language, paths
"Enable Application Signals. My code is in ./src and IaC is in ./infrastructure"
→ Problem: Relative paths instead of absolute paths
"Enable Application Signals for my ECS service at /home/user/myapp"
→ Missing: programming language, deployment strategy
```
**Modèle rapide :**
```
"Enable Application Signals for my [LANGUAGE] service on ECS.
Deployment strategy: [sidecar/daemon]
App code: [ABSOLUTE_PATH_TO_APP]
IaC code: [ABSOLUTE_PATH_TO_IAC]"
```
### Avantages de l'utilisation du serveur MCP
L'utilisation du serveur MCP CloudWatch Application Signals présente plusieurs avantages :
+ **Interface en langage naturel :** décrivez ce que vous souhaitez activer sans mémoriser les commandes ou la syntaxe de configuration
+ **Conseils contextuels :** le serveur MCP comprend votre environnement spécifique et fournit des recommandations personnalisées
+ **Réduction des erreurs :** la génération automatique de configuration minimise les erreurs de saisie manuelle
+ **Configuration plus rapide : passez** plus rapidement de l'intention à la mise en œuvre
+ **Outil d'apprentissage :** découvrez les configurations générées et comprenez le fonctionnement des signaux d'application
### Ressources supplémentaires
Pour plus d'informations sur la configuration et l'utilisation du serveur CloudWatch Application Signals MCP, consultez la documentation du [serveur MCP](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
# Activer vos applications sur Kubernetes
Activez les signaux CloudWatch d'application sur Kubernetes en suivant les étapes de configuration personnalisées décrites dans cette section.
Pour les applications exécutées sur Kubernetes, vous devez installer et configurer vous-même l' CloudWatch agent et AWS Distro. OpenTelemetry Sur ces architectures activées avec une configuration personnalisée d’Application Signals, Application Signals ne découvre pas automatiquement les noms de vos services ni les hôtes ou clusters sur lesquels ils s’exécutent. Vous devez spécifier ces noms lors de la configuration personnalisée, et les noms que vous spécifiez sont ceux qui sont affichés sur les tableaux de bord d’Application Signals.
**Exigences**
+ Vous devez disposer de l’autorisation d’administrateur sur le cluster Kubernetes sur lequel vous activez la vigie applicative.
+ Vous devez l'avoir AWS CLI installé sur l'environnement dans lequel votre cluster Kubernetes est exécuté. Pour plus d'informations sur l'installation du AWS CLI, voir [Installer ou mettre à jour la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ Vous devez avoir installé kubectl et helm sur votre terminal local. Pour plus d’informations, consultez la documentation [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) et [Helm](https://helm.sh/).
## Étape 1 : activer Application Signals dans votre compte
Vous devez d’abord activer la vigie applicative dans votre compte. Si ce n’est pas déjà fait, consultez [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md).
## Étape 2 : Installation de l'opérateur CloudWatch agent dans votre cluster
L'installation de l'opérateur CloudWatch agent installe l'opérateur, l' CloudWatch agent et d'autres instruments automatiques dans votre cluster. Pour ce faire, entrez la commande suivante. Remplacez *\$1REGION* par votre AWS région. *\$1YOUR\$1CLUSTER\$1NAME*Remplacez-le par le nom que vous souhaitez voir apparaître pour votre cluster dans les tableaux de bord des signaux d'application.
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm install amazon-cloudwatch-operator aws-observability/amazon-cloudwatch-observability \
--namespace amazon-cloudwatch --create-namespace \
--set region=$REGION \
--set clusterName=$YOUR_CLUSTER_NAME
```
Pour plus d'informations, voir [ amazon-cloudwatch-observability](https://github.com/aws-observability/helm-charts/tree/main/charts/amazon-cloudwatch-observability)ci-dessous GitHub.
## Étape 3 : configurer les AWS informations d'identification pour vos clusters Kubernetes
**Important**
Si votre cluster Kubernetes est hébergé sur Amazon EC2, vous pouvez ignorer cette section et passer à [Étape 4 : ajouter des annotations](#Application-Signals-Enable-Kubernetes-annotations).
Si votre cluster Kubernetes est hébergé sur site, vous devez suivre les instructions de cette section pour ajouter des informations d' AWS identification à votre environnement Kubernetes.
**Pour configurer les autorisations pour un cluster Kubernetes sur site**
1. Créer l’utilisateur IAM destiné à fournir les autorisations à votre hôte sur site :
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Sélectionnez **Utilisateurs**, **Créer un utilisateur**.
1. Dans **Détails de l’utilisateur**, pour **Nom d’utilisateur**, saisissez un nom pour le nouvel utilisateur IAM. Il s'agit du nom de connexion AWS qui sera utilisé pour authentifier votre hôte. Ensuite, sélectionnez **Next**
1. Sur la page **Définir les autorisations**, pour les **Options des autorisations**, sélectionnez **Attacher directement les politiques**.
1. Dans la liste des **politiques d'autorisation**, sélectionnez la **CloudWatchAgentServerPolicy**politique à ajouter à votre utilisateur. Ensuite, sélectionnez **Suivant**.
1. Sur la page **Réviser et créer**, assurez-vous que vous êtes satisfait du nom d'utilisateur et que la **CloudWatchAgentServerPolicy**politique figure dans le **résumé des autorisations**.
1. Sélectionnez **Créer un utilisateur**
1. Créez et récupérez votre clé AWS d'accès et votre clé secrète :
1. Dans le volet de navigation de la console IAM, sélectionnez **Utilisateurs**, puis le nom d’utilisateur que vous avez créé à l’étape précédente.
1. Sur la page de l’utilisateur, ouvrez l’onglet **Informations d’identification de sécurité**. Ensuite, dans la section **Clés d’accès**, sélectionnez **Créer une clé d’accès**.
1. Pour **Créer une clé d’accès – Étape 1**, sélectionnez **Interface de ligne de commande (CLI)**.
1. Pour **Créer une clé d’accès – Étape 2**, ajoutez éventuellement une balise puis cliquez sur **Suivant**.
1. Pour **Créer une clé d’accès – Étape 3**, sélectionnez **Télécharger le fichier .csv** pour enregistrer un fichier .csv avec la clé d’accès et la clé d’accès secrète de votre utilisateur IAM. Vous aurez besoin de ces informations pour l’étape suivante.
1. Sélectionnez **Exécuté**.
1. Configurez vos AWS informations d'identification sur votre hôte local en saisissant la commande suivante. Remplacez *ACCESS\$1KEY\$1ID* et *SECRET\$1ACCESS\$1ID* par votre clé d'accès et votre clé d'accès secrète nouvellement générées à partir du fichier .csv que vous avez téléchargé à l'étape précédente. Par défaut, le fichier d’informations d’identification est enregistré dans `/home/user/.aws/credentials.`
```
$ aws configure --profile AmazonCloudWatchAgent
AWS Access Key ID [None]: ACCESS_KEY_ID
AWS Secret Access Key [None]: SECRET_ACCESS_ID
Default region name [None]: MY_REGION
Default output format [None]: json
```
1. Modifiez la ressource personnalisée installée par l' CloudWatch agent à l'aide du graphique Helm pour ajouter le secret AWS d'identification nouvellement créé.
```
kubectl edit amazoncloudwatchagent cloudwatch-agent -n amazon-cloudwatch
```
1. Lorsque votre éditeur de fichiers est ouvert, montez les AWS informations d'identification dans le conteneur de l' CloudWatch agent en ajoutant la configuration suivante en haut du déploiement. Remplacez le chemin `/home/user/.aws/credentials` par l'emplacement de votre fichier d' AWS informations d'identification local.
```
apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
name: cloudwatch-agent
namespace: amazon-cloudwatch
spec:
volumeMounts:
- mountPath: /rootfs
volumeMounts:
- name: aws-credentials
mountPath: /root/.aws
readOnly: true
volumes:
- hostPath:
path: /home/user/.aws/credentials
name: aws-credentials
---
```
## Étape 4 : ajouter des annotations
**Note**
Si vous activez la vigie applicative pour une application Node.js avec ESM, veuillez ignorer les étapes de cette section et consulter plutôt [Configuration d’une application Node.js utilisant le format de module ESM](#Kubernetes-NodeJs-ESM).
[https://kubernetes.io/docs/concepts/workloads/](https://kubernetes.io/docs/concepts/workloads/) Cette annotation instrumente automatiquement votre application pour envoyer des métriques, des traces et des journaux à la vigie applicative.
**Pour ajouter les annotations pour la vigie applicative**
1. Vous avez deux options pour l’annotation :
+ **Annoter la charge de travail** instrumente automatiquement une seule charge de travail dans un cluster.
+ **Annoter l’espace de noms** permet d’instrumenter automatiquement toutes les charges de travail déployées dans l’espace de noms sélectionné.
Choisissez l’une de ces options, puis suivez les étapes appropriées.
1. Pour annoter une seule charge de travail, entrez l’une des commandes suivantes. Remplacez *\$1WORKLOAD\$1TYPE* et *\$1WORKLOAD\$1NAME* par les valeurs correspondant à votre charge de travail.
+ Pour les charges de travail Java :
```
kubectl patch $WORKLOAD_TYPE $WORKLOAD_NAME -p '{"spec": {"template": {"metadata": {"annotations": {"instrumentation.opentelemetry.io/inject-java": "true"}}}}}'
```
+ Pour les charges de travail Python :
```
kubectl patch $WORKLOAD_TYPE $WORKLOAD_NAME -p '{"spec": {"template": {"metadata": {"annotations": {"instrumentation.opentelemetry.io/inject-python": "true"}}}}}'
```
Pour les applications Python, des configurations supplémentaires sont requises. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
+ Pour les charges de travail .NET :
```
kubectl patch $WORKLOAD_TYPE $WORKLOAD_NAME -p '{"spec": {"template": {"metadata": {"annotations": {"instrumentation.opentelemetry.io/inject-dotnet": "true"}}}}}'
```
**Note**
Pour activer la vigie applicative pour une charge de travail .NET sur des images basées sur Alpine Linux (`linux-musl-x64`), veuillez ajouter l’annotation supplémentaire suivante.
```
instrumentation.opentelemetry.io/otel-dotnet-auto-runtime: "linux-musl-x64"
```
+ Pour les charges de travail Node.js :
```
kubectl patch $WORKLOAD_TYPE $WORKLOAD_NAME -p '{"spec": {"template": {"metadata": {"annotations": {"instrumentation.opentelemetry.io/inject-nodejs": "true"}}}}}'
```
1. Pour annoter toutes les charges de travail d’un espace de noms, veuillez saisir l’une des commandes suivantes. Remplacez *\$1NAMESPACE* par le nom de votre espace de noms.
Si l’espace de noms comprend des charges de travail Java, Python et .NET, veuillez ajouter toutes les annotations à l’espace de noms.
+ Pour les charges de travail Java dans l’espace de noms :
```
kubectl annotate ns $NAMESPACE instrumentation.opentelemetry.io/inject-java=true
```
+ Pour les charges de travail Python dans l’espace de noms :
```
kubectl annotate ns $NAMESPACE instrumentation.opentelemetry.io/inject-python=true
```
Pour les applications Python, des configurations supplémentaires sont requises. Pour de plus amples informations, veuillez consulter [L’application Python ne démarre pas après l’activation de la vigie applicative](CloudWatch-Application-Signals-Enable-Troubleshoot.md#Application-Signals-troubleshoot-starting-Python).
+ Pour les charges de travail .NET dans l’espace de noms :
```
kubectl annotate ns $NAMESPACE instrumentation.opentelemetry.io/inject-dotnet=true
```
+ Pour les charges de travail Node.js dans l’espace de noms :
```
kubectl annotate ns $NAMESPACE instrumentation.opentelemetry.io/inject-nodejs=true
```
Après avoir ajouté les annotations, redémarrez tous les pods de l’espace de noms en saisissant la commande suivante :
```
kubectl rollout restart
```
1. Lorsque les étapes précédentes sont terminées, dans la CloudWatch console, choisissez **Application Signals**, **Services**. Cela ouvre les tableaux de bord où vous pouvez voir les données collectées par la vigie applicative CloudWatch. Les données peuvent prendre quelques minutes pour s’afficher.
Pour plus d’informations sur la vue **Services**, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
### Configuration d’une application Node.js utilisant le format de module ESM
Un support limité est disponible pour les applications Node.js utilisant le format de module ESM. Pour en savoir plus, consultez [Limitations connues concernant Node.js avec ESM](CloudWatch-Application-Signals-supportmatrix.md#ESM-limitations).
Pour le format de module ESM, l’activation de la vigie applicative en annotant le fichier manifeste ne fonctionne pas. Sautez la procédure précédente et procédez comme suit à la place :
**Pour activer la vigie applicative pour une application Node.js avec ESM**
1. Installez les dépendances nécessaires à l’instrumentation automatique dans votre application Node.js :
```
npm install @aws/aws-distro-opentelemetry-node-autoinstrumentation
npm install @opentelemetry/instrumentation@0.54.0
```
1. Ajoutez les variables d’environnement suivantes au Dockerfile de votre application, puis construisez l’image.
```
...
ENV OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true
ENV OTEL_TRACES_SAMPLER_ARG='endpoint=http://cloudwatch-agent.amazon-cloudwatch:2000'
ENV OTEL_TRACES_SAMPLER='xray'
ENV OTEL_EXPORTER_OTLP_PROTOCOL='http/protobuf'
ENV OTEL_EXPORTER_OTLP_TRACES_ENDPOINT='http://cloudwatch-agent.amazon-cloudwatch:4316/v1/traces'
ENV OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT='http://cloudwatch-agent.amazon-cloudwatch:4316/v1/metrics'
ENV OTEL_METRICS_EXPORTER='none'
ENV OTEL_LOGS_EXPORTER='none'
ENV NODE_OPTIONS='--import @aws/aws-distro-opentelemetry-node-autoinstrumentation/register --experimental-loader=@opentelemetry/instrumentation/hook.mjs'
ENV OTEL_SERVICE_NAME='YOUR_SERVICE_NAME' #replace with a proper service name
ENV OTEL_PROPAGATORS='tracecontext,baggage,b3,xray'
...
# command to start the application
# for example
# CMD ["node", "index.mjs"]
```
1. Ajoutez les variables d’environnement `OTEL_RESOURCE_ATTRIBUTES_POD_NAME`, `OTEL_RESOURCE_ATTRIBUTES_NODE_NAME`, `OTEL_RESOURCE_ATTRIBUTES_DEPLOYMENT_NAME`, `POD_NAMESPACE` et `OTEL_RESOURCE_ATTRIBUTES` au fichier YAML de déploiement de votre application. Par exemple :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nodejs-app
labels:
app: nodejs-app
spec:
replicas: 2
selector:
matchLabels:
app: nodejs-app
template:
metadata:
labels:
app: nodejs-app
# annotations:
# make sure this annotation doesn't exit
# instrumentation.opentelemetry.io/inject-nodejs: 'true'
spec:
containers:
- name: nodejs-app
image:your-nodejs-application-image #replace it with a proper image uri
imagePullPolicy: Always
ports:
- containerPort: 8000
env:
- name: OTEL_RESOURCE_ATTRIBUTES_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: OTEL_RESOURCE_ATTRIBUTES_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: OTEL_RESOURCE_ATTRIBUTES_DEPLOYMENT_NAME
valueFrom:
fieldRef:
fieldPath: metadata.labels['app'] # Assuming 'app' label is set to the deployment name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: OTEL_RESOURCE_ATTRIBUTES
value: "k8s.deployment.name=$(OTEL_RESOURCE_ATTRIBUTES_DEPLOYMENT_NAME),k8s.namespace.name=$(POD_NAMESPACE),k8s.node.name=$(OTEL_RESOURCE_ATTRIBUTES_NODE_NAME),k8s.pod.name=$(OTEL_RESOURCE_ATTRIBUTES_POD_NAME)"
```
1. Déployez l’application Node.js sur le cluster Kubernetes.
## (Facultatif) Étape 5 : surveiller l’état de votre application
Une fois que vous avez activé vos applications sur Kubernetes, vous pouvez surveiller l’état de votre application. Pour de plus amples informations, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
# Activer vos applications sur Lambda
Vous pouvez activer la vigie applicative pour vos fonctions Lambda. Application Signals instrumente automatiquement vos fonctions Lambda à l'aide des bibliothèques AWS Distro for OpenTelemetry (ADOT) améliorées, fournies via une couche Lambda. Cette couche AWS Lambda permet d' OpenTelemetryempaqueter et de déployer les bibliothèques requises pour l'instrumentation automatique des signaux d'application.
En plus de prendre en charge les signaux d'application, cette couche Lambda est également un composant du OpenTelemetry support Lambda et fournit des fonctionnalités de suivi.
Vous pouvez également améliorer l’observabilité de Lambda en utilisant la recherche de transactions, qui permet de capturer des intervalles de traçage pour l’invocation de fonctions Lambda sans échantillonnage. Cette fonctionnalité vous permet de collecter des intervalles pour vos fonctions, sans être affecté par l’indicateur `sampled` dans la propagation du contexte de trace. Cela garantit qu’il n’y a pas d’impact supplémentaire sur les services dépendants en aval. En activant la recherche de transactions sur Lambda, vous bénéficiez d’une visibilité complète sur les performances de vos fonctions et vous pouvez résoudre les problèmes qui surviennent rarement. Consultez [Recherche de transactions](CloudWatch-Transaction-Search.md) pour démarrer
**Topics**
+ [Prise en main](#Application-Signals-Enable-Lambda-Methods-Getting-Started)
+ [Utiliser la console CloudWatch Application Signals](#Enable-Lambda-CWConsole)
+ [Utiliser la console Lambda](#Enable-Lambda-LambdaConsole)
+ [Activez les signaux d'application sur Lambda à l'aide de AWS CDK](#CloudWatch-Application-Signals-Lambda-CDK)
+ [Activer les signaux d'application sur Lambda à l'aide du protocole MCP (Model Context Protocol)](#CloudWatch-Application-Signals-Lambda-MCP)
+ [(Facultatif) Surveiller l’état de votre application](#CloudWatch-Application-Signals-Monitor-Lambda)
+ [Activez manuellement la vigie applicative.](#Enable-Lambda-Manually)
+ [Désactiver manuellement la vigie applicative](#Disable-Lambda-Manually)
+ [Configuration d’Application Signals](#Configuring-Lambda-AppSignals)
+ [AWS Lambda Layer pour OpenTelemetry ARNs](#Enable-Lambda-Layers)
+ [Déployer des fonctions Lambda à l’aide du conteneur Amazon ECR](#containerized-lambda)
## Prise en main
Il existe trois méthodes pour activer la vigie applicative pour vos fonctions Lambda.
Une fois que vous avez activé la vigie applicative pour une fonction Lambda, il faut quelques minutes pour que les données de télémétrie de cette fonction apparaissent dans la console de la vigie applicative.
+ Utiliser la console CloudWatch Application Signals
+ Utiliser la console Lambda
+ Ajoutez manuellement la couche AWS Lambda pour OpenTelemetry à l'exécution de votre fonction Lambda.
Chacune de ces méthodes ajoute la couche AWS Lambda pour OpenTelemetry à votre fonction.
## Utiliser la console CloudWatch Application Signals
Suivez ces étapes pour utiliser la console de la vigie applicative afin d’activer la vigie applicative pour une fonction Lambda.
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation du service, choisissez **Application Signals**, **Services**.
1. Dans la zone de liste **Services**, sélectionnez **Activer la vigie applicative**.
1. Sélectionnez la vignette **Lambda**.
1. Sélectionnez chaque fonction que vous voulez activer pour la vigie applicative, puis sélectionnez **Terminé**.
## Utiliser la console Lambda
Suivez ces étapes pour utiliser la console Lambda afin d’activer la vigie applicative pour une fonction Lambda.
1. Ouvrez la AWS Lambda console à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. Dans le volet de navigation, sélectionnez **Fonctions**, puis choisissez le nom de la fonction que vous voulez activer.
1. Sélectionnez l’onglet **Configuration**, puis choisissez **Outils de surveillance et d’opérations**.
1. Choisissez **Modifier**.
1. Dans la section **CloudWatch Application Signals and X-Ray**, sélectionnez à la fois **Collecter automatiquement les traces d'applications et les métriques d'application standard avec les signaux d'application** et **Collecter automatiquement les traces de service Lambda pour une visibilité de bout en bout avec X-Ray**. .
1. Choisissez **Enregistrer**.
## Activez les signaux d'application sur Lambda à l'aide de AWS CDK
Si vous n’avez pas encore activé Application Signals dans ce compte, vous devez accorder à Application Signals les autorisations nécessaires pour découvrir vos services. Pour de plus amples informations, veuillez consulter [Activation de la vigie applicative dans votre compte](CloudWatch-Application-Signals-Enable.md).
1. Activer la vigie applicative pour vos applications
```
import { aws_applicationsignals as applicationsignals } from 'aws-cdk-lib';
const cfnDiscovery = new applicationsignals.CfnDiscovery(this,
'ApplicationSignalsServiceRole', { }
);
```
La CloudFormation ressource Discovery accorde à Application Signals les autorisations suivantes :
+ `xray:GetServiceGraph`
+ `logs:StartQuery`
+ `logs:GetQueryResults`
+ `cloudwatch:GetMetricData`
+ `cloudwatch:ListMetrics`
+ `tag:GetResources`
Pour plus d’informations sur ce rôle, consultez [Autorisations de rôle liées au service pour les signaux d'application CloudWatch](using-service-linked-roles.md#service-linked-role-signals).
1. Ajoutez la politique IAM `CloudWatchLambdaApplicationSignalsExecutionRolePolicy` à la fonction Lambda.
```
const fn = new Function(this, 'DemoFunction', {
code: Code.fromAsset('$YOUR_LAMBDA.zip'),
runtime: Runtime.PYTHON_3_12,
handler: '$YOUR_HANDLER'
})
fn.role?.addManagedPolicy(ManagedPolicy.fromAwsManagedPolicyName('CloudWatchLambdaApplicationSignalsExecutionRolePolicy'));
```
1. `$AWS_LAMBDA_LAYER_FOR_OTEL_ARN`Remplacez-la par la [couche AWS Lambda pour l' OpenTelemetry ARN](https://aws-otel.github.io/docs/getting-started/lambda#adot-lambda-layer-arns) réelle de votre région.
```
fn.addLayers(LayerVersion.fromLayerVersionArn(
this, 'AwsLambdaLayerForOtel',
'$AWS_LAMBDA_LAYER_FOR_OTEL_ARN'
))
fn.addEnvironment("AWS_LAMBDA_EXEC_WRAPPER", "/opt/otel-instrument");
```
## Activer les signaux d'application sur Lambda à l'aide du protocole MCP (Model Context Protocol)
Vous pouvez utiliser le serveur MCP ( CloudWatch Application Signals Model Context Protocol) pour activer les signaux d'application sur vos fonctions Lambda par le biais d'interactions conversationnelles avec l'IA. Cela fournit une interface en langage naturel pour configurer la surveillance des signaux d'application.
Le serveur MCP automatise le processus d'activation en comprenant vos besoins et en générant la configuration appropriée. Au lieu de suivre manuellement les étapes de la console ou d'écrire du code CDK, vous pouvez simplement décrire ce que vous souhaitez activer.
### Conditions préalables
Avant d'utiliser le serveur MCP pour activer les signaux d'application, assurez-vous d'avoir :
+ Un environnement de développement compatible avec MCP (tel que Kiro, Claude Desktop, VSCode avec des extensions MCP ou d'autres outils compatibles avec MCP)
+ Le serveur MCP CloudWatch Application Signals configuré dans votre IDE. Pour obtenir des instructions de configuration détaillées, consultez la [documentation du serveur MCP CloudWatch Application Signals](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
### Utilisation du serveur MCP
Une fois que vous avez configuré le serveur MCP CloudWatch Application Signals dans votre IDE, vous pouvez demander des conseils d'activation à l'aide d'instructions en langage naturel. Bien que l'assistant de codage puisse déduire le contexte à partir de la structure de votre projet, le fait de fournir des informations spécifiques dans vos instructions permet de garantir des conseils plus précis et plus pertinents. Incluez des informations telles que le langage de programmation de votre fonction Lambda, le nom de la fonction et les chemins absolus vers votre code de fonction Lambda et votre code d'infrastructure.
**Instructions relatives aux meilleures pratiques (spécifiques et complètes) :**
```
"Enable Application Signals for my Python Lambda function.
My function code is in /home/user/order-processor/lambda and IaC is in /home/user/order-processor/terraform"
"I want to add observability to my Node.js Lambda function 'checkout-handler'.
The function code is at /Users/dev/checkout-function and
the CDK infrastructure is at /Users/dev/checkout-function/cdk"
"Help me instrument my Java Lambda function with Application Signals.
Function directory: /opt/apps/payment-lambda
CDK infrastructure: /opt/apps/payment-lambda/cdk"
```
**Des instructions moins efficaces :**
```
"Enable monitoring for my Lambda"
→ Missing: language, paths
"Enable Application Signals. My code is in ./src and IaC is in ./infrastructure"
→ Problem: Relative paths instead of absolute paths
"Enable Application Signals for my Lambda at /home/user/myfunction"
→ Missing: programming language
```
**Modèle rapide :**
```
"Enable Application Signals for my [LANGUAGE] Lambda function.
Function code: [ABSOLUTE_PATH_TO_FUNCTION]
IaC code: [ABSOLUTE_PATH_TO_IAC]"
```
### Avantages de l'utilisation du serveur MCP
L'utilisation du serveur MCP CloudWatch Application Signals présente plusieurs avantages :
+ **Interface en langage naturel :** décrivez ce que vous souhaitez activer sans mémoriser les commandes ou la syntaxe de configuration
+ **Conseils contextuels :** le serveur MCP comprend votre environnement spécifique et fournit des recommandations personnalisées
+ **Réduction des erreurs :** la génération automatique de configuration minimise les erreurs de saisie manuelle
+ **Configuration plus rapide : passez** plus rapidement de l'intention à la mise en œuvre
+ **Outil d'apprentissage :** découvrez les configurations générées et comprenez le fonctionnement des signaux d'application
Pour plus d'informations sur la configuration et l'utilisation du serveur CloudWatch Application Signals MCP, consultez la documentation du [serveur MCP](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server).
## (Facultatif) Surveiller l’état de votre application
Une fois vos applications activées sur Lambda, vous pouvez surveiller leur état de santé. Pour de plus amples informations, veuillez consulter [Surveillez l’état de fonctionnement de vos applications avec Application Signals](Services.md).
## Activez manuellement la vigie applicative.
Suivez ces étapes pour activer manuellement la vigie applicative pour une fonction Lambda.
1. Ajoutez la couche AWS Lambda pour OpenTelemetry à votre environnement d'exécution Lambda. Pour trouver l'ARN de la couche correspondant à votre région, consultez la couche [ ARNsLambda ADOT](https://aws-otel.github.io/docs/getting-started/lambda#adot-lambda-layer-arns).
1. Ajouter la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument`
Ajoutez la variable d’environnement `LAMBDA_APPLICATION_SIGNALS_REMOTE_ENVIRONMENT` pour configurer des environnements Lambda personnalisés. Par défaut, les environnements Lambda sont configurés sur `lambda:default`.
1. Associez la politique IAM AWS gérée **CloudWatchLambdaApplicationSignalsExecutionRolePolicy**au rôle d'exécution Lambda.
1. (Facultatif) Nous vous recommandons d’activer le traçage actif Lambda pour bénéficier d’une meilleure expérience de traçage. Pour plus d'informations, voir [Visualiser les invocations de fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html) à l'aide de. AWS X-Ray
## Désactiver manuellement la vigie applicative
Pour désactiver manuellement les signaux d'application pour une fonction Lambda, supprimez la couche AWS Lambda de OpenTelemetry votre environnement d'exécution Lambda et supprimez la variable d'environnement. `AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-instrument`
## Configuration d’Application Signals
Vous pouvez utiliser cette section pour configurer la vigie applicative dans Lambda.
**Regrouper plusieurs fonctions Lambda en un seul service**
La variable d’environnement `OTEL_SERVICE_NAME` définit le nom du service. Ce nom s’affichera dans les tableaux de bord de la vigie applicative comme nom du service de votre application. Vous pouvez attribuer le même nom de service à plusieurs fonctions Lambda, qui seront alors fusionnées en un seul service dans la vigie applicative. Si vous ne fournissez pas de valeur pour cette clé, le nom de fonction Lambda par défaut est utilisé.
**Prélèvement**
Par défaut, la stratégie d’échantillonnage des traces est basée sur le parent. Vous pouvez ajuster la stratégie d’échantillonnage en définissant les variables d’environnement `OTEL_TRACES_SAMPLER`.
Par exemple, définissez le taux d’échantillonnage des traces à 30 %.
```
OTEL_TRACES_SAMPLER=traceidratio
OTEL_TRACES_SAMPLER_ARG=0.3
```
Pour plus d'informations, consultez la section [Spécification des variables d'OpenTelemetry environnement](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/).
**Activation de toutes les instrumentations de bibliothèque**
Pour réduire les démarrages à froid Lambda, par défaut, seuls les AWS SDK et les instruments HTTP sont activés pour Python, Node et Java. Vous pouvez définir des variables d’environnement pour activer l’instrumentation d’autres bibliothèques utilisées dans votre fonction Lambda.
+ Python – `OTEL_PYTHON_DISABLED_INSTRUMENTATIONS=none`
+ Nœud : `OTEL_NODE_DISABLED_INSTRUMENTATIONS=none`
+ Java : `OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED=true`
## AWS Lambda Layer pour OpenTelemetry ARNs
Pour obtenir la liste complète des couches AWS Lambda OpenTelemetry ARNs par région et par environnement d'exécution, consultez la documentation relative à la ARNs couche [Lambda ADOT](https://aws-otel.github.io/docs/getting-started/lambda#adot-lambda-layer-arns) dans AWS la distribution. OpenTelemetry La couche est disponible pour les environnements d'exécution Python, Node.js, .NET et Java.
## Déployer des fonctions Lambda à l’aide du conteneur Amazon ECR
Les fonctions Lambda déployées sous forme d’images de conteneur ne prennent pas en charge les couches Lambda de manière traditionnelle. Lorsque vous utilisez des images de conteneur, vous ne pouvez pas attacher une couche comme vous le feriez avec d’autres méthodes de déploiement Lambda. Vous devez plutôt intégrer manuellement le contenu de la couche dans votre image de conteneur pendant le processus de compilation.
------
#### [ Java ]
Vous pouvez apprendre à intégrer la couche AWS Lambda pour OpenTelemetry dans votre fonction Java Lambda conteneurisée, télécharger l'artefact et `layer.zip` l'intégrer dans votre conteneur de fonctions Java Lambda pour permettre la surveillance des signaux d'application.
**Conditions préalables**
+ AWS CLI configuré avec vos informations d'identification
+ Docker installé
+ Ces instructions supposent que vous utilisez une plateforme x86\$164
1. **Configurer la structure du projet**
Créez un répertoire pour votre fonction Lambda
```
mkdir java-appsignals-container-lambda && \
cd java-appsignals-container-lambda
```
Créez une structure de projet Maven
```
mkdir -p src/main/java/com/example/java/lambda
mkdir -p src/main/resources
```
1. **Créer un fichier Dockerfile**
Téléchargez et intégrez le support OpenTelemetry Layer with Application Signals directement dans votre image de conteneur Lambda. Pour ce faire, le fichier `Dockerfile` est créé.
```
FROM public.ecr.aws/lambda/java:21
# Install utilities
RUN dnf install -y unzip wget maven
# Download the OpenTelemetry Layer with AppSignals Support
RUN wget https://github.com/aws-observability/aws-otel-java-instrumentation/releases/latest/download/layer.zip -O /tmp/layer.zip
# Extract and include Lambda layer contents
RUN mkdir -p /opt && \
unzip /tmp/layer.zip -d /opt/ && \
chmod -R 755 /opt/ && \
rm /tmp/layer.zip
# Copy and build function code
COPY pom.xml ${LAMBDA_TASK_ROOT}
COPY src ${LAMBDA_TASK_ROOT}/src
RUN mvn clean package -DskipTests
# Copy the JAR file to the Lambda runtime directory (from inside the container)
RUN mkdir -p ${LAMBDA_TASK_ROOT}/lib/
RUN cp ${LAMBDA_TASK_ROOT}/target/function.jar ${LAMBDA_TASK_ROOT}/lib/
# Set the handler
CMD ["com.example.java.lambda.App::handleRequest"]
```
**Note**
Le `layer.zip` fichier contient l' OpenTelemetryinstrumentation nécessaire à la prise en charge des signaux d' AWS application pour surveiller votre fonction Lambda.
Les étapes d’extraction de la couche garantissent :
Que le contenu de layer.zip est correctement extrait vers `/opt/ directory`
Que le script `otel-instrument` reçoit les autorisations d’exécution appropriées
Que le fichier temporaire layer.zip soit supprimé afin de réduire la taille de l’image
1. **Code de la fonction Lambda** : créer un fichier Java pour votre gestionnaire Lambda dans `src/main/java/com/example/lambda/App.java:`
Votre projet devrait ressembler à ceci :
```
.
├── Dockerfile
├── pom.xml
└── src
└── main
├── java
│ └── com
│ └── example
│ └── java
│ └── lambda
│ └── App.java
└── resources
```
1. **Créer et déployer l’image du conteneur**
**Configurer les variables d’environnement**
```
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_REGION=$(aws configure get region)
# For fish shell users:
# set AWS_ACCOUNT_ID (aws sts get-caller-identity --query Account --output text)
# set AWS_REGION (aws configure get region)
```
**Authentification avec ECR**
Tout d’abord avec ECR public (pour l’image de base) :
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
Ensuite avec votre ECR privé :
```
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
```
**Créer, baliser et envoyer votre image**
```
# Build the Docker image
docker build -t lambda-appsignals-demo .
# Tag the image
docker tag lambda-appsignals-demo:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
# Push the image
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
```
1. **Créer et configurer la fonction Lambda**
Créez une nouvelle fonction à l’aide de la console Lambda.
Sélectionnez **Image de conteneur** comme option de déploiement.
Choisissez **Parcourir les images** pour sélectionner votre image Amazon ECR.
1. **Tests et vérifications : testez votre Lambda avec un événement simple. Si l’intégration de la couche est réussie, votre Lambda apparaît sous la carte de service de la vigie applicative CloudWatch.**
Vous verrez les traces et les métriques de votre fonction Lambda dans la CloudWatch console.
**Résolution des problèmes**
Si la vigie applicative ne fonctionne pas, veuillez vérifier les points suivants :
+ Vérifiez les journaux de fonctionnement pour détecter toute erreur liée à l' OpenTelemetry instrumentation
+ Vérifiez si la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER` est correctement définie
+ Assurez-vous que l’extraction de la couche dans le fichier Docker s’est terminée avec succès
+ Vérifiez si les autorisations IAM sont correctement associées
+ Si nécessaire, augmentez les paramètres *Timeout et Memory* dans la configuration générale de la fonction Lambda
------
#### [ .Net ]
Vous pouvez apprendre comment intégrer la OpenTelemetry couche avec support des signaux d'application dans votre fonction Lambda .Net conteneurisée, télécharger l'`layer.zip`artefact et l'intégrer dans votre fonction .Net Lambda pour permettre la surveillance des signaux d'application.
**Conditions préalables**
+ AWS CLI configuré avec vos informations d'identification
+ Docker installé
+ Kit SDK .Net 8
+ Ces instructions supposent que vous utilisez une plateforme x86\$164
1. **Configurer la structure du projet**
Créer un répertoire pour l’image de conteneur de votre fonction Lambda
```
mkdir dotnet-appsignals-container-lambda && \
cd dotnet-appsignals-container-lambda
```
1. **Créer un fichier Dockerfile**
Téléchargez et intégrez le support OpenTelemetry Layer with Application Signals directement dans votre image de conteneur Lambda. Pour ce faire, le fichier `Dockerfile` est créé.
```
FROM public.ecr.aws/lambda/dotnet:8
# Install utilities
RUN dnf install -y unzip wget dotnet-sdk-8.0 which
# Add dotnet command to docker container's PATH
ENV PATH="/usr/lib64/dotnet:${PATH}"
# Download the OpenTelemetry Layer with AppSignals Support
RUN wget https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases/latest/download/layer.zip -O /tmp/layer.zip
# Extract and include Lambda layer contents
RUN mkdir -p /opt && \
unzip /tmp/layer.zip -d /opt/ && \
chmod -R 755 /opt/ && \
rm /tmp/layer.zip
WORKDIR ${LAMBDA_TASK_ROOT}
# Copy the project files
COPY dotnet-lambda-function/src/dotnet-lambda-function/*.csproj ${LAMBDA_TASK_ROOT}/
COPY dotnet-lambda-function/src/dotnet-lambda-function/Function.cs ${LAMBDA_TASK_ROOT}/
COPY dotnet-lambda-function/src/dotnet-lambda-function/aws-lambda-tools-defaults.json ${LAMBDA_TASK_ROOT}/
# Install dependencies and build the application
RUN dotnet restore
# Use specific runtime identifier and disable ReadyToRun optimization
RUN dotnet publish -c Release -o out --self-contained false /p:PublishReadyToRun=false
# Copy the published files to the Lambda runtime directory
RUN cp -r out/* ${LAMBDA_TASK_ROOT}/
CMD ["dotnet-lambda-function::dotnet_lambda_function.Function::FunctionHandler"]
```
**Note**
Le `layer.zip` fichier contient l' OpenTelemetryinstrumentation nécessaire à la prise en charge des signaux d' AWS application pour surveiller votre fonction Lambda.
Les étapes d’extraction de la couche garantissent :
Que le contenu de layer.zip est correctement extrait vers `/opt/ directory`
Que le script `otel-instrument` reçoit les autorisations d’exécution appropriées
Que le fichier temporaire layer.zip soit supprimé afin de réduire la taille de l’image
1. **Code de fonction Lambda** — Initialisez votre projet Lambda à l'aide du modèle Lambda .NET : AWS
```
# Install the Lambda templates if you haven't already
dotnet new -i Amazon.Lambda.Templates
# Create a new Lambda project
dotnet new lambda.EmptyFunction -n dotnet-lambda-function
```
Votre projet devrait ressembler à ceci :
```
.
├── Dockerfile
└── dotnet-lambda-function
├── src
│ └── dotnet-lambda-function
│ ├── Function.cs
│ ├── Readme.md
│ ├── aws-lambda-tools-defaults.json
│ └── dotnet-lambda-function.csproj
└── test
└── dotnet-lambda-function.Tests
├── FunctionTest.cs
└── dotnet-lambda-function.Tests.csproj
```
1. **Créer et déployer l’image du conteneur**
**Configurer les variables d’environnement**
```
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_REGION=$(aws configure get region)
# For fish shell users:
# set AWS_ACCOUNT_ID (aws sts get-caller-identity --query Account --output text)
# set AWS_REGION (aws configure get region)
```
Mettez à jour le code `Function.cs` comme suit :
Mettez à jour le code `dotnet-lambda-function.csproj` comme suit :
```
net8.0>/TargetFramework>
enable
enable
true
Lambda
true
true
```
1. **Créer et déployer l’image du conteneur**
Configurer les variables d’environnement
```
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_REGION=$(aws configure get region)
# For fish shell users:
# set AWS_ACCOUNT_ID (aws sts get-caller-identity --query Account --output text)
# set AWS_REGION (aws configure get region)
```
Authentifiez-vous avec Amazon ECR public
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
Authentifiez-vous avec Amazon ECR privé
```
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
```
Créez un référentiel Amazon ECR (si nécessaire)
```
aws ecr create-repository \
--repository-name lambda-appsignals-demo \
--region $AWS_REGION
```
Créez, balisez et envoyez votre image
```
# Build the Docker image
docker build -t lambda-appsignals-demo .
# Tag the image
docker tag lambda-appsignals-demo:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
# Push the image
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
5. Create and Configure the Lambda Function
```
1. **Créer et configurer la fonction Lambda**
Créez une nouvelle fonction à l’aide de la console Lambda.
Sélectionnez **Image de conteneur** comme option de déploiement.
Choisissez **Parcourir les images** pour sélectionner votre image Amazon ECR.
1. **Tests et vérifications : testez votre Lambda avec un événement simple. Si l’intégration de la couche est réussie, votre Lambda apparaît sous la carte de service de la vigie applicative CloudWatch.**
Vous verrez les traces et les métriques de votre fonction Lambda dans la CloudWatch console.
**Résolution des problèmes**
Si la vigie applicative ne fonctionne pas, veuillez vérifier les points suivants :
+ Vérifiez les journaux de fonctionnement pour détecter toute erreur liée à l' OpenTelemetry instrumentation
+ Vérifiez si la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER` est correctement définie
+ Assurez-vous que l’extraction de la couche dans le fichier Docker s’est terminée avec succès
+ Vérifiez si les autorisations IAM sont correctement associées
+ Si nécessaire, augmentez les paramètres *Timeout et Memory* dans la configuration générale de la fonction Lambda
------
#### [ Node.js ]
Vous pouvez apprendre comment intégrer la OpenTelemetry couche avec support des signaux d'application dans votre fonction Lambda Node.js conteneurisée, télécharger l'`layer.zip`artefact et l'intégrer dans votre fonction Lambda Node.js pour permettre la surveillance des signaux d'application.
**Conditions préalables**
+ AWS CLI configuré avec vos informations d'identification
+ Docker installé
+ Ces instructions supposent que vous utilisez une plateforme x86\$164
1. **Configurer la structure du projet**
Créer un répertoire pour l’image de conteneur de votre fonction Lambda
```
mkdir nodejs-appsignals-container-lambda &&\
cd nodejs-appsignals-container-lambda
```
1. **Créer un fichier Dockerfile**
Téléchargez et intégrez le support OpenTelemetry Layer with Application Signals directement dans votre image de conteneur Lambda. Pour ce faire, le fichier `Dockerfile` est créé.
```
# Dockerfile
FROM public.ecr.aws/lambda/nodejs:22
# Install utilities
RUN dnf install -y unzip wget
# Download the OpenTelemetry Layer with AppSignals Support
RUN wget https://github.com/aws-observability/aws-otel-js-instrumentation/releases/latest/download/layer.zip -O /tmp/layer.zip
# Extract and include Lambda layer contents
RUN mkdir -p /opt && \
unzip /tmp/layer.zip -d /opt/ && \
chmod -R 755 /opt/ && \
rm /tmp/layer.zip
# Install npm dependencies
RUN npm init -y
RUN npm install
# Copy function code
COPY *.js ${LAMBDA_TASK_ROOT}/
# Set the CMD to your handler
CMD [ "index.handler" ]
```
**Note**
Le `layer.zip` fichier contient l' OpenTelemetryinstrumentation nécessaire à la prise en charge des signaux d' AWS application pour surveiller votre fonction Lambda.
Les étapes d’extraction de la couche garantissent :
Que le contenu de layer.zip est correctement extrait vers `/opt/ directory`
Que le script `otel-instrument` reçoit les autorisations d’exécution appropriées
Que le fichier temporaire layer.zip soit supprimé afin de réduire la taille de l’image
1. **Code de la fonction Lambda**
Créez un fichier `index.js` avec le contenu suivant :
```
const { S3Client, ListBucketsCommand } = require('@aws-sdk/client-s3');
// Initialize S3 client
const s3Client = new S3Client({ region: process.env.AWS_REGION });
exports.handler = async function(event, context) {
console.log('Received event:', JSON.stringify(event, null, 2));
console.log('Handler initializing:', exports.handler.name);
const response = {
statusCode: 200,
body: {}
};
try {
// List S3 buckets
const command = new ListBucketsCommand({});
const data = await s3Client.send(command);
// Extract bucket names
const bucketNames = data.Buckets.map(bucket => bucket.Name);
response.body = {
message: 'Successfully retrieved buckets',
buckets: bucketNames
};
} catch (error) {
console.error('Error listing buckets:', error);
response.statusCode = 500;
response.body = {
message: `Error listing buckets: ${error.message}`
};
}
return response;
};
```
La structure de votre projet devrait ressembler à ceci :
```
.
├── Dockerfile
└── index.js
```
1. **Créer et déployer l’image du conteneur**
**Configurer les variables d’environnement**
```
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_REGION=$(aws configure get region)
# For fish shell users:
# set AWS_ACCOUNT_ID (aws sts get-caller-identity --query Account --output text)
# set AWS_REGION (aws configure get region)
```
Authentifiez-vous avec Amazon ECR public
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
Authentifiez-vous avec Amazon ECR privé
```
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
```
Créez un référentiel Amazon ECR (si nécessaire)
```
aws ecr create-repository \
--repository-name lambda-appsignals-demo \
--region $AWS_REGION
```
Créez, balisez et envoyez votre image
```
# Build the Docker image
docker build -t lambda-appsignals-demo .
# Tag the image
docker tag lambda-appsignals-demo:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
# Push the image
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
5. Create and Configure the Lambda Function
```
1. **Créer et configurer la fonction Lambda**
Créez une nouvelle fonction à l’aide de la console Lambda.
Sélectionnez **Image de conteneur** comme option de déploiement.
Choisissez **Parcourir les images** pour sélectionner votre image Amazon ECR.
1. **Tests et vérifications : testez votre Lambda avec un événement simple. Si l’intégration de la couche est réussie, votre Lambda apparaît sous la carte de service de la vigie applicative CloudWatch.**
Vous verrez les traces et les métriques de votre fonction Lambda dans la CloudWatch console.
**Résolution des problèmes**
Si la vigie applicative ne fonctionne pas, veuillez vérifier les points suivants :
+ Vérifiez les journaux de fonctionnement pour détecter toute erreur liée à l' OpenTelemetry instrumentation
+ Vérifiez si la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER` est correctement définie
+ Assurez-vous que l’extraction de la couche dans le fichier Docker s’est terminée avec succès
+ Vérifiez si les autorisations IAM sont correctement associées
+ Si nécessaire, augmentez les paramètres *Timeout et Memory* dans la configuration générale de la fonction Lambda
------
#### [ Python ]
Vous pouvez apprendre à intégrer la OpenTelemetry couche avec le support des signaux d'application dans votre fonction Lambda Python conteneurisée, à télécharger l'`layer.zip`artefact et à l'intégrer dans votre fonction Lambda Python pour permettre la surveillance des signaux d'application.
**Conditions préalables**
+ AWS CLI configuré avec vos informations d'identification
+ Docker installé
+ Ces instructions supposent que vous utilisez une plateforme x86\$164
1. **Configurer la structure du projet**
Créer un répertoire pour l’image de conteneur de votre fonction Lambda
```
mkdir python-appsignals-container-lambda &&\
cd python-appsignals-container-lambda
```
1. **Créer un fichier Dockerfile**
Téléchargez et intégrez le support OpenTelemetry Layer with Application Signals directement dans votre image de conteneur Lambda. Pour ce faire, le fichier `Dockerfile` est créé.
```
# Dockerfile
FROM public.ecr.aws/lambda/python:3.13
# Copy function code
COPY app.py ${LAMBDA_TASK_ROOT}
# Install unzip and wget utilities
RUN dnf install -y unzip wget
# Download the OpenTelemetry Layer with AppSignals Support
RUN wget https://github.com/aws-observability/aws-otel-python-instrumentation/releases/latest/download/layer.zip -O /tmp/layer.zip
# Extract and include Lambda layer contents
RUN mkdir -p /opt && \
unzip /tmp/layer.zip -d /opt/ && \
chmod -R 755 /opt/ && \
rm /tmp/layer.zip
# Set the CMD to your handler
CMD [ "app.lambda_handler" ]
```
**Note**
Le `layer.zip` fichier contient l' OpenTelemetryinstrumentation nécessaire à la prise en charge des signaux d' AWS application pour surveiller votre fonction Lambda.
Les étapes d’extraction de la couche garantissent :
Que le contenu de layer.zip est correctement extrait vers `/opt/ directory`
Que le script `otel-instrument` reçoit les autorisations d’exécution appropriées
Que le fichier temporaire layer.zip soit supprimé afin de réduire la taille de l’image
1. **Code de la fonction Lambda**
Créez votre fonction Lambda dans un fichier `app.py` :
```
import json
import boto3
def lambda_handler(event, context):
"""
Sample Lambda function that can be used in a container image.
Parameters:
-----------
event: dict
Input event data
context: LambdaContext
Lambda runtime information
Returns:
__
dict
Response object
"""
print("Received event:", json.dumps(event, indent=2))
# Create S3 client
s3 = boto3.client('s3')
try:
# List buckets
response = s3.list_buckets()
# Extract bucket names
buckets = [bucket['Name'] for bucket in response['Buckets']]
return {
'statusCode': 200,
'body': json.dumps({
'message': 'Successfully retrieved buckets',
'buckets': buckets
})
}
except Exception as e:
print(f"Error listing buckets: {str(e)}")
return {
'statusCode': 500,
'body': json.dumps({
'message': f'Error listing buckets: {str(e)}'
})
}
```
La structure de votre projet devrait ressembler à ceci :
```
.
├── Dockerfile
├── app.py
└── instructions.md
```
1. **Créer et déployer l’image du conteneur**
**Configurer les variables d’environnement**
```
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_REGION=$(aws configure get region)
# For fish shell users:
# set AWS_ACCOUNT_ID (aws sts get-caller-identity --query Account --output text)
# set AWS_REGION (aws configure get region)
```
Authentifiez-vous avec Amazon ECR public
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
Authentifiez-vous avec Amazon ECR privé
```
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
```
Créez un référentiel Amazon ECR (si nécessaire)
```
aws ecr create-repository \
--repository-name lambda-appsignals-demo \
--region $AWS_REGION
```
Créez, balisez et envoyez votre image
```
# Build the Docker image
docker build -t lambda-appsignals-demo .
# Tag the image
docker tag lambda-appsignals-demo:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
# Push the image
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/lambda-appsignals-demo:latest
5. Create and Configure the Lambda Function
```
1. **Créer et configurer la fonction Lambda**
Créez une nouvelle fonction à l’aide de la console Lambda.
Sélectionnez **Image de conteneur** comme option de déploiement.
Choisissez **Parcourir les images** pour sélectionner votre image Amazon ECR.
1. **Tests et vérifications : testez votre Lambda avec un événement simple. Si l’intégration de la couche est réussie, votre Lambda apparaît sous la carte de service de la vigie applicative CloudWatch.**
Vous verrez les traces et les métriques de votre fonction Lambda dans la CloudWatch console.
**Résolution des problèmes**
Si la vigie applicative ne fonctionne pas, veuillez vérifier les points suivants :
+ Vérifiez les journaux de fonctionnement pour détecter toute erreur liée à l' OpenTelemetry instrumentation
+ Vérifiez si la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER` est correctement définie
+ Assurez-vous que l’extraction de la couche dans le fichier Docker s’est terminée avec succès
+ Vérifiez si les autorisations IAM sont correctement associées
+ Si nécessaire, augmentez les paramètres *Timeout et Memory* dans la configuration générale de la fonction Lambda
------
# Résolution des problèmes liés à l’installation d’Application Signals
Cette section contient des conseils de résolution des problèmes relatifs aux signaux CloudWatch d'application.
**Topics**
+ [Résoudre les conflits OpenTelemetry de configuration dans Amazon EKS avec les signaux d'application](#Application-Signals-troubleshoot-eks-applications)
+ [Performances de démarrage à froid de la couche Java de la vigie applicative](#Application-Signals-troubleshoot-cold-start-performance)
+ [L’application ne démarre pas après l’activation d’Application Signals](#Application-Signals-troubleshoot-starting)
+ [L’application Python ne démarre pas après l’activation de la vigie applicative](#Application-Signals-troubleshoot-starting-Python)
+ [Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI](#Application-Signals-troubleshoot-Python-WSGI)
+ [Mon application Node.js n’est pas instrumentée ou ne génère pas de télémétrie de la vigie applicative](#Application-Signals-troubleshoot-telemetry-nodejs)
+ [Mon application .NET n'est pas instrumentée ou s'arrête à cause des appels du AWS SDK](#Application-Signals-troubleshoot-sdk-calls)
+ [Aucune donnée d’application dans le tableau de bord de la vigie applicative](#Application-Signals-troubleshoot-missingdata)
+ [Les métriques de service ou de dépendance ont des valeurs inconnues](#Application-Signals-troubleshoot-unknown-values)
+ [Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS](#Application-Signals-troubleshoot-conflict)
+ [Je veux filtrer les métriques et les traces inutiles](#Application-Signals-troubleshoot-cardinality)
+ [Que signifie `InternalOperation` ?](#Application-Signals-troubleshoot-InternalOperation)
+ [Comment activer la journalisation pour les applications .NET ?](#Application-Signals-troubleshoot-dotnet-logging)
+ [Comment résoudre les conflits de version d’assembly dans les applications .NET ?](#Application-Signals-troubleshoot-dotnet-conflicts)
+ [Puis-je le désactiver FluentBit ?](#Application-Signals-troubleshoot-FluentBit)
+ [Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ?](#Application-Signals-troubleshoot-filter-logs)
+ [Résolution TypeError lors de l'utilisation de AWS Distro pour la couche Lambda OpenTelemetry JavaScript (ADOT)](#lambda-execution)
+ [TypeError lors de l'utilisation de gestionnaires Lambda Response Streaming avec AWS Distro for ( OpenTelemetry ADOT) Lambda Layer JavaScript](#lambda-execution-streaming)
+ [Mettez à jour les versions requises des agents ou du module complémentaire Amazon EKS](#CloudWatch-Application-Signals-Agent-Versions)
+ [Format de métrique intégré (EMF) désactivé pour la vigie applicative](#emf-appsignals)
## Résoudre les conflits OpenTelemetry de configuration dans Amazon EKS avec les signaux d'application
Si vous utilisez OpenTelemetry (OTel) pour la surveillance des performances des applications (APM) avec Amazon EKS et que vous configurez des points de terminaison d'exportation OTLP personnalisés autres que les points de CloudWatch terminaison, vous pouvez rencontrer les comportements suivants après l'installation ou la mise à niveau vers le module complémentaire CloudWatch Observability version 5.0.0 ou ultérieure :
+ Interruption de la OTel télémétrie existante : le module complémentaire d' CloudWatch observabilité peut remplacer les points de terminaison de l'exportateur OTLP que vous avez codés en dur dans votre application. Cette dérogation n'affecte pas les points de terminaison configurés via des variables d'environnement de conteneur ou. `envFrom` ConfigMap En cas de remplacement, vos statistiques et vos traces risquent de ne pas atteindre leur destination prévue. Pour conserver votre configuration APM existante après la mise à niveau vers la version 5.0.0 ou ultérieure, voir [Désactiver les signaux d'application](install-CloudWatch-Observability-EKS-addon.md#Opting-out-App-Signals)
+ Les signaux d'application risquent de ne pas fonctionner si vous avez déjà activé les signaux d'application à l'aide du module complémentaire CloudWatch Observability et si vous avez configuré un point de terminaison OTLP personnalisé. Pour résoudre ce problème, supprimez les points de terminaison OTLP personnalisés ou définissez la variable d'environnement `OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true` lors de l'installation ou de la mise à niveau vers la version 5.0.0 ou ultérieure
## Performances de démarrage à froid de la couche Java de la vigie applicative
L’ajout de la couche de la vigie applicative aux fonctions Lambda Java augmente la latence de démarrage (temps de démarrage à froid). Les conseils suivants peuvent vous aider à réduire la latence pour les fonctions sensibles au temps.
**Démarrage rapide pour l’agent Java** : la couche Lambda Java de la vigie applicative comprend une fonctionnalité de démarrage rapide qui est désactivée par défaut, mais qui peut être activée en définissant la variable OTEL\$1JAVA\$1AGENT\$1FAST\$1STARTUP\$1ENABLED sur true. Lorsqu’elle est activée, cette fonctionnalité configure la JVM pour qu’elle utilise le compilateur C1 de niveau 1 afin de générer un code natif optimisé pour un démarrage à froid plus rapide. Le compilateur C1 privilégie la vitesse au détriment de l’optimisation à long terme, tandis que le compilateur C2 offre des performances globales supérieures en profilant les données au fil du temps.
Pour plus d’informations, consultez [Démarrage rapide pour l’agent Java](https://github.com/open-telemetry/opentelemetry-lambda/blob/main/java/README.md#fast-startup-for-java-agent).
**Réduisez les temps de démarrage à froid grâce à la simultanéité provisionnée** : la AWS Lambda simultanéité provisionnée préalloue un nombre spécifié d'instances de fonction, les gardant initialisées et prêtes à traiter les demandes immédiatement. Cela réduit les temps de démarrage à froid en éliminant la nécessité d’initialiser l’environnement de la fonction pendant l’exécution, garantissant des performances plus rapides et plus cohérentes, en particulier pour les charges de travail sensibles à la latence. Pour plus d’informations, consultez [Configuration de la simultanéité provisionnée pour une fonction](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html).
**Optimisation des performances de démarrage à l'aide de Lambda SnapStart** : AWS Lambda SnapStart fonctionnalité qui optimise les performances de démarrage des fonctions Lambda en créant un instantané préinitialisé de l'environnement d'exécution après la phase d'initialisation de la fonction. Cet instantané est ensuite réutilisé pour démarrer de nouvelles instances, ce qui réduit considérablement les temps de démarrage à froid en sautant le processus d’initialisation lors de l’invocation de la fonction. Pour plus d'informations, voir [Améliorer les performances de démarrage avec Lambda SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)
## L’application ne démarre pas après l’activation d’Application Signals
Si votre application sur un cluster Amazon EKS ne démarre pas une fois que vous avez activé Application Signals sur le cluster, vérifiez les points suivants :
+ Vérifiez si l’application a été instrumentée par une autre solution de surveillance. La vigie applicative peut ne pas prendre en charge la coexistence avec d’autres solutions d’instrumentation.
+ Vérifiez que votre application répond aux exigences de compatibilité pour utiliser Application Signals. Pour de plus amples informations, veuillez consulter [Systèmes pris en charge](CloudWatch-Application-Signals-supportmatrix.md).
+ Si votre application ne parvient pas à extraire les artefacts Application Signals tels que l'agent et CloudWatch les images de l'agent AWS Distro for OpenTelemetery Java ou Python, cela peut être dû à un problème de réseau.
Pour atténuer le problème, supprimez l’annotation `instrumentation.opentelemetry.io/inject-java: "true"` ou `instrumentation.opentelemetry.io/inject-python: "true"` du manifeste de déploiement de votre application et redéployez votre application. Vérifiez ensuite si l’application fonctionne.
**Problèmes connus**
La collecte de métriques d'exécution dans la version v1.32.5 du SDK Java est connue pour ne pas fonctionner avec les applications utilisant Wildfly. JBoss Ce problème s'étend au module complémentaire Amazon CloudWatch Observability EKS, affectant les `2.3.0-eksbuild.1` versions `2.5.0-eksbuild.1` suivantes.
Si vous êtes concerné, rétrogradez la version ou désactivez la collecte des métriques d’exécution en ajoutant la variable d’environnement `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` à votre application.
## L’application Python ne démarre pas après l’activation de la vigie applicative
Il s'agit d'un problème connu en OpenTelemetry matière d'instrumentation automatique : une variable d'`PYTHONPATH`environnement manquante peut parfois empêcher le démarrage de l'application. Pour résoudre ce problème, veillez à définir la variable d’environnement `PYTHONPATH` sur le répertoire de travail de votre application. Pour plus d’informations sur ce problème, consultez [Le paramètre d’instrumentation automatique Python de PYTHONPATH n’est pas compatible avec le comportement de résolution des modules Python, ce qui perturbe les applications Django](https://github.com/open-telemetry/opentelemetry-operator/issues/2302).
Pour les applications Django, des configurations supplémentaires sont requises, qui sont décrites dans la [documentation OpenTelemetry Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html).
+ Utilisez le paramètre `--noreload` pour empêcher le rechargement automatique.
+ Définissez la variable d’environnement `DJANGO_SETTINGS_MODULE` sur l’emplacement du fichier `settings.py` de votre application Django. Cela garantit que OpenTelemetry vous pouvez accéder et intégrer correctement vos paramètres Django.
## Aucune donnée de la vigie applicative pour les applications Python qui utilisent un serveur WSGI
Si vous utilisez un serveur WSGI tel que Gunicorn ou uWSGI, vous devez effectuer des modifications supplémentaires pour que l’auto-instrumentation ADOT Python fonctionne.
**Note**
Assurez-vous d'utiliser la dernière version d'ADOT Python et le module complémentaire Amazon CloudWatch Observability EKS avant de continuer.
**Étapes supplémentaires pour activer la vigie applicative avec un serveur WSGI**
1. Importez l’instrumentation automatique dans les processus de travail bifurqués.
Pour Gunicorn, utilisez le hook `post_fork` :
```
# gunicorn.conf.py
def post_fork(server, worker):
from opentelemetry.instrumentation.auto_instrumentation import sitecustomize
```
Pour uWSGI, utilisez la directive `import`.
```
# uwsgi.ini
[uwsgi]
; required for the instrumentation of worker processes
enable-threads = true
lazy-apps = true
import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize
```
1. Activez la configuration de l’instrumentation automatique ADOT Python pour ignorer le processus principal et le transférer aux processus de travail en définissant la variable d’environnement `OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED` sur `true`.
## Mon application Node.js n’est pas instrumentée ou ne génère pas de télémétrie de la vigie applicative
Pour activer la vigie applicative pour Node.js, vous devez vous assurer que votre application Node.js utilise le format de module CommonJS (CJS). La AWS distribution pour OpenTelemetry Node.js ne prend pas en charge le format du module ESM, car OpenTelemetry JavaScript le support d'ESM est expérimental et est en cours de développement.
Pour déterminer si votre application utilise CJS et non ESM, assurez-vous que votre application ne remplit pas les [conditions pour activer](https://nodejs.org/api/esm.html#enabling) ESM.
## Mon application .NET n'est pas instrumentée ou s'arrête à cause des appels du AWS SDK
Le SDK ADOT ( AWS Distro for Open Telemetry) pour .NET ne prend pas en charge le SDK pour .NET V4. AWS Utilisez le AWS SDK .NET V3 pour une prise en charge complète des signaux d'application.
## Aucune donnée d’application dans le tableau de bord de la vigie applicative
Si des métriques ou des suivis sont absents des tableaux de bord d’Application Signals, cela peut être dû aux causes suivantes. N’étudiez ces causes que si vous avez attendu 15 minutes pour qu’Application Signals collecte et affiche les données depuis votre dernière mise à jour.
+ Assurez-vous que la bibliothèque et le framework que vous utilisez sont pris en charge par l’agent Java ADOT. Pour plus d’informations, veuillez consulter la rubrique [Bibliothèques/Frameworks](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks).
+ Assurez-vous que l' CloudWatch agent est en cours d'exécution. Vérifiez d'abord l'état des modules d' CloudWatch agents et assurez-vous qu'ils le `Running` sont tous.
```
kubectl -n amazon-cloudwatch get pods.
```
Ajoutez ce qui suit au fichier de configuration de l' CloudWatch agent pour activer les journaux de débogage, puis redémarrez l'agent.
```
"agent": {
"region": "${REGION}",
"debug": true
},
```
Vérifiez ensuite l'absence d'erreurs dans les modules CloudWatch d'agent.
+ Vérifiez l'absence de problèmes de configuration avec l' CloudWatch agent. Vérifiez que les informations suivantes se trouvent toujours dans le CloudWatch fichier de configuration de l'agent et que l'agent a été redémarré depuis son ajout.
```
"agent": {
"region": "${REGION}",
"debug": true
},
```
Vérifiez ensuite les journaux de OpenTelemetry débogage pour détecter les messages d'erreur tels que`ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ...`. Ces messages peuvent indiquer le problème.
Si cela ne résout pas le problème, videz et vérifiez les variables d’environnement dont le nom commence par `OTEL_` en décrivant le pod à l’aide de la commande `kubectl describe pod`.
+ Pour activer la journalisation du débogage en OpenTelemetry Python, définissez la variable d'environnement `OTEL_PYTHON_LOG_LEVEL` sur `debug` et redéployez l'application.
+ Vérifiez que les autorisations d'exportation des données depuis l' CloudWatchagent ne sont pas correctes ou insuffisantes. Si vous voyez `Access Denied` des messages dans les journaux des CloudWatch agents, cela peut être à l'origine du problème. Il est possible que les autorisations appliquées lors de l'installation de l' CloudWatch agent aient été modifiées ou révoquées ultérieurement.
+ Vérifiez l'absence d'un problème de AWS distribution pour OpenTelemetry (ADOT) lors de la génération de données de télémétrie.
Assurez-vous que les annotations d’instrumentation `instrumentation.opentelemetry.io/inject-java` et ` sidecar.opentelemetry.io/inject-java` sont appliquées au déploiement de l’application et que la valeur est `true`. Sans celles-ci, les pods d’application ne seront pas instrumentés même si le module complémentaire ADOT est correctement installé.
Ensuite, vérifiez si le conteneur `init` est appliqué sur l’application et si son état `Ready` est `True`. Si le conteneur `init` n’est pas prêt, veuillez consulter l’état pour en connaître la raison.
Si le problème persiste, activez la journalisation du débogage sur le SDK OpenTelemetry Java en définissant la variable d'environnement sur true et `OTEL_JAVAAGENT_DEBUG` en redéployant l'application. Recherchez ensuite les messages commençant par `ERROR io.telemetry`.
+ L' metric/span exportateur est peut-être en train de supprimer des données. Pour le savoir, consultez le journal des applications pour voir s’il contient des messages incluant `Failed to export...`.
+ L' CloudWatch agent est peut-être limité lorsqu'il envoie des métriques ou des spans à Application Signals. Vérifiez les messages indiquant une limitation dans les journaux de l' CloudWatch agent.
+ Veuillez vous assurer que vous avez activé la configuration de la découverte de services. Vous ne devez effectuer cette opération qu’une seule fois dans votre région.
Pour confirmer cela, dans la CloudWatch console, choisissez **Application Signals**, **Services**. Si l’étape 1 n’est pas marquée comme **Terminée**, sélectionnez **Commencer à découvrir vos services**. Les données devraient commencer à affluer dans les cinq minutes.
## Les métriques de service ou de dépendance ont des valeurs inconnues
Si vous voyez **UnknownService**, **UnknownOperation**UnknownRemoteService****, ou **UnknownRemoteOperation**pour un nom de dépendance ou une opération dans les tableaux de bord des signaux d'application, vérifiez si l'occurrence de points de données pour le service distant inconnu et le fonctionnement à distance inconnu coïncident avec leurs déploiements.
+ **UnknownService**signifie que le nom d'une application instrumentée est inconnu. Si la variable d’environnement `OTEL_SERVICE_NAME` n’est pas définie et que `service.name` n’est pas spécifié dans `OTEL_RESOURCE_ATTRIBUTES`, le nom du service est défini sur `UnknownService`. Pour résoudre ce problème, veuillez spécifier le nom du service dans `OTEL_SERVICE_NAME` ou `OTEL_RESOURCE_ATTRIBUTES`.
+ **UnknownOperation**signifie que le nom d'une opération invoquée est inconnu. Cela se produit lorsque la vigie applicative ne parvient pas à découvrir un nom d’opération qui invoque l’appel distant ou lorsque le nom d’opération extrait contient des valeurs de cardinalité élevées.
+ **UnknownRemoteService**signifie que le nom du service de destination est inconnu. Cela se produit lorsque le système ne parvient pas à extraire le nom du service de destination auquel l’appel distant accède.
Une solution consiste à créer une portée personnalisée autour de la fonction qui envoie une requête et à ajouter l’attribut `aws.remote.service` avec la valeur désignée. Une autre option consiste à configurer l' CloudWatch agent pour personnaliser la valeur métrique de`RemoteService`. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultez[Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md).
+ **UnknownRemoteOperation**signifie que le nom de l'opération de destination est inconnu. Cela se produit lorsque le système est incapable d’extraire le nom de l’opération de destination à laquelle l’appel distant accède.
Une solution consiste à créer une portée personnalisée autour de la fonction qui envoie une requête et à ajouter l’attribut `aws.remote.operation` avec la valeur désignée. Une autre option consiste à configurer l' CloudWatch agent pour personnaliser la valeur métrique de`RemoteOperation`. Pour plus d'informations sur les personnalisations de l' CloudWatch agent, consultez[Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md).
## Gestion d'un ConfigurationConflict lors de la gestion du module complémentaire Amazon CloudWatch Observability EKS
Lorsque vous installez ou mettez à jour le module complémentaire Amazon CloudWatch Observability EKS, si vous remarquez une défaillance causée par un type `Health Issue` `ConfigurationConflict` de fichier dont la description commence par`Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`, c'est probablement parce que vous avez déjà ClusterRoleBinding installé l' CloudWatch agent et ses composants associés tels que le ServiceAccount, le ClusterRole et le sur le cluster. Lorsque le module complémentaire tente d'installer l' CloudWatch agent et ses composants associés, s'il détecte une modification du contenu, il échoue par défaut à l'installation ou à la mise à jour pour éviter de modifier l'état des ressources du cluster.
Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez cet échec, nous vous recommandons de supprimer une configuration d' CloudWatch agent existante que vous aviez précédemment installée sur le cluster, puis d'installer le module complémentaire EKS. Veillez à sauvegarder toutes les personnalisations que vous avez éventuellement apportées à la configuration d'origine de l' CloudWatch agent, telle qu'une configuration d'agent personnalisée, et à les fournir au module complémentaire Amazon CloudWatch Observability EKS lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l' CloudWatch agent pour l'intégration à Container Insights, consultez [Suppression de l' CloudWatch agent et de Fluent Bit for Container Insights](ContainerInsights-delete-agent.md) pour plus d'informations.
Le module complémentaire prend également en charge une option de configuration de résolution des conflits capable de spécifier `OVERWRITE`. Vous pouvez utiliser cette option pour procéder à l’installation ou à la mise à jour du module complémentaire en remplaçant les conflits sur le cluster. Si vous utilisez la console Amazon EKS, vous trouverez la **Méthode de résolution des conflits** lorsque vous choisissez les **Paramètres de configuration facultatifs** lorsque vous créez ou mettez à jour le module complémentaire. Si vous utilisez le AWS CLI, vous pouvez fournir le `--resolve-conflicts OVERWRITE` à votre commande pour créer ou mettre à jour le module complémentaire.
## Je veux filtrer les métriques et les traces inutiles
Si Application Signals collecte des traces et des mesures que vous ne souhaitez pas utiliser, consultez [Gestion des opérations à cardinalité élevée](Application-Signals-Cardinality.md) pour plus d'informations sur la configuration de l' CloudWatch agent avec des règles personnalisées afin de réduire la cardinalité.
Pour plus d’informations sur la personnalisation des règles d’échantillonnage des traces, consultez [Configurer les règles d’échantillonnage](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray-interface-console.html#xray-console) dans la documentation X-Ray.
## Que signifie `InternalOperation` ?
Un `InternalOperation` est une opération déclenchée en interne par l’application plutôt que par une invocation externe. L’apparition de `InternalOperation` est un comportement normal et attendu.
Voici quelques exemples typiques où vous pourriez voir `InternalOperation` :
+ **Préchargement au démarrage** : votre application effectue une opération nommée `loadDatafromDB` qui lit les métadonnées d’une base de données pendant la phase de préparation. Au lieu d’observer `loadDatafromDB` comme une opération de service, vous le verrez classé comme `InternalOperation`.
+ **Exécution asynchrone en arrière-plan** : votre application s’abonne à une file d’attente d’événements et traite les données en continu en conséquence chaque fois qu’il y a une mise à jour. Chaque opération déclenchée sera classée sous `InternalOperation` en tant qu’opération de service.
+ **Récupération des informations d’hôte à partir d’un registre de services** : votre application communique avec un registre de services pour la découverte de services. Toutes les interactions avec le système de découverte sont classées comme `InternalOperation`.
## Comment activer la journalisation pour les applications .NET ?
Pour activer la journalisation pour les applications .NET, veuillez configurer les variables d’environnement suivantes. Pour plus d'informations sur la configuration de ces variables d'environnement, consultez la section [Résolution des problèmes d'instrumentation automatique .NET](https://opentelemetry.io/docs/zero-code/net/troubleshooting/#general-steps) dans la OpenTelemetry documentation.
+ `OTEL_LOG_LEVEL`
+ `OTEL_DOTNET_AUTO_LOG_DIRECTORY`
+ `COREHOST_TRACE`
+ `COREHOST_TRACEFILE`
## Comment résoudre les conflits de version d’assembly dans les applications .NET ?
Si l'erreur suivante s'affiche, consultez la section [Conflits de versions d'assemblage](https://opentelemetry.io/docs/zero-code/net/troubleshooting/#assembly-version-conflicts) dans la OpenTelemetry documentation pour connaître les étapes de résolution.
```
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults)
at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
at Program.$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26
```
## Puis-je le désactiver FluentBit ?
Vous pouvez le désactiver FluentBit en configurant le module complémentaire Amazon CloudWatch Observability EKS. Pour de plus amples informations, veuillez consulter [(Facultatif) Configuration supplémentaire](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration).
## Puis-je filtrer les journaux des conteneurs avant de les exporter vers CloudWatch Logs ?
Non, le filtrage des journaux des conteneurs n’est pas encore pris en charge.
## Résolution TypeError lors de l'utilisation de AWS Distro pour la couche Lambda OpenTelemetry JavaScript (ADOT)
Votre fonction Lambda peut échouer avec cette erreur : `TypeError - "Cannot redefine property: handler"` lorsque vous :
+ Utiliser la couche JavaScript Lambda ADOT
+ `esbuild`À utiliser pour compiler TypeScript
+ Exportez votre gestionnaire avec le mot-clé `export`
La couche JavaScript Lambda ADOT doit modifier votre gestionnaire lors de l'exécution. Lorsque vous utilisez le `export` mot clé with `esbuild` (directement ou via AWS CDK), `esbuild` cela rend votre gestionnaire immuable, empêchant ainsi ces modifications.
Exportez votre fonction de gestionnaire en utilisant `module.exports` au lieu du mot-clé `export` :
```
// Before
export const handler = (event) => {
// Handler Code
}
```
```
// After
const handler = async (event) => {
// Handler Code
}
module.exports = { handler }
```
## TypeError lors de l'utilisation de gestionnaires Lambda Response Streaming avec AWS Distro for ( OpenTelemetry ADOT) Lambda Layer JavaScript
Votre fonction Lambda peut échouer avec cette erreur : `TypeError - "responseStream.write is not a function"` lorsque vous :
+ Utiliser la couche JavaScript Lambda ADOT avec l'instrumentation AWS Lambda activée (activée par défaut)
+ Utilisation de la fonctionnalité de diffusion des réponses dans les environnements d'exécution gérés par Node.js. Par exemple, lorsque votre gestionnaire de fonctions est comme :
```
* export const handler = awslambda.streamifyResponse(...)
```
L'instrumentation AWS Lambda de la couche JavaScript Lambda ADOT ne prend actuellement pas en charge le streaming de réponses dans les environnements d'exécution gérés par Node.js. Elle doit donc être désactivée pour éviter cela. TypeError
## Mettez à jour les versions requises des agents ou du module complémentaire Amazon EKS
Après le 9 août 2024, CloudWatch Application Signals ne prendra plus en charge les anciennes versions du module complémentaire Amazon CloudWatch Observability EKS, de l'agent et de l' CloudWatch agent AWS Distro for OpenTelemetry Auto-Instrumentation.
+ Pour le module complémentaire Amazon CloudWatch Observability EKS, les versions antérieures `v1.7.0-eksbuild.1` ne seront pas prises en charge.
+ Pour l' CloudWatch agent, les versions antérieures `1.300040.0` ne seront pas prises en charge.
+ Pour l'agent AWS d' OpenTelemetry auto-instrumentation Distro for :
+ Pour Java, les versions antérieures à `1.32.2` ne seront pas prises en charge.
+ Pour Python, les versions antérieures à `0.2.0` ne seront pas prises en charge.
+ Pour .NET, les versions antérieures à `1.3.2` ne seront pas prises en charge.
+ Pour Node.js, les versions antérieures à `0.3.0` ne seront pas prises en charge.
**Important**
Les dernières versions des agents incluent des mises à jour du schéma de métriques de la vigie applicative. Ces mises à jour ne sont pas rétrocompatibles, ce qui peut entraîner des problèmes de données si des versions incompatibles sont utilisées. Afin de garantir une transition en douceur vers la nouvelle fonctionnalité, veuillez suivre les étapes suivantes :
Si votre application s'exécute sur Amazon EKS, veillez à redémarrer toutes les applications instrumentées après avoir mis à jour le module complémentaire Amazon CloudWatch Observability.
**Pour les applications exécutées sur d'autres plateformes, veillez à mettre à niveau l' CloudWatch agent et l'agent d' AWS OpenTelemetry instrumentation automatique vers les dernières versions.**
Les instructions fournies dans les sections suivantes peuvent vous aider à effectuer la mise à jour vers une version prise en charge.
**Contents**
+ [Mettre à jour le module complémentaire Amazon CloudWatch Observability EKS](#Application-Signals-Upgrade-Addon)
+ [Utilisation de la console](#Upgrade-Addon-Console)
+ [Utilisez le AWS CLI](#Upgrade-Addon-CLI)
+ [Mettre à jour l' CloudWatch agent et l'agent ADOT](#Application-Signals-Upgrade-Agents)
+ [Mettre à jour sur Amazon ECS](#Upgrade-Agents-ECS)
+ [Mettre à jour sur Amazon EC2 ou d’autres architectures](#Upgrade-Addon-EC2)
### Mettre à jour le module complémentaire Amazon CloudWatch Observability EKS
Pour le module complémentaire Amazon CloudWatch Observability EKS, vous pouvez utiliser le AWS Management Console ou le AWS CLI.
#### Utilisation de la console
**Pour mettre à niveau le module complémentaire à l’aide de la console**
1. Ouvrez la console Amazon EKS à l'adresse [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Sélectionnez le nom du cluster Amazon EKS à mettre à jour.
1. Choisissez l'onglet **Modules complémentaires**, puis **Amazon CloudWatch Observability**.
1. Sélectionnez **Modifier**, choisissez la version vers laquelle vous voulez effectuer la mise à niveau, puis sélectionnez **Enregistrer les modifications**.
Veuillez vous assurer de sélectionner `v1.7.0-eksbuild.1` ou une version ultérieure.
1. Entrez l'une des AWS CLI commandes suivantes pour redémarrer vos services.
```
# Restart a deployment
kubectl rollout restart deployment/name
# Restart a daemonset
kubectl rollout restart daemonset/name
# Restart a statefulset
kubectl rollout restart statefulset/name
```
#### Utilisez le AWS CLI
**Pour mettre à niveau le module complémentaire à l'aide du AWS CLI**
1. Entrez la commande suivante pour trouver la dernière version.
```
aws eks describe-addon-versions \
--addon-name amazon-cloudwatch-observability
```
1. Entrez la commande suivante pour mettre à jour le module complémentaire. *\$1VERSION*Remplacez-le par une version antérieure `v1.7.0-eksbuild.1` ou ultérieure. Remplacez *\$1AWS\$1REGION* et *\$1CLUSTER* par le nom de votre région et de votre cluster.
```
aws eks update-addon \
--region $AWS_REGION \
--cluster-name $CLUSTER \
--addon-name amazon-cloudwatch-observability \
--addon-version $VERSION \
# required only if the advanced configuration is used.
--configuration-values $JSON_CONFIG
```
**Note**
Si vous utilisez une configuration personnalisée pour le module complémentaire, vous trouverez un exemple de configuration à utiliser *\$1JSON\$1CONFIG* dans[Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md).
1. Entrez l'une des AWS CLI commandes suivantes pour redémarrer vos services.
```
# Restart a deployment
kubectl rollout restart deployment/name
# Restart a daemonset
kubectl rollout restart daemonset/name
# Restart a statefulset
kubectl rollout restart statefulset/name
```
### Mettre à jour l' CloudWatch agent et l'agent ADOT
Si vos services s'exécutent sur des architectures autres qu'Amazon EKS, vous devrez mettre à niveau l' CloudWatch agent et l'agent d'auto-instrumentation ADOT pour utiliser les dernières fonctionnalités d'Application Signals.
#### Mettre à jour sur Amazon ECS
**Pour mettre à niveau vos agents pour les services fonctionnant sur Amazon ECS**
1. Créez une nouvelle révision de définition de tâche. Pour plus d’informations, consultez [Mettre à jour une définition de tâche à l’aide de la console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2).
1. Remplacez le `$IMAGE` du conteneur `ecs-cwagent` par la dernière balise d’image de [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) sur Amazon ECR.
Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `1.300040.0`.
1. Remplacez le `$IMAGE` du conteneur `init` par la dernière balise d’image provenant des emplacements suivants :
+ Pour Java, utilisez [adot-autoinstrumentation-javaaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java).
Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `1.32.2`.
+ Pour Python, utilisez [adot-autoinstrumentation-pythonaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-python).
Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `0.2.0`.
+ Pour .NET, utilisez [adot-autoinstrumentation-dotnetaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-dotnet).
Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `1.3.2`.
+ Pour Node.js, utilisez [adot-autoinstrumentation-nodeaws-observability/](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-node).
Si vous effectuez une mise à niveau vers une version fixe, veillez à utiliser une version égale ou supérieure à `0.3.0`.
1. Mettez à jour les variables d’environnement de la vigie applicative dans votre conteneur d’application en suivant les instructions fournies dans [Étape 4 : Instrumenter votre application avec l' CloudWatch agent](CloudWatch-Application-Signals-ECS-Sidecar.md#CloudWatch-Application-Signals-Enable-ECS-Instrument).
1. Déployez votre service avec la nouvelle définition de tâche.
#### Mettre à jour sur Amazon EC2 ou d’autres architectures
**Pour mettre à niveau vos agents pour les services s’exécutant sur Amazon EC2 ou d’autres architectures**
1. Assurez-vous de sélectionner la version `1.300040.0` ou une version ultérieure de la version de l' CloudWatch agent.
1. Téléchargez la dernière version de l'agent AWS Distro for OpenTelemetry Auto-Instrumentation depuis l'un des emplacements suivants :
+ Pour Java, utilisez [aws-otel-java-instrumentation ](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java).
Si vous mettez à niveau vers une version fixe, veillez à choisir `1.32.2` ou une version ultérieure.
+ Pour Python, utilisez [aws-otel-python-instrumentation ](https://github.com/aws-observability/aws-otel-python-instrumentation/releases).
Si vous mettez à niveau vers une version fixe, veillez à choisir `0.2.0` ou une version ultérieure.
+ Pour .NET, utilisez [aws-otel-dotnet-instrumentation](https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases).
Si vous mettez à niveau vers une version fixe, veillez à choisir `1.3.2` ou une version ultérieure.
+ Pour Node.js, utilisez [aws-otel-js-instrumentation](https://github.com/aws-observability/aws-otel-js-instrumentation/releases).
Si vous mettez à niveau vers une version fixe, veillez à choisir `0.3.0` ou une version ultérieure.
1. Appliquez les variables d’environnement de la vigie applicative mises à jour à votre application, puis démarrez votre application. Pour de plus amples informations, veuillez consulter [Étape 3 : instrumenter votre application et la démarrer](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument).
## Format de métrique intégré (EMF) désactivé pour la vigie applicative
La désactivation de l’EMF pour le groupe de journaux `/aws/application-signals/data` peut avoir les conséquences suivantes sur les fonctionnalités de la vigie applicative.
+ Les métriques et les graphiques de la vigie applicative ne s’afficheront pas
+ Les fonctionnalités de la vigie applicative seront dégradées
**Comment restaurer la vigie applicative ?**
Lorsque la vigie applicative affiche des graphiques ou des métriques vides, vous devez activer EMF pour le groupe de journaux `/aws/application-signals/data` afin de restaurer toutes les fonctionnalités. Pour de plus amples informations, veuillez consulter [PutAccountPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutAccountPolicy.html#API_PutAccountPolicy_RequestSyntax).
# (Facultatif) Configuration de la vigie applicative
Cette section contient des informations sur la configuration de CloudWatch Application Signals.
**Topics**
+ [Taux d’échantillonnage du suivi](Application-Signals-SampleRate.md)
+ [Activation de la corrélation entre suivis et journaux](Application-Signals-TraceLogCorrelation.md)
+ [Activation de la corrélation entre métriques et journaux](Application-Signals-MetricLogCorrelation.md)
+ [Gestion des opérations à cardinalité élevée](Application-Signals-Cardinality.md)
# Taux d’échantillonnage du suivi
Par défaut, lorsque vous activez Application Signals, l’échantillonnage centralisé X-Ray est activé en utilisant les paramètres de fréquence d’échantillonnage par défaut de `reservoir=1/s` et `fixed_rate=5%`. Les variables d’environnement de l’agent SDK AWS Distro for OpenTelemetry (ADOT) sont définies comme suit.
| Variable d'environnement | Valeur | Remarque |
| --- | --- | --- |
| `OTEL_TRACES_SAMPLER` | `xray` | |
| `OTEL_TRACES_SAMPLER_ARG` | `endpoint=http://cloudwatch-agent.amazon-cloudwatch:2000` | Point de terminaison de l’agent CloudWatch |
Pour plus d’informations sur la configuration d’échantillonnage, veuillez consulter les ressources suivantes :
+ Pour modifier l’échantillonnage X-Ray, consultez [Configuration des règles d’échantillonnage](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray-interface-console.html#xray-console)
+ Pour modifier l’échantillonnage ADOT, veuillez consulter la rubrique [Configuring the OpenTelemetry Collector for X-Ray remote sampling](https://aws-otel.github.io/docs/getting-started/remote-sampling).
Si vous souhaitez désactiver l’échantillonnage centralisé X-Ray et utiliser l’échantillonnage local à la place, définissez les valeurs suivantes pour l’agent Java du SDK ADOT comme indiqué ci-dessous. L’exemple suivant définit le taux d’échantillonnage à 5 %.
| Variable d'environnement | Valeur |
| --- | --- |
| `OTEL_TRACES_SAMPLER` | `parentbased_traceidratio` |
| `OTEL_TRACES_SAMPLER_ARG` | `0.05` |
Pour plus d’informations sur les paramètres d’échantillonnage plus avancés, veuillez consulter [OTEL\$1TRACES\$1SAMPLER](https://opentelemetry.io/docs/concepts/sdk-configuration/general-sdk-configuration/#otel_traces_sampler).
# Activation de la corrélation entre suivis et journaux
Vous pouvez activer la *corrélation entre suivis et journaux* dans la vigie applicative. Cette fonctionnalité insère automatiquement les identifiants de suivi et d’intervalle dans les journaux concernés de l’application. Ainsi, lorsque vous ouvrez la page de détails d’un suivi dans la console de la vigie applicative, les entrées de journaux associées (le cas échéant) s’affichent automatiquement avec le suivi en cours au bas de la page.
Par exemple, supposons que vous remarquiez un pic de latence dans un graphique de latence. Vous pouvez sélectionner le point correspondant sur le graphique pour charger les informations de diagnostic associées à ce moment précis. Vous sélectionnez ensuite le suivi correspondant pour obtenir plus d’informations. Lorsque vous consultez les informations de suivi, vous pouvez faire défiler l’écran vers le bas pour voir les journaux associés au suivi. Ces journaux peuvent révéler des motifs récurrents ou des codes d’erreur associés aux problèmes ayant provoqué le pic de latence.
Pour établir la corrélation entre les suivis et les journaux, la vigie applicative s’appuie sur :
+ [Instrumentation automatique Logger MDC](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/logger-mdc-instrumentation.md) pour Java.
+ [Instrumentation de journalisation OpenTelemetry](https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/logging/logging.html) pour Python.
+ Les instrumentations automatiques [Pino](https://www.npmjs.com/package/@opentelemetry/instrumentation-pino), [Winston](https://www.npmjs.com/package/@opentelemetry/instrumentation-winston) ou [Bunyan](https://www.npmjs.com/package/@opentelemetry/instrumentation-bunyan) pour Node.js.
Toutes ces instrumentations sont fournies par la communauté OpenTelemetry. La vigie applicative les utilise pour injecter les contextes de suivi, comme l’identifiant de suivi et l’identifiant d’intervalle, dans les journaux de l’application. Pour activer cette fonctionnalité, vous devez modifier manuellement la configuration de journalisation afin d’activer l’instrumentation automatique.
Selon l’architecture sur laquelle votre application s’exécute, il peut aussi être nécessaire de définir une variable d’environnement pour activer la corrélation entre suivis et journaux, en plus de suivre les étapes décrites dans cette section.
+ Sur Amazon EKS, aucune autre étape n’est nécessaire.
+ Sur Amazon ECS, aucune autre étape n’est nécessaire.
+ Sur Amazon EC2, reportez-vous à l’étape 4 de la procédure décrite dans [Étape 3 : instrumenter votre application et la démarrer](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument).
Après avoir activé la corrélation entre suivis et journaux,
## Exemples de configuration de la corrélation entre suivis et journaux
Cette section présente des exemples de configuration de la corrélation entre suivis et journaux dans différents environnements.
**Spring Boot pour Java**
Supposons que vous disposiez d’une application Spring Boot dans un dossier appelé `custom-app`. La configuration de l’application est généralement un fichier YAML appelé `custom-app/src/main/resources/application.yml`, qui pourrait ressembler à ceci :
```
spring:
application:
name: custom-app
config:
import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
...
```
Pour activer la entre suivis et journaux, ajoutez la configuration de journalisation suivante.
```
spring:
application:
name: custom-app
config:
import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
...
logging:
pattern:
level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p
```
**Logback pour Java**
Dans la configuration de journalisation (par exemple logback.xml), insérez le contexte de suivi `trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p` dans le `pattern` de l’encodeur. Par exemple, la configuration suivante ajoute le contexte de suivi avant le message du journal.
```
app.log
true
trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n
```
Pour plus d’informations sur les encodeurs dans Logback, consultez la section [Encodeurs](https://logback.qos.ch/manual/encoders.html) dans la documentation Logback.
**Log4j2 pour Java**
Dans la configuration de journalisation (par exemple log4j2.xml), insérez le contexte de suivi `trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p` dans `PatternLayout`. Par exemple, la configuration suivante ajoute le contexte de suivi avant le message du journal.
```
```
Pour plus d’informations sur la disposition des modèles dans Log4j2, consultez [Disposition des modèles](https://logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Layout) dans la documentation Log4j2.
**Log4j pour Java**
Dans la configuration de journalisation (par exemple log4j.xml), insérez le contexte de suivi `trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p` dans `PatternLayout`. Par exemple, la configuration suivante ajoute le contexte de suivi avant le message du journal.
```
;
;
;
;
;
;
;
```
Pour plus d’informations sur la disposition des modèles dans Log4j, consultez [Disposition des modèles](https://logging.apache.org/log4j/1.x/apidocs/org/apache/log4j/PatternLayout.html) dans la documentation Log4j.
**Python**
Définissez la variable d’environnement `OTEL_PYTHON_LOG_CORRELATION` sur `true` lors de l’exécution de votre application. Pour plus d’informations, consultez [Activation de l’injection de contexte de suivi](https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/logging/logging.html#enable-trace-context-injection) dans la documentation OpenTelemetry pour Python.
**Node.js**
Pour plus d’informations sur l’activation de l’injection de contexte de suivi dans Node.js pour les bibliothèques de journalisation compatibles, consultez la documentation NPM des instrumentations automatiques [Pino](https://www.npmjs.com/package/@opentelemetry/instrumentation-pino), [Winston](https://www.npmjs.com/package/@opentelemetry/instrumentation-winston) ou [Bunyan](https://www.npmjs.com/package/@opentelemetry/instrumentation-bunyan) pour Node.js.
# Activation de la corrélation entre métriques et journaux
Si vous publiez les journaux de votre application dans des groupes de journaux CloudWatch Logs, vous pouvez activer la *corrélation entre métriques et journaux d’application* dans la vigie applicative. Grâce à la corrélation entre métriques et journaux, la console de la vigie applicative affiche automatiquement les groupes de journaux associés à une métrique donnée.
Par exemple, supposons que vous remarquiez un pic de latence dans un graphique de latence. Vous pouvez sélectionner un point sur le graphique pour charger les informations de diagnostic associées à ce moment précis. Les informations de diagnostic indiquent les groupes de journaux d’application associés au service et à la métrique en cours. Vous pouvez ensuite choisir un bouton pour exécuter une requête CloudWatch Logs Insights sur ces groupes de journaux. Selon le contenu des journaux de votre application, cela peut vous aider à identifier la cause d’un pic de latence ou d’un autre problème de performance.
Selon l’architecture sur laquelle s’exécute votre application, il peut être nécessaire de définir une variable d’environnement pour activer la corrélation entre métriques et journaux d’application.
+ Sur Amazon EKS, aucune autre étape n’est nécessaire.
+ Sur Amazon ECS, aucune autre étape n’est nécessaire.
+ Sur Amazon EC2, reportez-vous à l’étape 4 de la procédure décrite dans [Étape 3 : instrumenter votre application et la démarrer](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument).
# Gestion des opérations à cardinalité élevée
La vigie applicative inclut des paramètres dans l’agent CloudWatch qui permettent de gérer la cardinalité des opérations et de contrôler l’exportation des métriques afin d’optimiser les coûts. Par défaut, la fonction de limitation des métriques s’active lorsque le nombre d’opérations distinctes pour un service au fil du temps dépasse le seuil par défaut de 500. Vous pouvez ajuster ce comportement en modifiant les paramètres de configuration.
## Vérification de l’activation de la limitation des métriques
Vous pouvez utiliser les méthodes suivantes pour déterminer si la limitation automatique des métriques est active. Si c’est le cas, il est recommandé d’optimiser le contrôle de la cardinalité en suivant les étapes décrites dans la section suivante.
+ Dans la console CloudWatch, sélectionnez **Vigie applicative**, **Services**. Si vous voyez une **Opération** nommée **AllOtherOperations** ou une **RemoteOperation** nommée **AllOtherRemoteOperations**, cela signifie que la limitation des métriques est active.
+ Si l’une des métriques collectées par la vigie applicative présente la valeur `AllOtherOperations` pour sa dimension `Operation`, cela indique également que la limitation des métriques est active.
+ Si l’une des métriques collectées par la vigie applicative présente la valeur `AllOtherRemoteOperations` pour sa dimension `RemoteOperation`, cela indique également que la limitation des métriques est active.
### Optimisation du contrôle de la cardinalité
Pour optimiser le contrôle de la cardinalité, vous pouvez :
+ Créer des règles personnalisées pour agréger les opérations.
+ Configurer votre politique de limitation des métriques.
#### Création de règles personnalisées pour agréger les opérations
Les opérations à cardinalité élevée peuvent parfois être causées par des valeurs uniques inappropriées extraites du contexte. Par exemple, l’envoi de requêtes HTTP/S contenant des identifiants d’utilisateur ou des identifiants de session dans le chemin peut générer des centaines d’opérations distinctes. Pour résoudre ce problème, il est recommandé de configurer l’agent CloudWatch avec des règles de personnalisation afin de réécrire ces opérations.
Dans les cas où un grand nombre de métriques distinctes sont générées par des appels `RemoteOperation` individuels tels que `PUT /api/customer/owners/123`, `PUT /api/customer/owners/456` ou d’autres requêtes similaires, il est conseillé de regrouper ces opérations en une seule `RemoteOperation`. Une approche consiste à standardiser tous les appels `RemoteOperation` qui commencent par `PUT /api/customer/owners/` dans un format uniforme, à savoir `PUT /api/customer/owners/{ownerId}`. L’exemple suivant illustre ce scénario. Pour plus d’informations sur d’autres règles de personnalisation, consultez [Activer les signaux CloudWatch d'application](CloudWatch-Agent-Application_Signals.md).
```
{
"logs":{
"metrics_collected":{
"application_signals":{
"rules":[
{
"selectors":[
{
"dimension":"RemoteOperation",
"match":"PUT /api/customer/owners/*"
}
],
"replacements":[
{
"target_dimension":"RemoteOperation",
"value":"PUT /api/customer/owners/{ownerId}"
}
],
"action":"replace"
}
]
}
}
}
}
```
Dans d’autres cas, les métriques à cardinalité élevée peuvent avoir été agrégées dans `AllOtherRemoteOperations`, ce qui rend difficile l’identification des métriques spécifiques incluses. L’agent CloudWatch peut journaliser les opérations ignorées. Pour identifier ces opérations ignorées, utilisez la configuration présentée dans l’exemple suivant pour activer la journalisation jusqu’à ce que le problème se reproduise. Examinez ensuite les journaux de l’agent CloudWatch (accessibles par le conteneur `stdout` ou les fichiers journaux EC2) et recherchez le mot-clé `drop metric data`.
```
{
"agent": {
"config": {
"agent": {
"debug": true
},
"traces": {
"traces_collected": {
"application_signals": {
}
}
},
"logs": {
"metrics_collected": {
"application_signals": {
"limiter": {
"log_dropped_metrics": true
}
}
}
}
}
}
}
```
#### Création d’une politique de limitation des métriques
Si la configuration par défaut de la limitation des métriques ne répond pas aux besoins de votre service, vous pouvez personnaliser la configuration du limiteur de métriques. Pour ce faire, ajoutez une section `limiter` sous la section `logs/metrics_collected/application_signals` dans le fichier de configuration de l’agent CloudWatch.
L’exemple suivant montre comment réduire le seuil de limitation des métriques de 500 métriques distinctes à 100.
```
{
"logs": {
"metrics_collected": {
"application_signals": {
"limiter": {
"drop_threshold": 100
}
}
}
}
}
```
# 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/).
# Métriques collectées par la vigie applicative
La vigie applicative collecte à la fois les [métriques d’application standard](#AppSignals-StandardMetrics) et les [métriques d’exécution](#AppSignals-StandardMetrics) des applications pour lesquelles vous l’activez.
Les métriques d’application standard concernent les aspects les plus critiques des performances, de la latence et de la disponibilité des services.
Les métriques d’exécution suivent les métriques d’application au fil du temps, notamment l’utilisation de la mémoire, l’utilisation du processeur et la récupération de mémoire. La vigie applicative affiche les métriques d’exécution dans le contexte des services pour lesquels vous avez activé la vigie applicative. En cas de problème opérationnel, l’observation des métriques d’exécution peut être utile pour vous aider à trouver une cause racine du problème. Par exemple, vous pouvez voir si les pics de latence de votre service sont liés à des pics dans une métrique d’exécution.
**Topics**
+ [Métriques d’application standard collectées](#AppSignals-StandardMetrics)
+ [Métriques d’exécution](#AppSignals-RuntimeMetrics)
+ [Désactivation de la collecte des métriques d’exécution](#AppSignals-RuntimeMetrics-Disable)
## Métriques d’application standard collectées
Application Signals collecte des *métriques d’application standard* à partir des services qu’il découvre. Ces indicateurs concernent les aspects les plus critiques des performances d’un service : latence, défaillances et erreurs. Ils peuvent vous aider à identifier les problèmes, à surveiller les tendances en matière de performances et à optimiser les ressources afin d’améliorer l’expérience utilisateur globale.
Le tableau suivant répertorie les métriques collectées par Application Signals. Ces métriques sont envoyées CloudWatch dans l'espace de `ApplicationSignals` noms.
| Métrique | Description |
| --- | --- |
| `Latency` | Le délai avant le début du transfert de données ne commence qu’une fois la demande effectuée. Unités : millisecondes |
| `Fault` | Nombre d'erreurs HTTP 5XX côté serveur et d'erreurs d'état du OpenTelemetry span. Unités : aucune |
| `Error` | Nombre d’erreurs HTTP 4XX côté client. Ces erreurs sont considérées comme des erreurs de requête qui ne sont pas dues à des problèmes de service. Par conséquent, la métrique `Availability` affichée sur les tableaux de bord d’Application Signals ne considère pas ces erreurs comme des défauts de service. Unités : aucune |
La métrique `Availability` affichée sur les tableaux de bord de la vigie applicative est calculée comme suit : **(1 - `Faults`/Total)\$1100**. Le nombre total de réponses comprend toutes les réponses et est dérivé de `SampleCount(Latency)`. Les réponses réussies sont toutes les réponses sans erreur `5XX`. Les réponses `4XX` sont considérées comme réussies lorsqu’Application Signals évalue `Availability`.
### Dimensions collectées et combinaisons de dimensions
Les dimensions suivantes sont définies pour chacune des métriques d’application standard. Pour plus d’informations sur les dimensions, veuillez consulter la rubrique [Dimensions](cloudwatch_concepts.md#Dimension).
Différentes dimensions sont collectées pour les *métriques de service* et les *métriques de dépendance*. Dans les services découverts par Application Signals, lorsque le microservice A appelle le microservice B, le microservice B répond à la requête. Dans ce cas, le microservice A émet des métriques de dépendance et le microservice B émet des métriques de service. Lorsqu’un client appelle le microservice A, le microservice A répond à la requête et émet des métriques de service.
**Dimension pour les métriques de service**
Les dimensions suivantes sont collectées pour les métriques de service.
| Dimension | Description |
| --- | --- |
| `Service` | Le nom du service . La valeur maximale est 255 caractères. |
| `Operation` | Nom de l’opération API ou d’une autre activité. La valeur maximale est de 1 024 caractères. Vous ne pouvez définir des objectifs de niveau de service sur les opérations que si le nom de l’opération comporte 194 caractères ou moins. |
| `Environment` | Le nom de l’environnement dans lequel les services sont exécutés. Si les services ne sont pas exécutés sur Amazon EKS, vous pouvez spécifier une valeur personnalisée facultative pour `deployment.environment` dans le paramètre `OTEL_ATTRIBUTE_RESOURCES`. La valeur maximale est de 259 caractères. |
Lorsque vous consultez ces mesures dans la CloudWatch console, vous pouvez les afficher à l'aide des combinaisons de dimensions suivantes :
+ `[Environment, Service, Operation, [Latency, Error, Fault]]`
+ `[Environment, Service, [Latency, Error, Fault]]`
**Dimensions pour les métriques de dépendance**
Les dimensions suivantes sont collectées pour les métriques de dépendance :
| Dimension | Description |
| --- | --- |
| `Service` | Le nom du service . La valeur maximale est 255 caractères. |
| `Operation` | Le nom de l’opération API ou d’une autre opération. La valeur maximale est de 1024 caractères. |
| `RemoteService` | Le nom du service distant invoqué. La valeur maximale est 255 caractères. |
| `RemoteOperation` | Le nom de l’opération API invoquée. La valeur maximale est de 1024 caractères. |
| `Environment` | Le nom de l’environnement dans lequel les services sont exécutés. Si les services ne sont pas exécutés sur Amazon EKS, vous pouvez spécifier une valeur personnalisée facultative pour `deployment.environment` dans le paramètre `OTEL_ATTRIBUTE_RESOURCES`. La valeur maximale est de 259 caractères. |
| `RemoteEnvironment` | Le nom de l’environnement dans lequel les services de dépendance sont exécutés. Le paramètre `RemoteEnvironment` est généré automatiquement lorsqu’un service appelle une dépendance et qu’ils sont tous deux exécutés dans le même cluster. Sinon, `RemoteEnvironment` n’est ni généré ni signalé dans les métriques de dépendance du service. Actuellement disponible uniquement sur les plateformes Amazon EKS et K8S. La valeur maximale est de 259 caractères. |
| `RemoteResourceIdentifier` | Le nom de la ressource invoquée par un appel distant. Le `RemoteResourceIdentifier` paramètre est automatiquement généré si le service appelle un AWS service distant. Sinon, `RemoteResourceIdentifier` n’est ni généré ni signalé dans les métriques de dépendance du service. La valeur maximale est de 1024 caractères. |
| `RemoteResourceType` | Le type de ressource invoquée par un appel distant. Requis uniquement si `RemoteResourceIdentifier` est défini. La valeur maximale est de 1024 caractères. |
Lorsque vous consultez ces mesures dans la CloudWatch console, vous pouvez les afficher à l'aide des combinaisons de dimensions suivantes :
**Exécution sur des clusters Amazon EKS**
+ `[Environment, Service, Operation, RemoteService, RemoteOperation, RemoteEnvironment, RemoteResourceIdentifier, RemoteResourceType, [Latency, Error, Fault]]`
+ `[Environment, Service, Operation, RemoteService, RemoteOperation, RemoteEnvironment, [Latency, Error, Fault]]`
+ `[Environment, Service, Operation, RemoteService, RemoteOperation, RemoteResourceIdentifier, RemoteResourceType, [Latency, Error, Fault]]`
+ `[Environment, Service, Operation, RemoteService, RemoteOperation, [Latency, Error, Fault]]`
+ `[Environment, Service, RemoteService, RemoteEnvironment, [Latency, Error, Fault]]`
+ `[Environment, Service, RemoteService, [Latency, Error, Fault]]`
+ `[Environment, Service, RemoteService, RemoteOperation, RemoteEnvironment, RemoteResourceIdentifier, RemoteResourceType, [Latency, Error, Fault]]`
+ `[Environment, Service, RemoteService, RemoteOperation, RemoteEnvironment, [Latency, Error, Fault]]`
+ `[Environment, Service, RemoteService, RemoteOperation, RemoteResourceIdentifier, RemoteResourceType, [Latency, Error, Fault]]`
+ `[Environment, Service, RemoteService, RemoteOperation, [Latency, Error, Fault]]`
+ `[RemoteService [Latency, Error, Fault]]`
+ `[RemoteService, RemoteResourceIdentifier, RemoteResourceType [Latency, Error, Fault]]`
## 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 que les métriques d’exécution soient collectées, vous devez remplir les conditions préalables suivantes :
+ Votre CloudWatch agent doit être une version `1.300049.1` ou une version ultérieure.
+ Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS, il doit s'agir d'une version `2.30-eksbuild.1` ou d'une version ultérieure. Si vous mettez à jour le module complémentaire, vous devez redémarrer vos applications.
+ Pour les applications Java, vous devez exécuter le logiciel AWS Distro for OpenTelemetry SDK for Java `1.32.5` ou une version ultérieure.
+ Pour les applications Python, vous devez exécuter le AWS Distro for OpenTelemetry SDK for Python `0.7.0` ou une version ultérieure.
+ Pour les applications .Net, vous devez exécuter le AWS Distro for OpenTelemetry SDK for .Net `1.6.0` ou une version ultérieure.
Les métriques d’exécution ne sont pas collectées pour les applications Node.js.
Les métriques d’exécution sont facturées dans le cadre des coûts de la vigie applicative. Pour plus d'informations sur CloudWatch les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing).
**Note**
**Problèmes connus**
La collecte de métriques d'exécution dans la version v1.32.5 du SDK Java est connue pour ne pas fonctionner avec les applications utilisant Wildfly. JBoss Ce problème s'étend au module complémentaire Amazon CloudWatch Observability EKS, affectant les `2.3.0-eksbuild.1` versions `2.6.0-eksbuild.1` suivantes. Le problème est résolu dans la version du SDK Java `v1.32.6` et dans la version du module complémentaire Amazon CloudWatch Observability EKS. `v3.0.0-eksbuild.1`
Si vous êtes concerné, mettez à niveau la version du kit SDK Java ou désactivez la collecte des métriques d’exécution en ajoutant la variable d’environnement `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` à votre application.
### Métriques d’exécution Java
La vigie applicative collecte les métriques JVM suivantes à partir des applications Java que vous activez pour la vigie applicative. Toutes les métriques d'exécution sont envoyées CloudWatch dans l'espace de `ApplicationSignals` noms et sont collectées avec le jeu de `Environment` dimensions `Service` et.
| Nom des métriques | Description | Statistiques significatives |
| --- | --- | --- |
| `JVMGCDuration` | Métrique agrégée pour la durée des actions de récupérateur de mémoire JVM. Unité : millisecondes | Somme, moyenne, minimum, maximum |
| `JVMGCOldGenDuration` | Métrique agrégée pour la durée des actions de récupérateur de mémoire JVM de l’ancienne génération. Disponible uniquement dans G1. Unité : millisecondes | Somme, moyenne, minimum, maximum |
| `JVMGCYoungGenDuration` | Métrique agrégée pour la durée des actions de récupérateur de mémoire JVM de de la nouvelle génération. Disponible uniquement dans G1. Unité : millisecondes | Somme, moyenne, minimum, maximum |
| `JVMGCCount` | Métrique agrégée pour le nombre d’actions de récupérateur de mémoire JVM. Unité : aucune | Somme, moyenne, minimum, maximum |
| `JVMGCOldGenCount` | Métrique agrégée pour le nombre d’actions de récupérateur de mémoire JVM de l’ancienne génération. Disponible uniquement dans G1. Unité : aucune | Somme, moyenne, minimum, maximum |
| `JVMGCYoungGenCount` | Métrique agrégée pour le nombre d’actions de récupérateur de mémoire JVM de la nouvelle génération. Disponible uniquement dans G1. Unité : aucune | Somme, moyenne, minimum, maximum |
| `JVMMemoryHeapUsed` | Quantité de mémoire de tas utilisée. Unité : octets | Moyenne, Minimum, Maximum |
| `JVMMemoryUsedAfterLastGC` | Quantité de mémoire utilisée, telle que mesurée après le dernier événement de récupérateur de mémoire sur ce groupe. Unité : octets | Moyenne, Minimum, Maximum |
| `JVMMemoryOldGenUsed` | Quantité de mémoire utilisée par l’ancienne génération. Unité : octets | Moyenne, Minimum, Maximum |
| `JVMMemorySurvivorSpaceUsed` | Quantité de mémoire de tas utilisée par l’espace survivant. Unité : octets | Moyenne, Minimum, Maximum |
| `JVMMemoryEdenSpaceUsed` | Quantité de mémoire utilisée par l’espace eden. Unité : octets | Moyenne, Minimum, Maximum |
| `JVMMemoryNonHeapUsed` | Quantité de mémoire non-tas utilisée. Unité : octets | Moyenne, Minimum, Maximum |
| `JVMThreadCount` | Nombre de threads en cours d’exécution, y compris les threads daemon et non daemon. Unité : aucune | Somme, moyenne, minimum, maximum |
| `JVMClassLoaded` | Nombre de classes chargées. Unité : aucune | Somme, moyenne, minimum, maximum |
| `JVMCpuTime` | Le temps processeur utilisé par le processus, tel que rapporté par la JVM. Unité : Aucune (nanosecondes) | Somme, moyenne, minimum, maximum |
| `JVMCpuRecentUtilization` | Le temps processeur récemment utilisé par le processus, tel que rapporté par la JVM. Unité : aucune | Moyenne, Minimum, Maximum |
### Métriques d’exécution Python
La vigie applicative collecte les métriques suivantes à partir des applications Python que vous activez pour la vigie applicative. Toutes les métriques d'exécution sont envoyées CloudWatch dans l'espace de `ApplicationSignals` noms et sont collectées avec le jeu de `Environment` dimensions `Service` et.
| Nom des métriques | Description | Statistiques significatives |
| --- | --- | --- |
| `PythonProcessGCCount` | Le nombre total d’objets actuellement suivis. Unité : aucune | Somme, moyenne, minimum, maximum |
| `PythonProcessGCGen0Count` | Le nombre d’objets actuellement suivis dans Génération 0. Unité : aucune | Somme, moyenne, minimum, maximum |
| `PythonProcessGCGen1Count` | Le nombre d’objets actuellement suivis dans Génération 1. Unité : aucune | Somme, moyenne, minimum, maximum |
| `PythonProcessGCGen2Count` | Le nombre d’objets actuellement suivis dans Génération 2. Unité : aucune | Somme, moyenne, minimum, maximum |
| `PythonProcessVMSMemoryUsed` | Quantité totale de mémoire virtuelle utilisée par le processus. Unité : octets | Moyenne, Minimum, Maximum |
| `PythonProcessRSSMemoryUsed` | Quantité totale de mémoire physique non permutée utilisée par le processus. Unité : octets | Moyenne, Minimum, Maximum |
| `PythonProcessThreadCount` | Nombre de threads actuellement utilisés par le processus. Unité : aucune | Somme, moyenne, minimum, maximum |
| `PythonProcessCpuTime` | Temps processeur utilisé par le processus. Unité : secondes | Somme, moyenne, minimum, maximum |
| `PythonProcessCpuUtilization` | Utilisation du processeur par le processus. Unité : aucune | Moyenne, Minimum, Maximum |
### Métrique d’exécution .Net
La vigie applicative collecte les métriques suivantes à partir des applications .Net que vous activez pour la vigie applicative. Toutes les métriques d'exécution sont envoyées CloudWatch dans l'espace de `ApplicationSignals` noms et sont collectées avec le jeu de `Environment` dimensions `Service` et.
| Nom des métriques | Description | Statistiques significatives |
| --- | --- | --- |
| `DotNetGCGen0Count` | Nombre total de métriques de récupérateur de mémoire suivies dans Génération 0 depuis le démarrage du processus. Unité : aucune | Somme, moyenne, minimum, maximum |
| `DotNetGCGen1Count` | Nombre total de métriques de récupérateur de mémoire suivies dans Génération 1 depuis le démarrage du processus. Unité : aucune | Somme, moyenne, minimum, maximum |
| `DotNetGCGen2Count` | Nombre total de métriques de récupérateur de mémoire suivies dans Génération 2 depuis le démarrage du processus. Unité : aucune | Somme, moyenne, minimum, maximum |
| `DotNetGCDuration` | Durée totale de pause dans le récupérateur de mémoire depuis le démarrage du processus. Unité : aucune | Somme, moyenne, minimum, maximum |
| `DotNetGCGen0HeapSize` | Taille du tas (y compris la fragmentation) de Génération 0 observée lors du dernier récupérateur de mémoire. Cette métrique n’est disponible qu’après la fin du premier récupérateur de mémoire. Unité : octets | Moyenne, Minimum, Maximum |
| `DotNetGCGen1HeapSize` | Taille du tas (y compris la fragmentation) de Génération 1 observée lors du dernier récupérateur de mémoire. Cette métrique n’est disponible qu’après la fin du premier récupérateur de mémoire. Unité : octets | Moyenne, Minimum, Maximum |
| `DotNetGCGen2HeapSize` | Taille du tas (y compris la fragmentation) de Génération 2 observée lors du dernier récupérateur de mémoire. Cette métrique n’est disponible qu’après la fin du premier récupérateur de mémoire. Unité : octets | Moyenne, Minimum, Maximum |
| `DotNetGCLOHHeapSize` | Taille du tas d’objets volumineux (y compris la fragmentation) observée lors du dernier récupérateur de mémoire. Cette métrique n’est disponible qu’après la fin du premier récupérateur de mémoire. Unité : octets | Moyenne, Minimum, Maximum |
| `DotNetGCPOHHeapSize` | Taille du tas d’objets épinglés (y compris la fragmentation) observée lors du dernier récupérateur de mémoire. Cette métrique n’est disponible qu’après la fin du premier récupérateur de mémoire. Unité : octets | Moyenne, Minimum, Maximum |
| `DotNetThreadCount` | Nombre de threads du groupe de threads actuellement existants. Unité : aucune | Moyenne, Minimum, Maximum |
| `DotNetThreadQueueLength` | Nombre d’éléments de travail actuellement en attente d’être traités par le groupe de threads. Unité : aucune | Moyenne, Minimum, Maximum |
## Désactivation de la collecte des métriques d’exécution
Les métriques d’exécution sont collectées par défaut pour les applications Java et Python qui sont activées pour la vigie applicative. Si vous voulez désactiver la collecte de ces métriques, veuillez suivre les instructions de cette section pour votre environnement.
### Amazon EKS
Pour désactiver les métriques d’exécution dans les applications Amazon EKS au niveau de l’application, ajoutez la variable d’environnement suivante à votre spécification de charge de travail.
```
env:
- name: OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED
value: "false"
```
Pour désactiver les métriques d'exécution dans les applications Amazon EKS au niveau du cluster, appliquez la configuration à la configuration avancée de votre module complémentaire Amazon CloudWatch Observability EKS.
```
{
"agent": {
"config": {
"traces": {
"traces_collected": {
"application_signals": {
}
}
},
"logs": {
"metrics_collected": {
"application_signals": {
}
}
}
},
"manager": {
"autoInstrumentationConfiguration": {
"java": {
"runtime_metrics": {
"enabled": false
}
},
"python": {
"runtime_metrics": {
"enabled": false
}
},
"dotnet": {
"runtime_metrics": {
"enabled": false
}
}
}
}
}
}
```
### Amazon ECS
Pour désactiver les métriques d’exécution dans les applications Amazon ECS, ajoutez la variable d’environnement `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` dans la nouvelle révision de définition de tâche et redéployez l’application.
### EC2
Pour désactiver les métriques d’exécution dans les applications Amazon EC2, ajoutez la variable d’environnement `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` avant le démarrage de l’application.
### Kubernetes
Pour désactiver les métriques d’exécution dans les applications Kubernetes au niveau de l’application, ajoutez la variable d’environnement suivante à votre spécification de charge de travail.
```
env:
- name: OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED
value: "false"
```
Pour désactiver les métriques d’exécution dans les applications Kubernetes au niveau du cluster, utilisez ce qui suit :
```
helm upgrade ... \
--set-string manager.autoInstrumentationConfiguration.java.runtime_metrics.enabled=false \
--set-string manager.autoInstrumentationConfiguration.python.runtime_metrics.enabled=false \
-\-set-string manager.autoInstrumentationConfiguration.dotnet.runtime_metrics.enabled=false
```
# Métriques personnalisées avec la vigie applicative
Pour surveiller les performances et la disponibilité des applications, la vigie applicative collecte des métriques standard (défaillances, erreurs et latence) et des métriques d’exécution à partir des applications détectées après son activation.
Les métriques personnalisées ajoutent un contexte précieux à la surveillance de vos applications et contribuent à accélérer le dépannage. Vous pouvez les utiliser pour :
+ Personnaliser l’analyse des données de télémétrie
+ Identifier les causes racine des problèmes
+ Prendre rapidement des décisions commerciales et opérationnelles précises
La vigie applicative vous permet d’afficher et de corréler les métriques personnalisées générées à partir d’un service avec les métriques standard et d’exécution. Par exemple, une application peut émettre des métriques pour la taille des demandes et le nombre d’échecs de cache. Ces métriques personnalisées fournissent des informations plus détaillées sur les problèmes de performances, vous aidant à diagnostiquer et à résoudre plus rapidement les baisses de disponibilité et les pics de latence.
**Topics**
+ [Configuration des métriques personnalisées pour la vigie applicative](#AppSignals-CustomMetrics-Adding)
+ [Affichage des métriques personnalisées dans la vigie applicative](#AppSignals-CustomMetrics-Viewing)
+ [Questions fréquemment posées (FAQ)](#AppSignals-CustomMetrics-FAQ)
## Configuration des métriques personnalisées pour la vigie applicative
Vous pouvez générer des métriques personnalisées à partir de votre application à l’aide de deux méthodes : les *métriques OpenTelemetry* et les *métriques de portée*.
**Topics**
+ [Métriques OpenTelemetry](#AppSignals-CustomMetrics-OpenTelemetry)
+ [Métriques de portée](#AppSignals-CustomMetrics-SpanMetrics)
### Métriques OpenTelemetry
Pour utiliser des métriques OpenTelemetry personnalisées avec la vigie applicative, vous devez utiliser soit l’agent CloudWatch, soit le collecteur OpenTelemetry. Les métriques OpenTelemetry personnalisées vous permettent de créer et d’exporter des métriques directement à partir du code de votre application à l’aide du kit SDK des métriques OpenTelemetry.
1. Intégrez le service à la vigie applicative.
1. Configurez l’agent ou le collecteur.
+ Lorsque vous utilisez l’agent CloudWatch, vous devez [configurer](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-OpenTelemetry-metrics.html) `metrics_collected` avec un `otlp`. Par exemple, `cloudwatch-config.json`
```
{
"traces": {
"traces_collected": {
"application_signals": {}
}
},
"logs": {
"metrics_collected": {
"application_signals": {},
"otlp": {
"grpc_endpoint": "0.0.0.0:4317",
"http_endpoint": "0.0.0.0:4318"
}
}
}
}
```
+ Lorsque vous utilisez le collecteur OpenTelemetry, configurez un pipeline de métriques. Vous devez utiliser [l’exportateur EMF CloudWatch pour le collecteur OpenTelemetry](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/awsemfexporter) et activer les [attributs de ressource pour les étiquettes de métriques](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/awsemfexporter#resource-attributes-to-metric-labels). Il est recommandé de configurer ` dimension_rollup_option: NoDimensionRollup` pour éviter d’émettre de nombreuses agrégations de métriques. Par exemple, `config.yaml` :
```
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
exporters:
awsemf:
region: $REGION
namespace: $NAMESPACE
log_group_name:$LOG_GROUP_NAME
resource_to_telemetry_conversion:
enabled: true
dimension_rollup_option: "NoDimensionRollup"
otlphttp/traces:
compression: gzip
traces_endpoint: https://xray.$REGION.amazonaws.com/v1/traces
auth:
authenticator: sigv4auth/traces
extensions:
sigv4auth/logs:
region: "$REGION"
service: "logs"
sigv4auth/traces:
region: "$REGION"
service: "xray"
processors:
batch:
service:
telemetry:
extensions: [sigv4auth/logs, sigv4auth/traces]
pipelines:
metrics:
receivers: [otlp]
processors: [batch]
exporters: [awsemf]
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/traces]
```
1. Configurez l'environnement. Lorsque plusieurs services portent le même nom et afin de corréler avec précision les métriques de la vigie applicative au nom de service correct, il est recommandé de configurer l’attribut de ressource `deployment.environment.name`. La configuration de cet attribut de ressource s’effectue généralement via les variables d’environnement.
```
OTEL_RESOURCE_ATTRIBUTES="service.name=$YOUR_SVC_NAME,deployment.environment.name=$YOUR_ENV_NAME"
```
1. Configurez l’exportation des métriques vers l’agent CloudWatch ou le collecteur OpenTelemetry. Vous pouvez utiliser l’une des approches suivantes :
+ (Recommandé) Pipeline d’exportation personnalisé : dans le code de l’application, créez un [MeterProvider](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#meterprovider) dédié qui exporte vers l’agent configuré ou le point de terminaison du collecteur. Par exemple :
```
Resource resource = Resource.getDefault().toBuilder()
.put(AttributeKey.stringKey("service.name"), serviceName)
.put(AttributeKey.stringKey("deployment.environment.name"), environment)
.build();
MetricExporter metricExporter = OtlpHttpMetricExporter.builder()
.setEndpoint("http://localhost:4318/v1/metrics")
.build();
MetricReader metricReader = PeriodicMetricReader.builder(metricExporter)
.setInterval(Duration.ofSeconds(10))
.build()
SdkMeterProvider meterProvider = SdkMeterProvider.builder()
.setResource(resource)
.registerMetricReader()
.build();
Meter meter = meterProvider.get("myMeter");
```
+ Exportation basée sur l’agent : configurez les variables d’environnement de l’agent [OTEL\$1METRICS\$1EXPORTER](https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#exporter-selection) et [OTEL\$1EXPORTER\$1OTLP\$1METRICS\$1ENDPOINT](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/#otel_exporter_otlp_metrics_endpoint). Par exemple :
```
OTEL_METRICS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://localhost:4318/v1/metrics
```
Dans le code de l’application, utilisez le MeterProvider global créé par l’agent. Par exemple :
```
Meter meter = GlobalOpenTelemetry.getMeter("myMeter");
```
1. À l’aide du [kit SDK de métriques OTEL](https://opentelemetry.io/docs/specs/otel/metrics/sdk/) dans le code de l’application, ajoutez les métriques OTEL. Par exemple, pour ajouter les métriques OTEL en Python :
```
counter = meter.counterBuilder("myCounter").build();
counter.add(value);
counter.add(value, Attributes.of(AttributeKey.stringKey("Operation"), "myOperation"));
```
L’ajout de l’attribut Operation n’est pas obligatoire, mais peut être utile pour corréler les opérations du service de la vigie applicative aux métriques OpenTelemetry personnalisées.
### Métriques de portée
Les métriques de portée personnalisées ne fonctionnent actuellement qu’avec la recherche de transactions. Avec les métriques de portée personnalisées, vous pouvez :
+ Créer des métriques à l’aide de filtres de métriques
+ Traiter les attributs de portée ajoutés dans le code de l’application
+ Utiliser le kit SDK de traces OpenTelemetry pour la mise en œuvre
1. Activer la surveillance de la vigie applicative avec la recherche de transactions. Pour plus d’informations, consultez [Recherche de transactions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search-getting-started.html).
Pour garantir un échantillonnage des métriques à 100 %, il est recommandé d’envoyer 100 % des portées au point de terminaison.
1. Ajoutez des attributs de portée à l’aide du [kit SDK de traces OTEL](https://opentelemetry.io/docs/specs/otel/trace/sdk/). Il existe deux méthodes :
+ [Recommandé] Ajoutez des attributs aux portées générées automatiquement. Par exemple :
```
Span.current().setAttribute("myattribute", value);
```
+ Ajoutez des attributs aux portées générées manuellement. Par exemple :
```
Span span = tracer.spanBuilder("myspan").startSpan();
try (Scope scope = span.makeCurrent()) {
span.setAttribute("myattribute", value);
}
```
1. Créez un filtre de métrique avec les valeurs suivantes. Pour plus d’informations sur la création d’un filtre de métrique, consultez [Créer un filtre de métrique pour un groupe de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html).
+ Groupe de journaux : aws/spans
+ Modèle de filtre : \$1 \$1.attributes.['myattribute'] = \$1 \$1
+ Nom de la métrique : myattribute (les valeurs doivent correspondre exactement, sinon la corrélation des intervalles ne fonctionnera pas)
+ Valeur de la métrique : \$1.attributes.['myattribute']
+ Dimensions – Nom du champ : Service, Valeur du champ : \$1.attributes.['aws.local.service'], Nom du champ : Environment, Valeur du champ : \$1.attributes.['aws.local.environment'], et Nom du champ : Operation, Valeur du champ : \$1.attributes.['aws.local.operation']
**Note**
Lorsque vous ajoutez des attributs à des portées générées manuellement, vous ne pouvez pas définir `Operation` car `aws.local.operation` ne sera pas présent dans les données de la portée.
## Affichage des métriques personnalisées dans la vigie applicative
Vous pouvez désormais afficher les métriques personnalisées pour les services et les opérations dans la console de la vigie applicative :
+ Sélectionnez un service dans la liste **Services** pour afficher le nouvel onglet **Métriques associées**
+ Affichez les métriques standard, les métriques d’exécution et les métriques associées pour le service sélectionné
+ Filtrez et sélectionnez plusieurs métriques dans la liste
+ Représentez graphiquement les métriques sélectionnées pour identifier les corrélations et les causes racine des problèmes
Pour plus d’informations sur les métriques associées, consultez [Afficher les métriques associées](ServiceDetail.md#ServiceDetail-relatedmetrics).
## Questions fréquemment posées (FAQ)
### Quel est l’impact de ne pas ajouter la configuration pour l’environnement des métriques personnalisées ?
La vigie applicative configure l’attribut de ressource `deployment.environment.name` pour lever toute ambiguïté entre les applications. La vigie applicative ne peut pas corréler les métriques personnalisées générées à partir de deux services différents portant le même nom avec le service correct sans lever l’ambiguïté.
Pour ajouter une configuration d’environnement à votre application, consultez [Métriques OpenTelemetry](#AppSignals-CustomMetrics-OpenTelemetry).
### Existe-t-il des limites pour les filtres de métrique ?
Vous ne pouvez créer que 100 filtres de métriques par groupe de journaux CloudWatch Logs. Chaque métrique définie peut avoir jusqu’à 3 dimensions. Vous pouvez consulter les limites des filtres de métriques ici [Métriques OpenTelemetry](#AppSignals-CustomMetrics-OpenTelemetry).
### Pourquoi les graphiques de métriques n’apparaissent-ils pas dans le tableau des métriques ?
La solution dépend de votre type de métrique :
+ Métriques personnalisées : consultez [Configuration des métriques personnalisées pour la vigie applicative](#AppSignals-CustomMetrics-Adding) pour vérifier la configuration des métriques
+ Métriques standard ou d’exécution : consultez [Dépannage de votre installation de la vigie applicative](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-Troubleshoot.html)