**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Monitoraggio delle metriche del cluster con Prometheus [Prometheus](https://prometheus.io/) è un database di monitoraggio e di serie temporali che esegue lo scraping degli endpoint. Offre la possibilità di eseguire query, aggregare e archiviare i dati raccolti. È possibile utilizzarlo anche per gli avvisi e l'aggregazione degli avvisi. Questo argomento spiega come configurare Prometheus come un’opzione gestita oppure open source. Il monitoraggio dei parametri del piano di controllo di Amazon EKS è un caso d'uso comune. Amazon Managed Service for Prometheus è un servizio di monitoraggio e avviso compatibile con Prometheus che semplifica il monitoraggio di applicazioni e infrastrutture containerizzate su larga scala. È un servizio completamente gestito che dimensiona automaticamente l'importazione, l'archiviazione, le query e gli avvisi dei parametri. Si integra anche con i servizi di sicurezza di AWS per consentire un accesso rapido e sicuro ai tuoi dati. È possibile utilizzare il linguaggio di query open source ProMQL per fare una query e creare avvisi relativi ai parametri. Inoltre, è possibile utilizzare l’alert manager nel servizio gestito da Amazon per Prometheus per configurare le regole di avviso per gli avvisi critici. Quindi, è possibile inviare questi avvisi critici come notifiche a un argomento Amazon SNS. Esistono diverse opzioni per utilizzare Prometheus con Amazon EKS: + È possibile attivare le metriche Prometheus quando si crea per la prima volta un cluster Amazon EKS o è possibile creare il proprio scraper Prometheus personalizzato per i cluster esistenti. Entrambe queste opzioni sono trattate in questo argomento. + È possibile implementare Prometheus utilizzando Helm. Per ulteriori informazioni, consulta [Implementare Prometheus utilizzando Helm](deploy-prometheus.md). + È possibile visualizzare le metriche grezze del piano di controllo in formato Prometheus. Per ulteriori informazioni, consulta [Recupero delle metriche grezze del piano di controllo in formato Prometheus](view-raw-metrics.md). ## Passaggio 1: attivazione delle metriche Prometheus **Importante** Le risorse del servizio gestito da Amazon per Prometheus non rientrano nel ciclo di vita del cluster e devono essere gestite indipendentemente dal cluster. Quando si elimina il cluster, assicurarsi di eliminare anche tutti gli scraper applicabili per bloccare i relativi costi. Per ulteriori informazioni, consulta [Trova ed elimina scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) nella *Guida per l’utente del servizio gestito da Amazon per Prometheus*. Prometheus rileva e raccoglie i parametri dal cluster tramite un modello basato su pull chiamato scraping. Gli scraper sono configurati per raccogliere dati dall'infrastruttura del cluster e dalle applicazioni containerizzate. Quando attivi l’opzione di invio delle metriche Prometheus, il servizio gestito da Amazon per Prometheus fornisce uno scraper privo di agente completamente gestito. Se non hai ancora creato il cluster, è possibile attivare l’opzione per inviare i le metriche a Prometheus al momento della creazione del cluster per la prima volta. Nella console Amazon EKS, questa opzione si trova nel passaggio **Configura osservabilità** della creazione di un nuovo cluster. Per ulteriori informazioni, consulta [Crea un cluster Amazon EKS.](create-cluster.md). Se si dispone già di un cluster esistente, è possibile creare il proprio scraper Prometheus. Per eseguire questa operazione nella console Amazon EKS, accedi alla scheda **Osservabilità** del cluster e scegli il pulsante **Aggiungi scraper**. Se preferisci farlo con l’API AWS o AWS CLI, consulta [Creare uno scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) nella *Guida per l’utente del servizio gestito da Amazon per Prometheus*. Le seguenti opzioni sono disponibili quando si crea lo scraper con la console Amazon EKS. **Alias scraper** (Facoltativo) Inserisci un alias univoco per lo scraper. **Destinazione** Scegli un workspace Amazon Managed Service for Prometheus. un'area di lavoro è uno spazio logico dedicato all'archiviazione e all'interrogazione dei parametri di Prometheus. Con questo workspace, sarai in grado di visualizzare i le metriche Prometheus di tutti gli account che vi hanno accesso. L'opzione **Crea nuovo workspace** consente ad Amazon EKS di creare un workspace per tuo conto utilizzando **l'alias del workspace** che fornisci. Con l'opzione **Seleziona workspace esistente**, puoi selezionare un workspace esistente da un elenco a discesa. Per ulteriori informazioni sui workspace, consulta [Gestione di workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-manage-ingest-query.html) nella *Guida per l'utente di Amazon Managed Service for Prometheus*. **Accesso al servizio** Questa sezione riassume le autorizzazioni concesse per l’invio delle metriche Prometheus: + Consentire ad Amazon Managed Service for Prometheus di descrivere il cluster Amazon EKS sottoposto a scraping + Consentire la scrittura remota nel workspace gestito da Amazon per Prometheus Se `AmazonManagedScraperRole` esiste già, viene utilizzato dallo scraper. Scegli il link `AmazonManagedScraperRole` per visualizzare i **dettagli dell'autorizzazione**. Se `AmazonManagedScraperRole` non esiste ancora, scegli il link **Visualizza dettagli di autorizzazione** per vedere le autorizzazioni specifiche che concedi inviando le metriche Prometheus. **Sottoreti** Modificare le sottoreti che sono ereditate dallo scraper. Se è necessario aggiungere un’opzione di sottoreti disattivata, torna al passaggio di creazione del cluster **Specifica la rete**. **Configurazione dello scraper** Modifica la configurazione dello scraper in formato YAML secondo le esigenze. A tale scopo, utilizza il modulo o carica un file YAML sostitutivo. Per ulteriori informazioni, consulta [Configurazione dello scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) nella *Guida per l'utente di Amazon Managed Service for Prometheus*. Amazon Managed Service for Prometheus si riferisce allo scraper agentless creato insieme al cluster come raccoglitore gestito da AWS. Per ulteriori informazioni sugli agenti di raccolta gestiti da AWS, consulta [Imposta metriche con raccoglitori gestiti da AWS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) nella *Guida per l’utente del servizio gestito da Amazon per Prometheus*. **Importante** Se crei uno scraper Prometheus utilizzando AWS CLI o AWS API, è necessario modificarne la configurazione per fornire allo scraper le autorizzazioni interne al cluster. Per ulteriori informazioni, consulta [Configurazione del cluster Amazon EKS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) nella *Guida per l'utente di Amazon Managed Service for Prometheus*. Se disponi di uno scraper Prometheus creato prima dell’11 novembre 2024 che utilizza `aws-auth` `ConfigMap` anziché le voci di accesso, devi aggiornarlo per accedere a metriche aggiuntive dal piano di controllo del cluster Amazon EKS. Per la configurazione aggiornata, consulta [Configurazione manuale di Amazon EKS per l’accesso allo scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-manual-setup) nella *Guida per l’utente del servizio gestito da Amazon per Prometheus*. ## Passaggio 2: utilizzo delle metriche Prometheus Per ulteriori informazioni su come utilizzare le metriche Prometheus dopo averli attivati per il cluster, consulta la [Guida per l’utente del servizio gestito da Amazon per Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html). ## Passaggio 3: gestione degli scraper Prometheus Per gestire gli scraper, scegli la scheda **Osservabilità** nella console Amazon EKS. Una tabella mostra un elenco di scraper per il cluster, incluse informazioni come l'ID, l'alias, lo stato e la data di creazione dello scraper. È possibile aggiungere altri scraper, modificarli, eliminarli o visualizzare ulteriori informazioni sugli scraper correnti. Per visualizzare ulteriori dettagli sullo scraper, scegli un link relativo all’ID dello scraper. Ad esempio, è possibile visualizzare ARN, ambiente, ID dell’area di lavoro, ruolo IAM, configurazione e informazioni sulla rete. È possibile utilizzare l’ID scraper come input per operazioni dell’API del servizio gestito da Amazon per Prometheus come [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) e [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html). Per ulteriori informazioni sull’uso dell’API Prometheus, consulta [Riferimento delle API del servizio gestito da Amazon per Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-APIReference.html). # Implementare Prometheus utilizzando Helm In alternativa all’utilizzo del Servizio gestito da Amazon per Prometheus, è possibile implementare Prometheus nel cluster con Helm. Se Helm è già stato installato, è possibile controllarne la versione con il comando `helm version`. Helm è un programma di gestione del pacchetto per cluster Kubernetes. Per ulteriori informazioni su Helm e su come installarlo, consultare [Implementazione di applicazioni con Helm su Amazon EKS](helm.md). Dopo aver configurato Helm per il cluster Amazon EKS, è possibile utilizzarlo per implementare Prometheus attraverso i seguenti passaggi. 1. Creare un namespace Prometheus. ``` kubectl create namespace prometheus ``` 1. Aggiungere il repository del grafico `prometheus-community`. ``` helm repo add prometheus-community https://prometheus-community.github.io/helm-charts ``` 1. Implementare Prometheus. ``` helm upgrade -i prometheus prometheus-community/prometheus \ --namespace prometheus \ --set alertmanager.persistence.storageClass="gp2" \ --set server.persistentVolume.storageClass="gp2" ``` **Nota** Se si riceve l'errore `Error: failed to download "stable/prometheus" (hint: running helm repo update may help)` durante l'esecuzione di questo comando, eseguire `helm repo update prometheus-community`, quindi provare a eseguire nuovamente il comando della fase 2. Se si riceve l'errore `Error: rendered manifests contain a resource that already exists`, eseguire `helm uninstall your-release-name -n namespace `, quindi provare a eseguire nuovamente il comando della fase 3. 1. Verificare che tutti i pod nel namespace `prometheus` siano nello stato `READY`. ``` kubectl get pods -n prometheus ``` Di seguito viene riportato un output di esempio. ``` 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. Utilizzare `kubectl` per eseguire l'inoltro della porta della console Prometheus al computer locale. ``` kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090 ``` 1. Indirizzare un browser web a `http://localhost:9090` per visualizzare la console Prometheus. 1. Scegliere un parametro dal menu **- insert metric at cursor**, quindi selezionare **Execute (Esegui)**. Scegliere la scheda **Graph (Grafico)** per visualizzare il parametro nel tempo. L'immagine che segue mostra `container_memory_usage_bytes` nel tempo. ![\[Parametri Prometheus\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/prometheus-metric.png) 1. Dalla barra di navigazione superiore, scegliere **Status (Stato)**, quindi **Targets (Destinazioni)**. ![\[Console Prometheus\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/prometheus.png) Vengono visualizzati tutti gli endpoint Kubernetes che sono connessi a Prometheus utilizzando il rilevamento di servizi. # Recupero delle metriche grezze del piano di controllo in formato Prometheus Il piano di controllo Kubernetes espone una serie di metriche che sono rappresentate in un [formato Prometheus.](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) Questi parametri sono utili per il monitoraggio e l'analisi. Sono esposti internamente tramite endpoint metrici ed è possibile accedervi senza dover implementare completamente Prometheus. Tuttavia, l’implementazione più semplice di Prometheus consente di analizzare le metriche nel tempo. Per visualizzare il risultato delle metriche grezze, sostituisci `endpoint` ed esegui il comando riportato. ``` kubectl get --raw endpoint ``` Questo comando consente di inoltrare qualsiasi endpoint e restituisce la risposta non elaborata. I diversi parametri sono elencati per riga e ogni riga include un nome di parametro, tag e un valore. ``` metric_name{tag="value"[,...]} value ``` ## Recuperare le metriche dal server API L’endpoint del server API generale è esposto sul piano di controllo Amazon EKS. Questo endpoint è utile principalmente per esaminare una metrica specifica. ``` kubectl get --raw /metrics ``` Di seguito viene riportato un output di esempio: ``` [...] # 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 ``` Questo output non elaborato restituisce in modo completo ciò che il server API espone. ## Recupera le metriche del piano di controllo con `metrics.eks.amazonaws.com` Per i cluster con versione Kubernetes `1.28` e successive, Amazon EKS espone anche i parametri relativi al gruppo di API `metrics.eks.amazonaws.com`. Queste metriche includono componenti del piano di controllo come `kube-scheduler` e `kube-controller-manager`. **Nota** Se disponi di una configurazione webhook che potrebbe bloccare la creazione della nuova risorsa `APIService` `v1.metrics.eks.amazonaws.com` nel cluster, la funzionalità degli endpoint delle metriche potrebbe non essere disponibile. È possibile verificarlo nel log di verifica `kube-apiserver` cercando la parola chiave `v1.metrics.eks.amazonaws.com`. ### Recuperare le metriche `kube-scheduler` Utilizza il codice seguente per recuperare le metriche `kube-scheduler`. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics" ``` Di seguito viene riportato un output di esempio: ``` # 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 [...] ``` ### Recuperare le metriche `kube-controller-manager` Utilizza il codice seguente per recuperare le metriche `kube-controller-manager`. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics" ``` Di seguito viene riportato un output di esempio: ``` [...] 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 [...] ``` ### Comprendere le metriche di gestione del sistema di pianificazione e del controller La tabella seguente descrive le metriche di gestione del sistema di pianificazione e del controller rese disponibili per lo scraping in stile Prometheus. Per ulteriori informazioni relative a queste metriche, consulta [Riferimento delle metriche Kubernetes](https://kubernetes.io/docs/reference/instrumentation/metrics/) nella documentazione Kubernetes. | Parametro | Componente del piano di controllo | Descrizione | | --- | --- | --- | | scheduler\$1pending\$1pods | pianificatore | Il numero di pod in attesa di essere pianificati su un nodo per l’esecuzione. | | scheduler\$1schedule\$1attempts\$1total | pianificatore | Il numero di tentativi effettuati per pianificare i pod. | | scheduler\$1preemption\$1attempts\$1total | pianificatore | Il numero di tentativi effettuati dal sistema di pianificazione per i pod con priorità più alta eliminando quelli con priorità inferiore. | | scheduler\$1preemption\$1victims | pianificatore | Il numero di pod che sono stati selezionati per l’espulsione per fare spazio ai pod con priorità più alta. | | scheduler\$1pod\$1scheduling\$1attempts | pianificatore | Il numero di tentativi di pianificare correttamente un pod. | | scheduler\$1scheduling\$1attempt\$1duration\$1seconds | pianificatore | Indica la velocità o la lentezza con cui lo strumento di pianificazione riesce a trovare un luogo adatto per l’esecuzione di un pod in base a vari fattori come la disponibilità delle risorse e le regole di pianificazione. | | scheduler\$1pod\$1scheduling\$1sli\$1duration\$1seconds | pianificatore | La latenza end-to-end per un pod in fase di pianificazione, dal momento in cui il pod entra nella coda di pianificazione. Ciò potrebbe comportare più tentativi di pianificazione. | | cronjob\$1controller\$1job\$1creation\$1skew\$1duration\$1seconds | gestore del controller | Il tempo che intercorre tra la pianificazione dell’esecuzione di un cronjob e la creazione del processo corrispondente. | | workqueue\$1depth | gestore del controller | La profondità corrente della coda. | | workqueue\$1adds\$1total | gestore del controller | Il numero totale di aggiunte gestite dalla coda di lavoro. | | workqueue\$1queue\$1duration\$1seconds | gestore del controller | Il tempo in secondi in cui un elemento rimane nella coda di lavoro prima di essere richiesto. | | workqueue\$1work\$1duration\$1seconds | gestore del controller | Il tempo in secondi impiegato per l’elaborazione di un elemento dalla coda di lavoro. | ## Implementare uno scraper Prometheus per acquisire metriche in modo coerente Per implementare uno scraper Prometheus per eseguire lo scraping delle metriche in modo coerente, utilizza la seguente configurazione: ``` --- 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’autorizzazione che segue è richiesta per consentire al pod di accedere al nuovo endpoint metrico. ``` { "effect": "allow", "apiGroups": [ "metrics.eks.amazonaws.com" ], "resources": [ "kcm/metrics", "ksh/metrics" ], "verbs": [ "get" ] }, ``` Per applicare una patch al ruolo, puoi utilizzare il seguente comando. ``` kubectl patch clusterrole --type=json -p='[ { "op": "add", "path": "/rules/-", "value": { "verbs": ["get"], "apiGroups": ["metrics.eks.amazonaws.com"], "resources": ["kcm/metrics", "ksh/metrics"] } } ]' ``` Quindi puoi visualizzare la dashboard di Prometheus effettuando il proxy della porta dello scraper Prometheus verso la porta locale. ``` kubectl port-forward pods/prom-pod 9090:9090 ``` Per il tuo cluster Amazon EKS, le principali metriche del piano di controllo Kubernetes sono inserite anche nelle metriche di Amazon CloudWatch sotto il namespace `AWS/EKS`. Per visualizzarli, apri la [console CloudWatch](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) e seleziona **Tutte le metriche** dal riquadro di navigazione a sinistra. Nella pagina di selezione **Metriche**, scegli il namespace `AWS/EKS` e una dimensione delle metriche per il tuo cluster.