**Aidez à améliorer cette page** 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. Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page. 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. # Surveiller les métriques de votre cluster avec Prometheus [Prometheus](https://prometheus.io/) est une base de données de surveillance et de séries chronologiques qui récupère les points de terminaison. Elle permet d’interroger, d’agréger et de stocker les données collectées. Vous pouvez également l’utiliser pour les alertes et l’agrégation des alertes. Cette rubrique explique comment configurer Prometheus en tant qu’option gérée ou open source. La surveillance des métriques du plan de contrôle d’Amazon EKS est un cas d’utilisation courant. Amazon Managed Service for Prometheus est un service de surveillance et d'alerte compatible avec Prometheus qui facilite la surveillance des applications et infrastructures conteneurisées à grande échelle. Il s'agit d'un service entièrement géré qui met automatiquement à l'échelle l'ingestion, le stockage, l'interrogation et l'alerte de vos métriques. Il s'intègre également aux services de sécurité AWS pour permettre un accès rapide et sécurisé à vos données. Vous pouvez utiliser le langage de requête open source PromQL pour interroger vos métriques et émettre des alertes à leur sujet. Vous pouvez également utiliser le gestionnaire d’alertes dans le service géré Amazon pour Prometheus pour configurer des règles d’alerte pour les alertes critiques. Vous pouvez ensuite envoyer ces alertes critiques sous forme de notifications à une rubrique Amazon SNS. Il existe plusieurs options différentes pour utiliser Prometheus avec Amazon EKS : + Vous pouvez activer les métriques Prometheus lors de la création initiale d’un cluster Amazon EKS ou vous pouvez créer votre propre scraper Prometheus pour les clusters existants. Ces deux options sont abordées dans cette rubrique. + Vous pouvez déployer Prometheus à l’aide de Helm. Pour de plus amples informations, consultez [Déployer Prometheus à l’aide de Helm](deploy-prometheus.md). + Vous pouvez afficher les métriques brutes du plan de contrôle au format Prometheus. Pour de plus amples informations, consultez [Récupérer les métriques brutes du plan de contrôle au format Prometheus](view-raw-metrics.md). ## Étape 1 : activer les métriques Prometheus **Important** Les ressources du service géré Amazon pour Prometheus ne font pas partie du cycle de vie du cluster et doivent être gérées indépendamment de celui-ci. Lorsque vous supprimez votre cluster, veillez à supprimer également tous les scrapers concernés afin de mettre fin aux coûts applicables. Pour plus d’informations, consultez [Rechercher et supprimer des scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) dans le *Guide de l’utilisateur du Service géré Amazon pour Prometheus*. Prometheus détecte et collecte les métriques de votre cluster via un modèle basé sur le pull appelé scraping. Les scrapers sont configurés pour collecter des données à partir de l’infrastructure de votre cluster et des applications conteneurisées. Lorsque vous activez l’option d’envoi des métriques Prometheus, le service géré Amazon pour Prometheus fournit un scraper sans agent entièrement géré. Si vous n’avez pas encore créé le cluster, vous pouvez activer l’option d’envoi des métriques à Prometheus lors de la création initiale du cluster. Dans la console Amazon EKS, cette option se trouve dans l’étape **Configurer l’observabilité** de la création d’un nouveau cluster. Pour de plus amples informations, consultez [Création d’un cluster Amazon EKS](create-cluster.md). Si vous disposez déjà d’un cluster, vous pouvez créer votre propre scraper Prometheus. Pour ce faire dans la console Amazon EKS, accédez à l’onglet **Observabilité** de votre cluster et sélectionnez le bouton **Ajouter un scraper**. Si vous préférez utiliser l’API AWS ou l’interface AWS CLI, consultez [Créer un scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) dans le *Guide de l’utilisateur du Service géré Amazon pour Prometheus*. Les options suivantes sont disponibles lors de la création du scraper avec la console Amazon EKS. **Alias du scraper** (Facultatif) Saisissez un alias unique pour le scraper. **Destination (Destination)** Choisissez un espace de travail Amazon Managed Service for Prometheus. Un espace de travail est un espace logique dédié au stockage et à l’interrogation des métriques Prometheus. Avec cet espace de travail, vous pourrez afficher les métriques Prometheus sur tous les comptes qui y ont accès. L’option **Créer un nouvel espace de travail** indique à Amazon EKS de créer un espace de travail en votre nom à l’aide de l’**Alias d’espace de travail** que vous fournissez. L’option **Sélectionner un espace de travail** existant vous permet de sélectionner un espace de travail existant dans une liste déroulante. Pour plus d’informations sur les espaces de travail, consultez [Gestion des espaces de travail](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-manage-ingest-query.html) dans le *Guide de l’utilisateur Amazon Managed Service for Prometheus*. **Accès à un service** Cette section résume les autorisations que vous accordez lorsque vous envoyez des métriques Prometheus : + Autoriser Amazon Managed Service for Prometheus à décrire le cluster Amazon EKS récupéré + Autoriser l’écriture à distance dans l’espace de travail Amazon Managed Prometheus Si `AmazonManagedScraperRole` existe déjà, le scraper l’utilise. Choisissez le lien `AmazonManagedScraperRole` pour voir les **Détails de l’autorisation**. Si le rôle `AmazonManagedScraperRole` n’existe pas encore, sélectionnez le lien **Afficher les détails des autorisations** pour voir les autorisations spécifiques que vous accordez en envoyant des métriques Prometheus. **Sous-réseaux** Modifiez les sous-réseaux que le scraper héritera selon vos besoins. Si vous devez ajouter une option de sous-réseau grisée, revenez à l’étape **Spécifier le réseau** de la création du cluster. **Configuration du scraper** Modifiez la configuration du scraper au format YAML si nécessaire. Pour ce faire, utilisez le formulaire ou chargez un fichier YAML de remplacement. Pour plus d’informations, consultez [Configuration du scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) dans le *Guide de l’utilisateur Amazon Managed Service for Prometheus*. Amazon Managed Service for Prometheus fait référence au scraper sans agent créé aux côtés du cluster en tant que collecteur géré AWS. Pour plus d’informations sur les collecteurs gérés par AWS, consultez [Ingérer des métriques avec les collecteurs gérés par AWS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) dans le *Guide de l’utilisateur du Service géré Amazon pour Prometheus*. **Important** Si vous créez un scraper Prometheus à l’aide de l’interface AWS CLI ou de l’API AWS, vous devez ajuster sa configuration pour lui attribuer des autorisations au sein du cluster. Pour plus d'informations, consultez [Configuration de votre cluster Amazon EKS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) dans le *Guide de l'utilisateur Amazon Managed Service for Prometheus*. Si vous disposez d’un scraper Prometheus créé avant le 11 novembre 2024 qui utilise le `aws-auth` `ConfigMap` au lieu des entrées d’accès, vous devez le mettre à jour pour accéder à des métriques supplémentaires à partir du plan de contrôle du cluster Amazon EKS. Pour la configuration mise à jour, consultez [Configuration manuelle d’Amazon EKS pour l’accès au scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-manual-setup) dans le *Guide de l’utilisateur du Service géré Amazon pour Prometheus*. ## Étape 2 : utiliser les métriques Prometheus Pour plus d’informations sur l’utilisation des métriques Prometheus après les avoir activées pour votre cluster, consultez le [Guide de l’utilisateur du Service géré Amazon pour Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html). ## Étape 3 : gérer les scrapers Prometheus Pour gérer les scrapers, sélectionnez l’onglet **Observabilité** dans la console Amazon EKS. Un tableau affiche la liste des scrappers du cluster, avec des informations telles que l’ID de scraper, l’alias, le statut et la date de création. Vous pouvez ajouter d’autres scrapers, modifier des scrapers, supprimer des scrapers ou afficher plus d’informations sur les scrapers actuels. Pour obtenir plus de détails sur un scraper, sélectionnez le lien ID du scraper. Vous pouvez par exemple afficher l’ARN, l’environnement, l’ID de l’espace de travail, le rôle IAM, la configuration et les informations réseau. Vous pouvez utiliser l’ID du scraper comme entrée pour les opérations d’API du service géré Amazon pour Prometheus telles que [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html), [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html) et [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html). Pour plus d’informations sur l’utilisation de l’API Prometheus, consultez la [référence d’API du service géré Amazon pour Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-APIReference.html). # Déployer Prometheus à l’aide de Helm Au lieu d’utiliser le service géré Amazon pour Prometheus, vous pouvez déployer Prometheus dans votre cluster avec Helm. Si Helm est déjà installé, vous pouvez vérifier votre version avec la commande `helm version`. Helm est un gestionnaire de package pour les clusters Kubernetes. Pour de plus amples informations sur Helm et son installation, veuillez consulter [Déployez des applications avec Helm sur Amazon EKS](helm.md). Une fois que vous avez configuré Helm pour votre cluster Amazon EKS, vous pouvez l'utiliser pour déployer Prometheus avec les étapes suivantes. 1. Créez un espace de noms Prometheus. ``` kubectl create namespace prometheus ``` 1. Ajoutez le référentiel de graphiques `prometheus-community`. ``` helm repo add prometheus-community https://prometheus-community.github.io/helm-charts ``` 1. Déployez Prometheus. ``` helm upgrade -i prometheus prometheus-community/prometheus \ --namespace prometheus \ --set alertmanager.persistence.storageClass="gp2" \ --set server.persistentVolume.storageClass="gp2" ``` **Note** Si vous obtenez l'erreur `Error: failed to download "stable/prometheus" (hint: running helm repo update may help)` lors de l'exécution de cette commande, exécutez `helm repo update prometheus-community`, puis réessayez d'exécuter la commande Étape 2. Si vous obtenez l'erreur `Error: rendered manifests contain a resource that already exists`, exécutez `helm uninstall your-release-name -n namespace `, puis réessayez d'exécuter la commande Étape 3. 1. Vérifiez que tous les pods dans l’espace de noms `prometheus` sont à l’état `READY`. ``` kubectl get pods -n prometheus ``` L'exemple qui suit illustre un résultat. ``` NAME READY STATUS RESTARTS AGE prometheus-alertmanager-59b4c8c744-r7bgp 1/2 Running 0 48s prometheus-kube-state-metrics-7cfd87cf99-jkz2f 1/1 Running 0 48s prometheus-node-exporter-jcjqz 1/1 Running 0 48s prometheus-node-exporter-jxv2h 1/1 Running 0 48s prometheus-node-exporter-vbdks 1/1 Running 0 48s prometheus-pushgateway-76c444b68c-82tnw 1/1 Running 0 48s prometheus-server-775957f748-mmht9 1/2 Running 0 48s ``` 1. Utilisez `kubectl` pour transférer la console Prometheus vers votre ordinateur local. ``` kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090 ``` 1. Ouvrez un navigateur Web sur `http://localhost:9090` pour afficher la console Prometheus. 1. Choisissez une métrique dans le menu **- insert metric at cursor (insérer une métrique sur le curseur)**, puis choisissez **Execute (Exécuter)**. Choisissez l'onglet **Graph (Graphique)** pour afficher la métrique au fil du temps. L'image suivante montre `container_memory_usage_bytes` au fil du temps. ![\[Métriques Prometheus\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/prometheus-metric.png) 1. Dans la barre de navigation supérieure, choisissez **Status (Statut)**, puis **Targets (Cibles)**. ![\[Console Prometheus\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/prometheus.png) Tous les points de terminaison Kubernetes qui sont connectés à Prometheus à l'aide de la découverte de service sont affichés. # Récupérer les métriques brutes du plan de contrôle au format Prometheus Le plan de contrôle Kubernetes expose un certain nombre de métriques représentées au [format Prometheus](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md). Ces métriques sont utiles pour la surveillance et l’analyse. Elles sont exposées en interne via des points de terminaison de métriques et sont accessibles sans avoir à déployer Prometheus dans son intégralité. Cependant, le déploiement de Prometheus facilite l’analyse des métriques au fil du temps. Pour afficher les métriques brutes, remplacez `endpoint` et exécutez la commande suivante. ``` kubectl get --raw endpoint ``` Cette commande vous permet de passer n’importe quel chemin d’accès au point de terminaison et renvoie la réponse brute. La sortie répertorie différentes métriques ligne par ligne, chaque ligne comprenant un nom de métrique, des balises et une valeur. ``` metric_name{tag="value"[,...]} value ``` ## Récupérer les métriques à partir du serveur API Le point de terminaison général du serveur API est exposé sur le plan de contrôle Amazon EKS. Ce point de terminaison est particulièrement utile lorsque vous recherchez une métrique spécifique. ``` kubectl get --raw /metrics ``` L'exemple qui suit illustre un résultat. ``` [...] # HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host. # TYPE rest_client_requests_total counter rest_client_requests_total{code="200",host="127.0.0.1:21362",method="POST"} 4994 rest_client_requests_total{code="200",host="127.0.0.1:443",method="DELETE"} 1 rest_client_requests_total{code="200",host="127.0.0.1:443",method="GET"} 1.326086e+06 rest_client_requests_total{code="200",host="127.0.0.1:443",method="PUT"} 862173 rest_client_requests_total{code="404",host="127.0.0.1:443",method="GET"} 2 rest_client_requests_total{code="409",host="127.0.0.1:443",method="POST"} 3 rest_client_requests_total{code="409",host="127.0.0.1:443",method="PUT"} 8 # HELP ssh_tunnel_open_count Counter of ssh tunnel total open attempts # TYPE ssh_tunnel_open_count counter ssh_tunnel_open_count 0 # HELP ssh_tunnel_open_fail_count Counter of ssh tunnel failed open attempts # TYPE ssh_tunnel_open_fail_count counter ssh_tunnel_open_fail_count 0 ``` Cette sortie brute renvoie tel quel ce que le serveur d'API expose. ## Récupérer les métriques du plan de contrôle avec `metrics.eks.amazonaws.com` Pour les clusters Kubernetes version `1.28` et supérieure, Amazon EKS expose également les métriques sous le groupe API `metrics.eks.amazonaws.com`. Ces métriques incluent les composants du plan de contrôle tels que `kube-scheduler` et `kube-controller-manager`. **Note** Si vous disposez d’une configuration de webhook susceptible de bloquer la création de la nouvelle ressource `APIService` `v1.metrics.eks.amazonaws.com` sur votre cluster, la fonctionnalité du point de terminaison des métriques peut ne pas être disponible. Vous pouvez le vérifier dans le journal d’audit `kube-apiserver` en recherchant le mot-clé `v1.metrics.eks.amazonaws.com`. ### Récupérer les métriques `kube-scheduler` Pour récupérer les métriques `kube-scheduler`, utilisez la commande suivante. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics" ``` L'exemple qui suit illustre un résultat. ``` # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 0 scheduler_pending_pods{queue="backoff"} 0 scheduler_pending_pods{queue="gated"} 0 scheduler_pending_pods{queue="unschedulable"} 18 # HELP scheduler_pod_scheduling_attempts [STABLE] Number of attempts to successfully schedule a pod. # TYPE scheduler_pod_scheduling_attempts histogram scheduler_pod_scheduling_attempts_bucket{le="1"} 79 scheduler_pod_scheduling_attempts_bucket{le="2"} 79 scheduler_pod_scheduling_attempts_bucket{le="4"} 79 scheduler_pod_scheduling_attempts_bucket{le="8"} 79 scheduler_pod_scheduling_attempts_bucket{le="16"} 79 scheduler_pod_scheduling_attempts_bucket{le="+Inf"} 81 [...] ``` ### Récupérer les métriques `kube-controller-manager` Pour récupérer les métriques `kube-controller-manager`, utilisez la commande suivante. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics" ``` L'exemple qui suit illustre un résultat. ``` [...] workqueue_work_duration_seconds_sum{name="pvprotection"} 0 workqueue_work_duration_seconds_count{name="pvprotection"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-08"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-07"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-06"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-06"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-05"} 19 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.001"} 109 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.01"} 139 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.1"} 181 workqueue_work_duration_seconds_bucket{name="replicaset",le="1"} 191 workqueue_work_duration_seconds_bucket{name="replicaset",le="10"} 191 workqueue_work_duration_seconds_bucket{name="replicaset",le="+Inf"} 191 workqueue_work_duration_seconds_sum{name="replicaset"} 4.265655885000002 [...] ``` ### Comprendre les métriques du planificateur et du gestionnaire de contrôleurs Le tableau suivant décrit les métriques du planificateur et du gestionnaire de contrôleurs qui sont disponibles pour le scraping de type Prometheus. Pour plus d’informations sur ces métriques, consultez [Référence des métriques Kubernetes](https://kubernetes.io/docs/reference/instrumentation/metrics/) dans la documentation Kubernetes. | Métrique | Composant du plan de contrôle | Description | | --- | --- | --- | | scheduler\$1pending\$1pods | planificateur | Nombre de pods en attente d’être planifiés sur un nœud pour exécution. | | scheduler\$1schedule\$1attempts\$1total | planificateur | Nombre de tentatives effectuées pour planifier des pods. | | scheduler\$1preemption\$1attempts\$1total | planificateur | Nombre de tentatives effectuées par le planificateur pour planifier des pods de priorité supérieure en évictant ceux de priorité inférieure. | | scheduler\$1preemption\$1victims | planificateur | Nombre de pods sélectionnés pour être évictés afin de libérer de l’espace pour des pods de priorité supérieure. | | scheduler\$1pod\$1scheduling\$1attempts | planificateur | Nombre de tentatives pour planifier avec succès un pod. | | scheduler\$1scheduling\$1attempt\$1duration\$1seconds | planificateur | Indique la rapidité ou la lenteur avec laquelle le planificateur est capable de trouver un emplacement approprié pour l’exécution d’un pod en fonction de divers facteurs tels que la disponibilité des ressources et les règles de planification. | | scheduler\$1pod\$1scheduling\$1sli\$1duration\$1seconds | planificateur | Latence de bout en bout pour un pod en cours de planification, à partir du moment où le pod entre dans la file d’attente de planification. Cela peut impliquer plusieurs tentatives de planification. | | cronjob\$1controller\$1job\$1creation\$1skew\$1duration\$1seconds | gestionnaire de contrôleur | Temps entre le moment où une tâche cron est planifiée pour être exécutée et le moment où la tâche correspondante est créée. | | workqueue\$1depth | gestionnaire de contrôleur | La profondeur actuelle de la file d’attente. | | workqueue\$1adds\$1total | gestionnaire de contrôleur | Le nombre total d’ajouts traités par la file d’attente de travail. | | workqueue\$1queue\$1duration\$1seconds | gestionnaire de contrôleur | Le temps en secondes pendant lequel un élément reste dans la file d’attente de travail avant d’être demandé. | | workqueue\$1work\$1duration\$1seconds | gestionnaire de contrôleur | Le temps en secondes nécessaire au traitement d’un élément de la file d’attente de travail. | ## Déployer un scraper Prometheus pour récupérer les métriques de manière cohérente Pour déployer un scraper Prometheus afin de récupérer les métriques de manière cohérente, utilisez la configuration suivante : ``` --- apiVersion: v1 kind: ConfigMap metadata: name: prometheus-conf data: prometheus.yml: |- global: scrape_interval: 30s scrape_configs: # apiserver metrics - job_name: apiserver-metrics kubernetes_sd_configs: - role: endpoints scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https # Scheduler metrics - job_name: 'ksh-metrics' kubernetes_sd_configs: - role: endpoints metrics_path: /apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https # Controller Manager metrics - job_name: 'kcm-metrics' kubernetes_sd_configs: - role: endpoints metrics_path: /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https --- apiVersion: v1 kind: Pod metadata: name: prom-pod spec: containers: - name: prom-container image: prom/prometheus ports: - containerPort: 9090 volumeMounts: - name: config-volume mountPath: /etc/prometheus/ volumes: - name: config-volume configMap: name: prometheus-conf ``` L’autorisation suivante est requise pour que le pod puisse accéder au nouveau point de terminaison des métriques. ``` { "effect": "allow", "apiGroups": [ "metrics.eks.amazonaws.com" ], "resources": [ "kcm/metrics", "ksh/metrics" ], "verbs": [ "get" ] }, ``` Pour appliquer un correctif au rôle utilisé, vous pouvez utiliser la commande suivante. ``` kubectl patch clusterrole --type=json -p='[ { "op": "add", "path": "/rules/-", "value": { "verbs": ["get"], "apiGroups": ["metrics.eks.amazonaws.com"], "resources": ["kcm/metrics", "ksh/metrics"] } } ]' ``` Vous pouvez ensuite afficher le tableau de bord Prometheus en redirigeant le port du scraper Prometheus vers votre port local. ``` kubectl port-forward pods/prom-pod 9090:9090 ``` Pour votre cluster Amazon EKS, les métriques du plan de contrôle Kubernetes sont également ingérées dans Amazon CloudWatch Metrics sous l’espace de noms `AWS/EKS`. Pour les afficher, ouvrez la [console CloudWatch](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) et sélectionnez **Toutes les métriques** dans le panneau de navigation gauche. Sur la page de sélection **Métriques**, choisissez l’espace de noms `AWS/EKS` et une dimension de métrique pour votre cluster.