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. # 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).