**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 prestazioni del cluster e visualizzazione dei log
Amazon EKS mette a disposizione una serie di strumenti di monitoraggio o registrazione per l'osservazione dei dati. I dati di log di Amazon EKS possono essere trasmessi in streaming a AWS servizi o a strumenti partner per l'analisi dei dati. Sono disponibili molti servizi Console di gestione AWS che forniscono dati per la risoluzione dei problemi di Amazon EKS. Puoi anche utilizzare una soluzione open source AWS supportata per monitorare l'infrastruttura [Amazon EKS](https://docs.aws.amazon.com/grafana/latest/userguide/solution-eks.html).
Dopo aver selezionato **Cluster** nel riquadro di navigazione sinistro della console Amazon EKS, puoi visualizzare l’integrità e i dettagli del cluster selezionandone il nome e scegliendo la scheda **Osservabilità**. Per visualizzare i dettagli delle risorse Kubernetes esistenti implementate nel cluster, consulta [Visualizza le risorse Kubernetes nel Console di gestione AWS](view-kubernetes-resources.md).
Il monitoraggio è una parte importante per mantenere l'affidabilità, la disponibilità e le prestazioni di Amazon EKS e delle tue AWS soluzioni. Ti consigliamo di raccogliere i dati di monitoraggio da tutte le parti della AWS soluzione. per consentire un debug più facile di eventuali errori in più punti. Prima di iniziare il monitoraggio di Amazon EKS, è opportuno creare un piano di monitoraggio che tenga conto dei seguenti aspetti.
+ Quali sono gli obiettivi? Sono necessarie notifiche in tempo reale se i cluster si ridimensionano notevolmente?
+ Di quali risorse si intende eseguire il monitoraggio?
+ Con quale frequenza sarà eseguito il monitoraggio di queste risorse? L'azienda vuole rispondere rapidamente ai rischi?
+ Quali strumenti verranno utilizzati? Se utilizzi già AWS Fargate come parte del lancio, puoi utilizzare il [log](fargate-logging.md) router integrato.
+ Chi eseguirà le attività di monitoraggio?
+ Chi deve ricevere una notifica quando si verifica un problema?
## Registrazione e monitoraggio su Amazon EKS
Amazon EKS offre strumenti integrati per la registrazione e il monitoraggio. Per le versioni supportate, la dashboard di osservabilità offre visibilità sulle prestazioni del cluster. Ti aiuta a rilevare, risolvere e correggere rapidamente i problemi. Oltre alle funzionalità di monitoraggio, include elenchi basati sui log di audit del piano di controllo (control-plane). Il piano di controllo di Kubernetes espone una serie di metriche che possono essere analizzate anche all'esterno della console.
I log del piano di controllo (control-plane) registrano tutte le chiamate dell'API ai tuoi cluster, le informazioni di controllo che acquisiscono quali utenti hanno eseguito determinate azioni sui tuoi cluster, e informazioni basate sui ruoli. Per ulteriori informazioni, consulta [Registrazione e monitoraggio su Amazon EKS nella Guida AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/amazon-eks-logging-monitoring.html) *prescrittiva*.
La registrazione del piano di controllo di Amazon EKS fornisce log di audit e diagnostica direttamente dal piano di controllo di Amazon CloudWatch EKS ai log del tuo account. Questi log consentono di semplificare la protezione e l'esecuzione dei cluster. Puoi selezionare i tipi di log esatti di cui hai bisogno e i log vengono inviati come flussi di log a un gruppo per ogni cluster Amazon EKS in cui opera. CloudWatch Per ulteriori informazioni, consulta [Invia i registri del piano di controllo ai CloudWatch registri](control-plane-logs.md).
**Nota**
Quando controlli i log dell'autenticatore di Amazon EKS su Amazon CloudWatch, vengono visualizzate le voci che contengono testo simile al seguente testo di esempio.
```
level=info msg="mapping IAM role" groups="[]" role="arn:aws: iam::111122223333:role/XXXXXXXXXXXXXXXXXX-NodeManagerRole-XXXXXXXX" username="eks:node-manager"
```
Sono previste voci che contengono questo testo. Lo `username` è un ruolo di servizio Amazon EKS interno che esegue operazioni specifiche per i gruppi di nodi gestiti e nodi Fargate.
Per la registrazione personalizzabile di basso livello, consulta [Registrazione Kubernetes](https://kubernetes.io/docs/concepts/cluster-administration/logging/).
Amazon EKS è integrato con AWS CloudTrail, un servizio che fornisce un registro delle azioni intraprese da un utente, un ruolo o un AWS servizio in Amazon EKS. CloudTrail acquisisce tutte le chiamate API per Amazon EKS come eventi. Le chiamate acquisite includono le chiamate dalla console Amazon EKS e le chiamate di codice alle operazioni API Amazon EKS. Per ulteriori informazioni, consulta [Registra le chiamate API come eventi AWS CloudTrail](logging-using-cloudtrail.md).
Il server API Kubernetes espone una serie di parametri che sono utili per il monitoraggio e l'analisi dei dati. Per ulteriori informazioni, consulta [Monitoraggio delle metriche del cluster con Prometheus](prometheus.md).
Per configurare Fluent Bit per CloudWatch i log Amazon personalizzati, consulta [Configurazione di Fluent Bit](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html#Container-Insights-FluentBit-setup) nella *Amazon CloudWatch * User Guide.
## Strumenti di registrazione e monitoraggio di Amazon EKS
Amazon Web Services offre vari strumenti che permettono di monitorare Amazon EKS. Alcuni di questi strumenti possono essere configurati in modo che eseguano automaticamente il monitoraggio, mentre altri richiedono l'intervento manuale. Ti consigliamo di automatizzare il più possibile i processi di monitoraggio nella misura in cui l'ambiente e il set di strumenti esistenti lo consentono.
La tabella seguente descrive varie opzioni dello strumento di monitoraggio.
| Aree | Strumento | Description | Configurazione |
| --- | --- | --- | --- |
| Piano di controllo | [Dashboard di osservabilità](observability-dashboard.md) | Per le versioni supportate, la dashboard di osservabilità offre visibilità sulle prestazioni del cluster. Ti aiuta a rilevare, risolvere e correggere rapidamente i problemi. | [Procedura di configurazione](observability-dashboard.md) |
| Applicazioni/piano di controllo (control-plane) | [Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) | Prometheus può essere utilizzato per monitorare metriche e avvisi per le applicazioni e il piano di controllo (control-plane). | [Procedura di configurazione](prometheus.md) |
| Applicazioni | [CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) | CloudWatch Container Insights raccoglie, aggrega e riepiloga metriche e log delle applicazioni e dei microservizi containerizzati. | [Procedura di configurazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) |
| Applicazioni | [AWS OpenTelemetry Distro per (ADOT)](https://aws-otel.github.io/docs/introduction) | ADOT può raccogliere e inviare metriche, dati di traccia e metadati correlati a servizi o partner di monitoraggio. AWS Può essere configurato tramite Container Insights. CloudWatch | [Procedura di configurazione](opentelemetry.md) |
| Applicazioni | [Amazon DevOps Guru](https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-devops-guru-coverage-amazon-eks-metrics-cluster/) | Amazon DevOps Guru rileva le prestazioni operative e la disponibilità a livello di nodo. | [Procedura di configurazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) |
| Applicazioni | [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) | AWS X-Ray riceve dati di traccia sull'applicazione. Questi dati di traccia includono le richieste in entrata e in uscita e i metadati relativi a tali richieste. Per Amazon EKS, l'implementazione richiede il OpenTelemetry componente aggiuntivo. | [Procedura di configurazione](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html) |
| Applicazioni | [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) | CloudWatch fornisce gratuitamente alcuni parametri di base di Amazon EKS nelle versioni supportate. Puoi espandere questa funzionalità con CloudWatch Observability Operator per gestire la raccolta di metriche, log e dati di tracciamento. | [Procedura di configurazione](cloudwatch.md) |
La tabella seguente descrive varie opzioni dello strumento di registrazione.
| Aree | Strumento | Description | Configurazione |
| --- | --- | --- | --- |
| Piano di controllo | [Dashboard di osservabilità](observability-dashboard.md) | Per le versioni supportate, la dashboard di osservabilità mostra elenchi basati sui log di audit del piano di controllo (control-plane). Include anche collegamenti per controllare i log dei piani in Amazon CloudWatch. | [Procedura di configurazione](observability-dashboard.md) |
| Applicazioni | [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) | Amazon CloudWatch Container Insights raccoglie, aggrega e riepiloga i parametri e i log delle tue applicazioni e microservizi containerizzati. | [Procedura di configurazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-quickstart.html) |
| Piano di controllo (control-plane) | [ CloudWatch Registri Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) | Puoi inviare i log di controllo e diagnostica direttamente dal piano di controllo di Amazon CloudWatch EKS ai registri del tuo account. | [Procedura di configurazione](control-plane-logs.md) |
| Piano di controllo (control-plane) | [AWS CloudTrail](logging-using-cloudtrail.md) | Registra le chiamate API da parte di un utente, un ruolo o un servizio. | [Procedura di configurazione](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) |
| Diverse aree per le istanze AWS Fargate | [AWS Router di registro Fargate](fargate-logging.md) | Per le istanze AWS Fargate, il router di log trasmette i log ai servizi o agli AWS strumenti dei partner. Utilizza [AWS per Fluent Bit](https://github.com/aws/aws-for-fluent-bit). I log possono essere trasmessi in streaming ad altri servizi o strumenti partner. AWS | [Procedura di configurazione](fargate-logging.md) |
# Monitora il tuo cluster con la dashboard di osservabilità
La console Amazon EKS include una dashboard di osservabilità che offre visibilità nelle prestazioni del cluster. Le informazioni che fornisce aiutano a rilevare, risolvere e chiarire rapidamente i problemi. È possibile aprire la sezione applicabile del dashboard di osservabilità scegliendo un elemento nel **Riepilogo di integrità e prestazioni**. Questo riepilogo è incluso in diversi punti, inclusa la scheda **Osservabilità**.
La dashboard di osservabilità è suddivisa in diverse schede.
## Riepilogo
Il **riepilogo dello stato e delle prestazioni** elenca la quantità di articoli in varie categorie. Ciascun numero funge da collegamento ipertestuale a una posizione nella dashboard di osservabilità con un elenco per quella categoria.
## Integrità del cluster
**L’integrità del cluster** fornisce notifiche importanti di cui essere a conoscenza, su alcune delle quali potrebbe essere necessario intervenire il prima possibile. Con questo elenco, è possibile vedere le descrizioni e le risorse interessate. Lo stato del cluster include due tabelle: **Problemi di integrità** e **Approfondimenti sulla configurazione**. Per aggiornare lo stato dei **Problemi di integrità**, scegli il pulsante di aggiornamento ( ↻ ). Gli **Approfondimenti sulla configurazione** si aggiornano automaticamente una volta ogni 24 ore e non possono essere aggiornate manualmente.
Per ulteriori informazioni sui **Problemi di integrità**, consulta [Integrità del cluster FAQs e codici di errore con percorsi di risoluzione](troubleshooting.md#cluster-health-status). Per ulteriori informazioni su **Approfondimenti sulla configurazione**, consulta [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md).
## Monitoraggio del piano di controllo
La scheda **Monitoraggio del piano di controllo** è divisa in tre sezioni, ognuna delle quali aiuta a monitorare e risolvere i problemi del piano di controllo del cluster.
### Metriche
Per i cluster con versione Kubernetes `1.28` e successive, la sezione **Metriche** mostra grafici di diverse metriche raccolte per vari componenti del piano di controllo.
È possibile impostare il periodo di tempo utilizzato dall’asse X di ogni grafico effettuando le selezioni nella parte superiore della sezione. È possibile aggiornare i dati con il pulsante di aggiornamento ( ↻ ). Per ogni grafico separato, il pulsante con le ellissi verticali (⋮) apre un menu con opzioni da. CloudWatch
Queste e altre metriche sono automaticamente disponibili come metriche di monitoraggio di base nel CloudWatch namespace. `AWS/EKS` Per ulteriori informazioni, consulta la sezione [Monitoraggio di base e monitoraggio dettagliato](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html) nella *Amazon CloudWatch User Guide*. Per ottenere metriche, visualizzazioni e approfondimenti più dettagliati, consulta [Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) nella *Amazon CloudWatch User Guide*. Oppure, se si preferisce un monitoraggio basato su Prometheus, consulta [Monitoraggio delle metriche del cluster con Prometheus](prometheus.md).
La tabella seguente descrive le metriche disponibili.
| Metrica | Description |
| --- | --- |
| APIServer Richieste | Le richieste al minuto effettuate al server API. |
| APIServer Richieste totali 4XX | Il numero di richieste al minuto del server API con codici di risposta HTTP 4XX (errori lato client). |
| APIServer Richieste totali 5XX | Il numero di richieste al minuto del server API con codici di risposta HTTP 5XX (errori lato server). |
| APIServer Richieste totali 429 | Il numero di richieste al minuto del server API con codici di risposta HTTP 429 (troppe richieste). |
| Dimensioni dell’archiviazione | La dimensione del database di archiviazione (`etcd`). |
| Tentativi del sistema di pianificazione | Il numero di tentativi di pianificare i pod in base ai risultati “Non pianificabile”, “Errore” e “Pianificato”. |
| Pod in sospeso | Il numero di pod in sospeso per tipo di coda di “attivo”, “backoff”, “non pianificabile” e “limitato”. |
| Latenza delle richieste del server API | La latenza per le richieste del server API. |
| Richieste correnti del server API | Le richieste correnti per il server API. |
| Richieste webhook | Le richieste webhook al minuto. |
| Rifiuti delle richieste webhook | Il numero di richieste webhook che sono state rifiutate. |
| Latenza della richiesta webhook P99 | La latenza del 99° percentile delle richieste webhook esterne di terze parti. |
### CloudWatch Log Insights
La sezione **CloudWatch Log Insights** mostra vari elenchi basati sui log di controllo del piano di controllo. I log del piano di controllo di Amazon EKS devono essere attivati per utilizzare questa funzionalità, che puoi eseguire dalla sezione **Visualizza i log del piano di controllo**. CloudWatch
Quando è trascorso abbastanza tempo per raccogliere i dati, è possibile **Eseguire tutte le query** o scegliere **Esegui query** per un singolo elenco alla volta. CloudWatch Ogni volta che esegui una richiesta, verrà addebitato un costo aggiuntivo. Nella parte superiore della sezione, scegli il periodo di tempo dei risultati che desideri visualizzare. **Se desideri un controllo più avanzato per qualsiasi query, puoi scegliere Visualizza in. CloudWatch** Ciò ti consentirà di aggiornare una query in CloudWatch base alle tue esigenze.
Per ulteriori informazioni, consulta [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) nella Amazon CloudWatch Logs User Guide.
### Visualizza i log del piano di controllo in CloudWatch
Per aggiornare i tipi di log disponibili, scegli **Gestisci log**. Dopo aver abilitato la registrazione, occorrono alcuni minuti prima che i log vengano visualizzati in CloudWatch Logs. Quando è trascorso tempo sufficiente, scegli uno dei link **Visualizza** in questa sezione per accedere al log applicabile.
Per ulteriori informazioni, consulta [Invia i registri del piano di controllo ai CloudWatch registri](control-plane-logs.md).
## Approfondimenti sui cluster
La tabella **Migliora approfondimenti** fa emergere i problemi e consiglia azioni correttive, accelerando il processo di convalida per l’aggiornamento a nuove versioni di Kubernetes. Amazon EKS esegue automaticamente la scansione dei cluster e li mette a confronto con un elenco di potenziali problemi di aggiornamento della versione Kubernetes. La tabella **Migliora approfondimenti** elenca i controlli approfonditi eseguiti da Amazon EKS su questo cluster, insieme ai relativi stati associati.
Amazon EKS gestisce e aggiorna periodicamente l’elenco dei controlli degli approfondimenti da eseguire sulla base delle valutazioni delle modifiche nel progetto Kubernetes e delle modifiche al servizio Amazon EKS legate alle nuove versioni. La console Amazon EKS aggiorna automaticamente lo stato di ciascun approfondimento, che può essere visualizzato nella colonna relativa all’ora dell’ultimo aggiornamento.
Per ulteriori informazioni, consulta [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md).
## Problemi di integrità dei nodi
L’agente di monitoraggio dei nodi Amazon EKS legge automaticamente i log dei nodi per rilevare problemi di integrità. Indipendentemente dall’impostazione di riparazione automatica, vengono segnalati tutti i problemi di integrità dei nodi in modo da poterli esaminare se necessario. Se un tipo di problema è elencato senza una descrizione, è possibile leggere la descrizione nel relativo elemento popover.
Quando si aggiorna la pagina, tutti i problemi risolti scompariranno dall’elenco. Se la riparazione automatica è abilitata, potresti visualizzare temporaneamente alcuni problemi di integrità che verranno risolti senza intervento da parte dell’utente. I problemi non supportati dalla riparazione automatica potrebbero richiedere un’azione manuale da parte dell’utente a seconda del tipo.
Per segnalare problemi di integrità dei nodi, il cluster deve utilizzare la modalità automatica Amazon EKS o disporre del componente aggiuntivo dell’agente di monitoraggio dei nodi. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).
## Funzionalità EKS
La sezione **Capacità** mostra lo stato e lo stato delle risorse EKS Capability nel cluster. Le notifiche sullo stato e sullo stato di entrambe le funzionalità e le relative risorse Kubernetes gestite nel cluster possono essere monitorate qui. Quando si aggiorna la pagina, tutti i problemi risolti scompariranno dall’elenco.
Per ulteriori informazioni, consulta [Lavorare con le risorse di capacità](working-with-capabilities.md).
# Monitora il traffico dei carichi di lavoro Kubernetes con Container Network Observability
Amazon EKS offre funzionalità avanzate di osservabilità della rete che forniscono informazioni più approfondite sull'ambiente di rete dei container. Queste funzionalità ti aiutano a comprendere, monitorare e risolvere meglio il tuo panorama di rete Kubernetes in. AWS Con una migliore osservabilità della rete di container, puoi sfruttare metriche granulari relative alla rete per un migliore rilevamento proattivo delle anomalie nel traffico del cluster, nei flussi cross-AZ e nei servizi. AWS Utilizzando queste metriche, puoi misurare le prestazioni del sistema e visualizzare le metriche sottostanti utilizzando il tuo stack di osservabilità preferito.
Inoltre, Amazon EKS ora fornisce visualizzazioni di monitoraggio della rete nella AWS console che accelerano e migliorano la risoluzione precisa dei problemi per un'analisi più rapida delle cause principali. Puoi anche sfruttare queste funzionalità visive per individuare i principali interlocutori e i flussi di rete che causano ritrasmissioni e timeout di ritrasmissione, eliminando i punti ciechi durante gli incidenti.
Queste funzionalità sono abilitate da [Amazon CloudWatch Network Flow Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor.html).
## Casi d’uso
### Misura le prestazioni della rete per rilevare anomalie
Diversi team si basano su uno stack di osservabilità che consente loro di misurare le prestazioni del sistema, visualizzare le metriche del sistema e allarmarsi nel caso in cui venga superata una soglia specifica. L'osservabilità della rete di container in EKS si allinea a questo aspetto, esponendo le metriche chiave del sistema che è possibile analizzare per ampliare l'osservabilità delle prestazioni di rete del sistema a livello di pod e nodo di lavoro.
### Sfrutta le visualizzazioni della console per una risoluzione dei problemi più precisa
In caso di allarme proveniente dal sistema di monitoraggio, potresti voler concentrarti sul cluster e sul carico di lavoro da cui ha avuto origine il problema. A tale scopo, puoi sfruttare le visualizzazioni della console EKS che restringono l'ambito di indagine a livello di cluster e accelerano la divulgazione dei flussi di rete responsabili della maggior parte delle ritrasmissioni, dei timeout di ritrasmissione e del volume di dati trasferiti.
### Tieni traccia dei migliori oratori nel tuo ambiente Amazon EKS
Molti team utilizzano EKS come base per le proprie piattaforme, rendendolo il punto focale dell'attività di rete di un ambiente applicativo. Utilizzando le funzionalità di monitoraggio della rete di questa funzionalità, puoi monitorare quali carichi di lavoro sono responsabili della maggior parte del traffico (misurato in base al volume di dati) all'interno del cluster AZs, oltre al traffico verso destinazioni esterne all'interno AWS (DynamoDB e S3) e oltre AWS il cloud (Internet o on-premise). Inoltre, è possibile monitorare le prestazioni di ciascuno di questi flussi in base alle ritrasmissioni, ai timeout di ritrasmissione e ai dati trasferiti.
## Funzionalità
1. Metriche delle prestazioni: questa funzionalità consente di acquisire le metriche di sistema relative alla rete per pod e nodi di lavoro direttamente dall'agente Network Flow Monitor (NFM) in esecuzione nel cluster EKS.
1. Mappa dei servizi: questa funzionalità visualizza dinamicamente l'intercomunicazione tra i carichi di lavoro nel cluster, consentendo di divulgare rapidamente le metriche chiave (ritrasmissioni - RT, timeout di ritrasmissione - RTO e dati trasferiti - DT) associate ai flussi di rete tra pod comunicanti.
1. Tabella dei flussi: con questa tabella, puoi monitorare i migliori oratori nei carichi di lavoro Kubernetes del tuo cluster da tre diverse angolazioni: visualizzazione del AWS servizio, visualizzazione del cluster e visualizzazione esterna. Per ogni vista, puoi vedere le ritrasmissioni, i timeout di ritrasmissione e i dati trasferiti tra il pod di origine e la sua destinazione.
+ AWS visualizzazione del servizio: mostra i migliori oratori ai AWS servizi (DynamoDB e S3)
+ Visualizzazione cluster: mostra i migliori oratori all'interno del cluster (da est ← a → ovest)
+ Vista esterna: mostra i migliori oratori alle destinazioni esterne al cluster all'esterno AWS
## Nozioni di base
Per iniziare, abilita Container Network Observability nella console EKS per un cluster nuovo o esistente. [Ciò automatizzerà la creazione delle dipendenze di Network Flow Monitor (NFM) (risorse [Scope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateScope.html) and Monitor).](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateMonitor.html) Inoltre, dovrai installare il componente aggiuntivo [Network Flow Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.html) Agent. [In alternativa, puoi installare queste dipendenze utilizzando [EKS APIs](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) (per il componente aggiuntivo)` AWS CLI`, [NFM APIs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-API-operations.html) o Infrastructure as Code (come Terraform).](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/networkflowmonitor_monitor) Una volta stabilite queste dipendenze, puoi configurare lo strumento di monitoraggio preferito per raccogliere le metriche delle prestazioni di rete per pod e nodi di lavoro dall'agente NFM. Per visualizzare l'attività di rete e le prestazioni dei carichi di lavoro, è possibile accedere alla console EKS nella scheda «Rete» del dashboard di osservabilità del cluster.
Quando si utilizza Network Flow Monitor in EKS, è possibile mantenere il flusso di lavoro e lo stack tecnologico di osservabilità esistenti, sfruttando al contempo una serie di funzionalità aggiuntive che consentono di comprendere e ottimizzare ulteriormente il livello di rete del proprio ambiente EKS. Puoi saperne di più sui prezzi di [Network Flow Monitor qui](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor.pricing.html).
## Prerequisiti e note importanti
1. Come accennato in precedenza, se abilitate Container Network Observability dalla console EKS, le dipendenze delle risorse NFM sottostanti (Scope e Monitor) verranno create automaticamente per vostro conto e sarete guidati attraverso il processo di installazione del componente aggiuntivo EKS per NFM.
1. Se desideri abilitare questa funzionalità utilizzando Infrastructure as Code (IaC) come Terraform, dovrai definire le seguenti dipendenze nel tuo IaC: NFM Scope, NFM Monitor, componente aggiuntivo EKS per NFM. [Inoltre, dovrai concedere le [autorizzazioni pertinenti](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) al componente aggiuntivo EKS utilizzando [Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) o IAM roles for service accounts (IRSA).](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
1. È necessario eseguire una versione minima di 1.1.0 per il componente aggiuntivo EKS dell'agente NFM.
1. È necessario utilizzare la versione 6.21.0 o successiva di [Terraform AWS Provider](https://github.com/hashicorp/terraform-provider-aws) per il supporto delle risorse di Network Flow Monitor.
### Autorizzazioni IAM richieste
#### Componente aggiuntivo EKS per l'agente NFM
Puoi utilizzare la [policy `CloudWatchNetworkFlowMonitorAgentPublishPolicy`AWS gestita](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) con Pod Identity. Questa policy contiene le autorizzazioni per l'agente NFM a inviare report di telemetria (metriche) a un endpoint Network Flow Monitor.
```
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"networkflowmonitor:Publish"
],
"Resource" : "*"
}
]
}
```
#### Osservabilità della rete dei container nella console EKS
Le seguenti autorizzazioni sono necessarie per abilitare la funzionalità e visualizzare la mappa dei servizi e la tabella dei flussi nella console.
```
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect": "Allow",
"Action": [
"networkflowmonitor:ListScopes",
"networkflowmonitor:ListMonitors",
"networkflowmonitor:GetScope",
"networkflowmonitor:GetMonitor",
"networkflowmonitor:CreateScope",
"networkflowmonitor:CreateMonitor",
"networkflowmonitor:TagResource",
"networkflowmonitor:StartQueryMonitorTopContributors",
"networkflowmonitor:StopQueryMonitorTopContributors",
"networkflowmonitor:GetQueryStatusMonitorTopContributors",
"networkflowmonitor:GetQueryResultsMonitorTopContributors"
],
"Resource": "*"
}
]
}
```
## Utilizzo di AWS CLI, API EKS e API NFM
```
#!/bin/bash
# Script to create required Network Flow Monitor resources
set -e
CLUSTER_NAME="my-eks-cluster"
CLUSTER_ARN="arn:aws:eks:{Region}:{Account}:cluster/{ClusterName}"
REGION="us-west-2"
AGENT_NAMESPACE="amazon-network-flow-monitor"
echo "Creating Network Flow Monitor resources..."
# Check if Network Flow Monitor agent is running in the cluster
echo "Checking for Network Flow Monitor agent in cluster..."
if kubectl get pods -n "$AGENT_NAMESPACE" --no-headers 2>/dev/null | grep -q "Running"; then
echo "Network Flow Monitor agent exists and is running in the cluster"
else
echo "Network Flow Monitor agent not found. Installing as EKS addon..."
aws eks create-addon \
--cluster-name "$CLUSTER_NAME" \
--addon-name "$AGENT_NAMESPACE" \
--region "$REGION"
echo "Network Flow Monitor addon installation initiated"
fi
# Get Account ID
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
echo "Cluster ARN: $CLUSTER_ARN"
echo "Account ID: $ACCOUNT_ID"
# Check for existing scope
echo "Checking for existing Network Flow Monitor Scope..."
EXISTING_SCOPE=$(aws networkflowmonitor list-scopes --region $REGION --query 'scopes[0].scopeArn' --output text 2>/dev/null || echo "None")
if [ "$EXISTING_SCOPE" != "None" ] && [ "$EXISTING_SCOPE" != "null" ]; then
echo "Using existing scope: $EXISTING_SCOPE"
SCOPE_ARN=$EXISTING_SCOPE
else
echo "Creating new Network Flow Monitor Scope..."
SCOPE_RESPONSE=$(aws networkflowmonitor create-scope \
--targets "[{\"targetIdentifier\":{\"targetId\":{\"accountId\":\"${ACCOUNT_ID}\"},\"targetType\":\"ACCOUNT\"},\"region\":\"${REGION}\"}]" \
--region $REGION \
--output json)
SCOPE_ARN=$(echo $SCOPE_RESPONSE | jq -r '.scopeArn')
echo "Scope created: $SCOPE_ARN"
fi
# Create Network Flow Monitor with EKS Cluster as local resource
echo "Creating Network Flow Monitor..."
MONITOR_RESPONSE=$(aws networkflowmonitor create-monitor \
--monitor-name "${CLUSTER_NAME}-monitor" \
--local-resources "type=AWS::EKS::Cluster,identifier=${CLUSTER_ARN}" \
--scope-arn "$SCOPE_ARN" \
--region $REGION \
--output json)
MONITOR_ARN=$(echo $MONITOR_RESPONSE | jq -r '.monitorArn')
echo "Monitor created: $MONITOR_ARN"
echo "Network Flow Monitor setup complete!"
echo "Monitor ARN: $MONITOR_ARN"
echo "Scope ARN: $SCOPE_ARN"
echo "Local Resource: AWS::EKS::Cluster (${CLUSTER_ARN})"
```
## Utilizzo dell'infrastruttura come codice (IaC)
### Terraform
Se utilizzi Terraform per gestire la tua infrastruttura AWS cloud, puoi includere le seguenti configurazioni di risorse per abilitare l'osservabilità della rete di contenitori per il tuo cluster.
#### Ambito NFM
```
data "aws_caller_identity" "current" {}
resource "aws_networkflowmonitor_scope" "example" {
target {
region = "us-east-1"
target_identifier {
target_type = "ACCOUNT"
target_id {
account_id = data.aws_caller_identity.current.account_id
}
}
}
tags = {
Name = "example"
}
}
```
#### Monitor NFM
```
resource "aws_networkflowmonitor_monitor" "example" {
monitor_name = "eks-cluster-name-monitor"
scope_arn = aws_networkflowmonitor_scope.example.scope_arn
local_resource {
type = "AWS::EKS::Cluster"
identifier = aws_eks_cluster.example.arn
}
remote_resource {
type = "AWS::Region"
identifier = "us-east-1" # this must be the same region that the cluster is in
}
tags = {
Name = "example"
}
}
```
#### Componente aggiuntivo EKS per NFM
```
resource "aws_eks_addon" "example" {
cluster_name = aws_eks_cluster.example.name
addon_name = "aws-network-flow-monitoring-agent"
}
```
## Come funziona?
### Metriche delle prestazioni
#### Parametri del sistema
Se utilizzi strumenti di terze parti (3P) per monitorare il tuo ambiente EKS (come Prometheus e Grafana), puoi acquisire le metriche di sistema supportate direttamente dall'agente Network Flow Monitor. Queste metriche possono essere inviate allo stack di monitoraggio per ampliare la misurazione delle prestazioni di rete del sistema a livello di pod e nodo di lavoro. Le metriche disponibili sono elencate nella tabella, in Metriche di sistema supportate.
![\[Illustrazione delle metriche del sistema di scraping\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/nfm-eks-metrics-workflow.png)
Per abilitare queste metriche, sovrascrivete le seguenti variabili di ambiente utilizzando le variabili di configurazione durante il processo di installazione (vedi: containers/ -advanced-configuration/): https://aws.amazon.com/blogs/ amazon-eks-add-ons
```
OPEN_METRICS:
Enable or disable open metrics. Disabled if not supplied
Type: String
Values: [“on”, “off”]
OPEN_METRICS_ADDRESS:
Listening IP address for open metrics endpoint. Defaults to 127.0.0.1 if not supplied
Type: String
OPEN_METRICS_PORT:
Listening port for open metrics endpoint. Defaults to 80 if not supplied
Type: Integer
Range: [0..65535]
```
#### Metriche del livello di flusso
Inoltre, Network Flow Monitor acquisisce i dati del flusso di rete insieme alle metriche del livello di flusso: ritrasmissioni, timeout di ritrasmissione e dati trasferiti. Questi dati vengono elaborati da Network Flow Monitor e visualizzati nella console EKS per far emergere il traffico nell'ambiente del cluster e il relativo rendimento in base a queste metriche del livello di flusso.
Il diagramma seguente illustra un flusso di lavoro in cui entrambi i tipi di metriche (sistema e livello di flusso) possono essere sfruttati per ottenere una maggiore intelligenza operativa.
![\[Illustrazione del flusso di lavoro con diverse metriche prestazionali\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/nfm-eks-metrics-types-workflow.png)
1. Il team della piattaforma può raccogliere e visualizzare le metriche di sistema nel proprio stack di monitoraggio. Una volta attivati gli avvisi, possono rilevare anomalie di rete o problemi che influiscono sui pod o sui nodi di lavoro utilizzando le metriche di sistema fornite dall'agente NFM.
1. Come passaggio successivo, i team della piattaforma possono sfruttare le visualizzazioni native della console EKS per restringere ulteriormente l'ambito delle indagini e accelerare la risoluzione dei problemi in base alle rappresentazioni dei flussi e alle metriche associate.
Nota importante: l'acquisizione delle metriche di sistema dall'agente NFM e il processo con cui l'agente NFM invia le metriche a livello di flusso al backend NFM sono processi indipendenti.
##### Metriche di sistema supportate
Nota importante: le metriche di sistema vengono esportate in formato. [OpenMetrics](https://openmetrics.io/)
| Nome parametro | Tipo | Dimensioni | Description |
| --- | --- | --- | --- |
| ingress\$1flow | Gauge | instance\$1id, iface, pod, namespace, nodo | Conteggio del flusso TCP in ingresso () TcpPassiveOpens |
| Flusso\$1uscita | Gauge | instance\$1id, iface, pod, namespace, node | Conteggio del flusso TCP in uscita () TcpActiveOpens |
| pacchetti\$1in ingresso | Gauge | instance\$1id, iface, pod, namespace, nodo | Numero di pacchetti in ingresso (delta) |
| pacchetti\$1in uscita | Gauge | instance\$1id, iface, pod, namespace, node | Numero di pacchetti in uscita (delta) |
| ingress\$1bytes | Gauge | instance\$1id, iface, pod, namespace, nodo | Conteggio dei byte in ingresso (delta) |
| egress\$1bytes | Gauge | instance\$1id, iface, pod, namespace, nodo | Conteggio dei byte in uscita (delta) |
| bw\$1in\$1allowance\$1exceeded | Gauge | instance\$1id, eni, nodo | Pacchetti queued/dropped dovuti al limite di larghezza di banda in entrata |
| bw\$1out\$1allowance\$1exceeded | Gauge | instance\$1id, eni, nodo | Pacchetti queued/dropped dovuti al limite di larghezza di banda in uscita |
| pps\$1allowance\$1exceeded | Gauge | instance\$1id, eni, nodo | Pacchetti queued/dropped dovuti al limite PPS bidirezionale |
| conntrack\$1allowance\$1exceeded | Gauge | instance\$1id, eni, nodo | Pacchetti persi a causa del limite di tracciamento della connessione |
| linklocal\$1allowance\$1exceeded | Gauge | instance\$1id, eni, nodo | I pacchetti sono caduti a causa del limite PPS del servizio proxy locale |
##### Metriche del livello di flusso supportate
| Nome parametro | Tipo | Description |
| --- | --- | --- |
| Ritrasmissioni TCP | Contatore | Numero di volte in cui un mittente invia nuovamente un pacchetto perso o danneggiato durante la trasmissione. |
| Timeout di ritrasmissione TCP | Contatore | Numero di volte in cui un mittente ha avviato un periodo di attesa per determinare se un pacchetto è andato perso durante il transito. |
| Dati (byte) trasferiti | Contatore | Volume di dati trasferiti tra un'origine e una destinazione per un determinato flusso. |
### Mappa dei servizi e tabella dei flussi
![\[Illustrazione di come NFM funziona con EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/nfm-eks-workflow.png)
1. Una volta installato, l'agente Network Flow Monitor viene eseguito DaemonSet su ogni nodo di lavoro e raccoglie i primi 500 flussi di rete (in base al volume di dati trasferiti) ogni 30 secondi.
1. Questi flussi di rete sono suddivisi nelle seguenti categorie: Intra AZ, Inter AZ, EC2 → S3, → EC2 DynamoDB (DDB) e Unclassified. A ogni flusso sono associate 3 metriche: ritrasmissioni, timeout di ritrasmissione e dati trasferiti (in byte).
+ Intra AZ: flussi di rete tra pod nella stessa AZ
+ Inter AZ: la rete scorre tra pod diversi AZs
+ EC2 → S3: la rete scorre dai pod a S3
+ EC2 → DDB: flussi di rete dai pod al DDB
+ Non classificato: la rete scorre dai pod a Internet o in locale
1. I flussi di rete dell'API Network Flow Monitor Top Contributors vengono utilizzati per potenziare le seguenti esperienze nella console EKS:
+ Mappa dei servizi: visualizzazione dei flussi di rete all'interno del cluster (Intra AZ e Inter AZ).
+ Tabella dei flussi: presentazione in tabella dei flussi di rete all'interno del cluster (Intra AZ e Inter AZ), dai pod ai AWS servizi (EC2 → S3 e EC2 → DDB) e dai pod alle destinazioni esterne (non classificate).
I flussi di rete estratti dall'API Top Contributors hanno un ambito temporale di 1 ora e possono includere fino a 500 flussi per categoria. Per quanto riguarda la mappa dei servizi, ciò significa che è possibile reperire e presentare fino a 1000 flussi dalle categorie di flusso Intra AZ e Inter AZ in un intervallo di tempo di 1 ora. Per quanto riguarda la tabella dei flussi, ciò significa che è possibile reperire e presentare fino a 3000 flussi di rete da tutte le 6 categorie di flussi di rete in un intervallo di tempo di 2 ore.
#### Esempio: mappa dei servizi
*Visualizzazione della distribuzione*
![\[Illustrazione della mappa dei servizi con app di e-commerce nella visualizzazione di distribuzione\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/ecommerce-deployment.png)
*Vista Pod*
![\[Illustrazione della mappa dei servizi con app di e-commerce in visualizzazione pod\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/ecommerce-pod.png)
*Vista di distribuzione*
![\[Illustrazione della mappa dei servizi con l'app della galleria fotografica nella visualizzazione di distribuzione\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/photo-gallery-deployment.png)
*Vista Pod*
![\[Illustrazione della mappa dei servizi con app per la galleria fotografica in modalità pod\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/photo-gallery-pod.png)
#### Esempio: tabella di flusso
* AWS visualizzazione del servizio*
![\[Illustrazione della visualizzazione della tabella di flusso\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/aws-service-view.png)
*Vista a grappolo*
![\[Illustrazione della tabella di flusso nella vista cluster\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/cluster-view.png)
## Considerazioni e limitazioni
+ L'osservabilità della rete di contenitori in EKS è disponibile solo nelle regioni in cui [è supportato Network Flow Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-Regions.html).
+ Le metriche di sistema supportate sono in OpenMetrics formato e possono essere estratte direttamente dall'agente Network Flow Monitor (NFM).
+ Per abilitare l'osservabilità della rete dei container in EKS utilizzando Infrastructure as Code (IaC) come [Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/networkflowmonitor_monitor), è necessario definire e creare queste dipendenze nelle configurazioni: ambito NFM, monitor NFM e agente NFM.
+ Network Flow Monitor supporta fino a circa 5 milioni di flussi al minuto. Si tratta di circa 5.000 EC2 istanze (nodi di lavoro EKS) con l'agente Network Flow Monitor installato. L'installazione di agenti su più di 5000 istanze può influire sulle prestazioni di monitoraggio fino a quando non sarà disponibile capacità aggiuntiva.
+ È necessario eseguire una versione minima di 1.1.0 per il componente aggiuntivo EKS dell'agente NFM.
+ È necessario utilizzare la versione 6.21.0 o successiva di [Terraform AWS Provider](https://github.com/hashicorp/terraform-provider-aws) per il supporto delle risorse di Network Flow Monitor.
+ Per arricchire i flussi di rete con i metadati dei pod, i pod devono funzionare nel proprio spazio dei nomi di rete isolato, non nello spazio dei nomi della rete host.
# 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.
# Monitora i dati del cluster con Amazon CloudWatch
Amazon CloudWatch è un servizio di monitoraggio che raccoglie metriche e log dalle tue risorse cloud. CloudWatch fornisce gratuitamente alcuni parametri di base di Amazon EKS quando si utilizza un nuovo cluster di versione `1.28` o superiore. Tuttavia, quando si utilizza CloudWatch Observability Operator come componente aggiuntivo di Amazon EKS, è possibile ottenere funzionalità di osservabilità avanzate.
## Metriche di base in Amazon CloudWatch
Per i cluster con versione Kubernetes `1.28` e successive, ottieni metriche CloudWatch vendute gratuitamente nel namespace. `AWS/EKS` La seguente tabella fornisce un elenco delle metriche di base disponibili per le versioni supportate. Ogni metrica presente nell’elenco ha una frequenza di un minuto.
| Nome parametro | Description |
| --- | --- |
| `apiserver_flowcontrol_current_executing_seats` | Il numero di postazioni attualmente in uso per l'esecuzione delle richieste API. [L'allocazione dei posti è determinata dalla configurazione priority\$1level e flow\$1schema nella funzionalità Priority and Fairness dell'API Kubernetes.](https://kubernetes.io/docs/concepts/cluster-administration/flow-control/) **Unità:** numero **Statistiche valide:** somma |
| `scheduler_schedule_attempts_total` | Il numero totale di tentativi da parte pianificatore di pianificare i pod nel cluster per un determinato periodo. Questa metrica aiuta a monitorare il carico di lavoro del pianificatore e può indicare la pressione della pianificazione o potenziali problemi con il posizionamento dei pod. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_schedule_attempts_SCHEDULED` | Il numero di tentativi riusciti da parte pianificatore di pianificare i pod sui nodi nel cluster per un determinato periodo. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_schedule_attempts_UNSCHEDULABLE` | Il numero di tentativi di pianificazione dei pod che non è stato possibile pianificare per un determinato periodo a causa di vincoli validi, quali CPU o memoria insufficienti su un nodo. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_schedule_attempts_ERROR` | Il numero di tentativi di pianificazione dei pod che non sono riusciti in un determinato periodo a causa di un problema interno del pianificatore stesso, ad esempio problemi di connettività del server API. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_pending_pods` | Il numero totale di pod in sospeso che il pianificatore del cluster deve pianificare per un determinato periodo. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_pending_pods_ACTIVEQ` | Il numero di pod in sospeso in ActiveQ che attendono di essere pianificati nel cluster in un determinato periodo. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_pending_pods_UNSCHEDULABLE` | Il numero di pod in sospeso che il pianificatore ha tentato di pianificare senza successo e che vengono mantenuti in uno stato non pianificabile per un nuovo tentativo. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_pending_pods_BACKOFF` | Il numero di Pod in sospeso in `backoffQ` in uno stato di backoff che sono in attesa della scadenza del periodo di backoff. **Unità:** numero **Statistiche valide:** somma |
| `scheduler_pending_pods_GATED` | Il numero di pod in sospeso che sono attualmente in attesa in uno stato chiuso, in quanto non possono essere pianificati finché non soddisfano le condizioni richieste. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_request_total` | Il numero di richieste HTTP inviate su tutti i server API del cluster. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_request_total_4XX` | Il numero di richieste HTTP effettuate a tutti i server API del cluster che hanno generato codici di stato `4XX` (errore client). **Unità:** numero **Statistiche valide:** somma |
| `apiserver_request_total_429` | Il numero di richieste HTTP inviate a tutti i server API del cluster che hanno generato il codice di stato `429`, che si verifica quando i client superano le soglie di limitazione della velocità. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_request_total_5XX` | Il numero di richieste HTTP effettuate a tutti i server API del cluster che hanno generato codici di stato `5XX` (errore server). **Unità:** numero **Statistiche valide:** somma |
| `apiserver_request_total_LIST_PODS` | Il numero di richieste Pod `LIST` inviate a tutti i server API del cluster. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_request_duration_seconds_PUT_P99` | Il 99° percentile della latenza per le richieste `PUT` calcolato da tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste `PUT`. **Unità: secondi** **Statistiche valide:** media |
| `apiserver_request_duration_seconds_PATCH_P99` | Il 99° percentile della latenza per le richieste `PATCH` calcolato da tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste `PATCH`. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_request_duration_seconds_POST_P99` | Il 99° percentile della latenza per le richieste `POST` calcolato da tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste `POST`. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_request_duration_seconds_GET_P99` | Il 99° percentile della latenza per le richieste `GET` calcolato da tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste `GET`. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_request_duration_seconds_LIST_P99` | Il 99° percentile della latenza per le richieste `LIST` calcolato da tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste `LIST`. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_request_duration_seconds_DELETE_P99` | Il 99° percentile della latenza per le richieste `DELETE` calcolato da tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste `DELETE`. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_current_inflight_requests_MUTATING` | Il numero di richieste di mutazione (`POST`, `PUT`, `DELETE`, `PATCH`) attualmente in elaborazione su tutti i server API del cluster. Questa metrica rappresenta le richieste in corso per le quali l’elaborazione non è ancora stata completata. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_current_inflight_requests_READONLY` | Il numero di richieste di sola lettura (`GET`, `LIST`) attualmente in elaborazione su tutti i server API del cluster. Questa metrica rappresenta le richieste in corso per le quali l’elaborazione non è ancora stata completata. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_request_total` | Il numero di richieste webhook di ammissione inviate su tutti i server API nel cluster. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_request_total_ADMIT` | Il numero di richieste di mutazione webhook di ammissione inviate su tutti i server API nel cluster. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_request_total_VALIDATING` | Il numero di richieste webhook di ammissione di convalida inviate su tutti i server API nel cluster. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_rejection_count` | Il numero di richieste webhook di ammissione inviate su tutti i server API del cluster che sono state rifiutate. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_rejection_count_ADMIT` | Il numero di richieste di mutazione webhook di ammissione inviate su tutti i server API del cluster che sono state rifiutate. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_rejection_count_VALIDATING` | Il numero di richieste webhook di ammissione di convalida inviate su tutti i server API del cluster che sono state rifiutate. **Unità:** numero **Statistiche valide:** somma |
| `apiserver_admission_webhook_admission_duration_seconds` | Il 99° percentile della latenza per le richieste webhook di ammissione di terze parti calcolato sulla base di tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste webhook di ammissione di terze parti. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_admission_webhook_admission_duration_seconds_ADMIT_P99` | Il 99° percentile della latenza per le richieste webhook di mutazione di ammissione di terze parti calcolato sulla base di tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste webhook di mutazione di ammissione di terze parti. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_admission_webhook_admission_duration_seconds_VALIDATING_P99` | Il 99° percentile della latenza per le richieste webhook di validazione di ammissione di terze parti calcolato sulla base di tutte le richieste su tutti i server API nel cluster. Rappresenta il tempo di risposta al di sotto del quale viene completato il 99% di tutte le richieste webhook di validazione di ammissione di terze parti. **Unità:** secondi **Statistiche valide:** media |
| `apiserver_storage_size_bytes` | La dimensione fisica in byte del file del database di storage etcd usato dai server API del cluster. Questa metrica rappresenta lo spazio su disco effettivo allocato per lo storage. **Unità:** byte **Statistiche valide:** massimo |
## Operatore di CloudWatch osservabilità di Amazon
Amazon CloudWatch Observability raccoglie log, parametri e dati di tracciamento in tempo reale. Li invia ad [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) e [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html). Puoi installare questo componente aggiuntivo per abilitare sia CloudWatch Application Signals che CloudWatch Container Insights con una migliore osservabilità per Amazon EKS. In questo modo puoi monitorare lo stato e le prestazioni dell'infrastruttura e delle applicazioni containerizzate. Amazon CloudWatch Observability Operator è progettato per installare e configurare i componenti necessari.
Amazon EKS supporta CloudWatch Observability Operator come [componente aggiuntivo di Amazon EKS](eks-add-ons.md). Il componente aggiuntivo consente l’uso di Container Insights sui nodi di lavoro Linux e Windows nel cluster. Per abilitare Container Insights su Windows, la versione del componente aggiuntivo Amazon EKS deve essere `1.5.0` o superiore. Attualmente, CloudWatch Application Signals non è supportato su Amazon EKS Windows.
Gli argomenti seguenti descrivono come iniziare a utilizzare CloudWatch Observability Operator per il tuo cluster Amazon EKS.
+ *Per istruzioni sull'installazione di questo componente aggiuntivo, consulta [Installa l' CloudWatch agente con il componente aggiuntivo Amazon CloudWatch Observability EKS o il grafico Helm nella](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) Amazon User Guide. CloudWatch *
+ Per ulteriori informazioni su CloudWatch Application Signals, consulta [Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) nella *Amazon CloudWatch User Guide*.
+ Per ulteriori informazioni su Container Insights, consulta [Using Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) nella *Amazon CloudWatch User Guide*.
# Invia i registri del piano di controllo ai CloudWatch registri
La registrazione del piano di controllo di Amazon EKS fornisce log di audit e diagnostica direttamente dal piano di controllo di Amazon CloudWatch EKS ai log del tuo account. Questi log consentono di semplificare la protezione e l'esecuzione dei cluster. Puoi selezionare i tipi di log esatti di cui hai bisogno e i log vengono inviati come flussi di log a un gruppo per ogni cluster Amazon EKS in cui opera. CloudWatch Puoi utilizzare i filtri di CloudWatch abbonamento per eseguire analisi in tempo reale sui log o per inoltrarli ad altri servizi (i log saranno codificati in Base64 e compressi con il formato gzip). Per ulteriori informazioni, consulta [Amazon CloudWatch logging.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Nota**
I log del piano di controllo di Amazon EKS vengono consegnati a CloudWatch Logs in pochi minuti. Tuttavia, la consegna dei log è la soluzione migliore.
É possibile iniziare a utilizzare il piano di controllo Amazon EKS scegliendo quali tipi di log che si desidera abilitare per ogni cluster Amazon EKS nuovo o esistente. Puoi abilitare o disabilitare ogni tipo di registro per cluster utilizzando la Console di gestione AWS AWS CLI (versione `1.16.139` o successiva) o tramite l'API Amazon EKS. Se abilitato, i log vengono inviati automaticamente dal cluster Amazon CloudWatch EKS ai log nello stesso account.
Quando si utilizza la registrazione del piano di controllo Amazon EKS, viene addebitato il prezzo Amazon EKS standard per ogni cluster eseguito. Ti vengono addebitati i costi standard di inserimento e archiviazione dei dati di CloudWatch Logs per tutti i log inviati a Logs dai tuoi cluster. CloudWatch Ti viene inoltre addebitato il costo di tutte AWS le risorse, come le istanze Amazon EC2 o i volumi Amazon EBS, di cui effettui il provisioning come parte del cluster.
Sono disponibili i seguenti tipi di registro del piano di controllo del cluster. Ogni tipo di registro corrisponde a un componente del piano di controllo Kubernetes. Per ulteriori informazioni su questi componenti, consultare [Kubernetes Components](https://kubernetes.io/docs/concepts/overview/components/) nella documentazione Kubernetes.
**Server API`api` (**)
Il server API del cluster è il componente del piano di controllo (control-plane) che espone l’API Kubernetes. Se abiliti i log del server API quando avvii il cluster o poco dopo, questi log includono i flag del server API utilizzati per l'avvio del server API. Per ulteriori informazioni, consulta [kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) e la [ policy di audit](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh#L1129-L1255) nella documentazione Kubernetes.
**Audit`audit` (**)
I log di audit Kubernetes forniscono un record dei singoli utenti, amministratori o componenti di sistema che interessano il cluster. Per ulteriori informazioni, consultare [Auditing](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) nella documentazione Kubernetes.
**Autenticatore`authenticator` (**)
I log dell'autenticatore sono univoci per Amazon EKS. Questi registri rappresentano il componente del piano di controllo utilizzato da Amazon EKS per l'autenticazione [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) Kubernetes utilizzando credenziali IAM. Per ulteriori informazioni, consulta [Organizzazione e monitoraggio delle risorse del cluster](eks-managing.md).
**Gestore controller`controllerManager` (**)
Il gestore controller gestisce i loop di controllo di base inviati con Kubernetes. Per ulteriori informazioni, consultare [kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) nella documentazione Kubernetes.
**Pianificatore`scheduler` (**)
Il componente pianificatore gestisce quando e dove eseguire i pod nel cluster. Per ulteriori informazioni, consultare [kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) nella documentazione Kubernetes.
## Abilitare o disabilitare i log del piano di controllo (control-plane)
Per impostazione predefinita, i log del piano di controllo del cluster non vengono inviati a Logs. CloudWatch È necessario abilitare ogni tipo di registro singolarmente per inviare i log per il cluster. CloudWatch Le tariffe di inserimento dei log, archiviazione, archiviazione e scansione dei dati si applicano ai log del piano di controllo abilitati. Per ulteriori informazioni, consultare [Prezzi di CloudWatch ](https://aws.amazon.com/cloudwatch/pricing/).
Per aggiornare la configurazione di registrazione del piano di controllo (control-plane), Amazon EKS richiede fino a cinque indirizzi IP disponibili in ciascuna sottorete. Quando abiliti un tipo di registro, i log vengono inviati con un livello di dettaglio dei log di `2`.
È possibile abilitare o disabilitare i log del piano di controllo (control-plane) con la [Console di gestione AWS](#control-plane-console) o [AWS CLI](#control-plane-cli).
### Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegliere il nome del cluster per visualizzare le informazioni sul cluster.
1. Scegli la scheda **Osservabilità**.
1. Nella sezione **Registrazione del piano di controllo**, scegli **Gestisci registrazione**.
1. Per ogni singolo tipo di log, scegli se il tipo di log deve essere attivato o disattivato. Per impostazione predefinita, i tipi di log sono disattivati.
1. Scegliere **Salva le modifiche** per terminare.
### AWS CLI
1. Controlla la tua versione AWS CLI con il seguente comando.
```
aws --version
```
Se la tua versione AWS CLI è precedente alla`1.16.139`, devi prima eseguire l'aggiornamento alla versione più recente. Per installare o aggiornare la AWS CLI, consulta [Installazione dell'interfaccia a riga di AWS comando nella Guida](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) per l'*utente dell'interfaccia a riga di AWS comando*.
1. Aggiorna la configurazione di esportazione dei log del piano di controllo del cluster con il seguente comando AWS CLI. Sostituisci *my-cluster* con il nome del cluster e specifica i valori desiderati per l'accesso all'endpoint.
**Nota**
Il comando seguente invia tutti i tipi di log disponibili a CloudWatch Logs.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
```
Di seguito viene riportato un output di esempio.
```
{
"update": {
"id": "883405c8-65c6-4758-8cee-2a7c1340a6d9",
"status": "InProgress",
"type": "LoggingUpdate",
"params": [
{
"type": "ClusterLogging",
"value": "{\"clusterLogging\":[{\"types\":[\"api\",\"audit\",\"authenticator\",\"controllerManager\",\"scheduler\"],\"enabled\":true}]}"
}
],
"createdAt": 1553271814.684,
"errors": []
}
}
```
1. Monitorare lo stato di aggiornamento della configurazione del log con il comando seguente utilizzando il nome del cluster e l'ID di aggiornamento restituiti dal comando precedente. L'aggiornamento è completo quando lo stato viene visualizzato come `Successful`.
```
aws eks describe-update \
--region region-code\
--name my-cluster \
--update-id 883405c8-65c6-4758-8cee-2a7c1340a6d9
```
Di seguito viene riportato un output di esempio.
```
{
"update": {
"id": "883405c8-65c6-4758-8cee-2a7c1340a6d9",
"status": "Successful",
"type": "LoggingUpdate",
"params": [
{
"type": "ClusterLogging",
"value": "{\"clusterLogging\":[{\"types\":[\"api\",\"audit\",\"authenticator\",\"controllerManager\",\"scheduler\"],\"enabled\":true}]}"
}
],
"createdAt": 1553271814.684,
"errors": []
}
}
```
## Visualizzare i log del piano di controllo (control-plane) del cluster
Dopo aver abilitato uno qualsiasi dei tipi di log del piano di controllo per il tuo cluster Amazon EKS, puoi visualizzarli sulla CloudWatch console.
Per ulteriori informazioni sulla visualizzazione, l'analisi e la gestione dei log in CloudWatch, consulta la [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/) User Guide.
1. Apri la [CloudWatch console](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks). Questo link apre la console e mostra i gruppi di log disponibili correnti e li filtra con il prefisso `/aws/eks`.
1. Scegliere il cluster per il quale si intende visualizzare i log. Il formato del nome del gruppo di log è `/aws/eks/my-cluster/cluster`.
1. Scegliere il flusso di log da visualizzare. L'elenco seguente descrive il formato del nome del flusso di log per ogni tipo di registro.
**Nota**
Al crescere della quantità di dati del flusso di log, i nomi del flusso di log vengono ruotati. Quando esistono più flussi di log per un determinato tipo di log, puoi visualizzare l'ultimo flusso di log cercando il nome del flusso di log con **Last event time** (Ora ultimo evento) più recente.
+ **Log del componente server API Kubernetes (`api`)** – `kube-apiserver-1234567890abcdef01234567890abcde `
+ **Audit (`audit`)** – `kube-apiserver-audit-1234567890abcdef01234567890abcde `
+ **Autenticatore (`authenticator`)** – `authenticator-1234567890abcdef01234567890abcde `
+ **Gestore controller (`controllerManager`)** – `kube-controller-manager-1234567890abcdef01234567890abcde `
+ **Pianificatore (`scheduler`)** – `kube-scheduler-1234567890abcdef01234567890abcde `
1. Esamina gli eventi del flusso di log.
Ad esempio, dovresti vedere i flag iniziali del server API del cluster quando visualizzi la parte iniziale di `kube-apiserver-1234567890abcdef01234567890abcde `.
**Nota**
Se i log del server API non vengono visualizzati all’inizio del flusso di log, è probabile che il file di log del server API sia stato ruotato sul server prima di abilitare la registrazione di log del server API sul server. I file di log che vengono ruotati prima dell'attivazione della registrazione del server API non possono essere esportati in. CloudWatch
Tuttavia, è possibile creare un nuovo cluster con la stessa versione di Kubernetes e abilitare la registrazione del server API quando si crea il cluster. I cluster con la stessa versione della piattaforma hanno gli stessi flag abilitati, quindi i flag devono corrispondere a quelli del nuovo cluster. Al termine della visualizzazione dei flag relativi al nuovo cluster CloudWatch, è possibile eliminare il nuovo cluster.
# Registra le chiamate API come eventi AWS CloudTrail
Amazon EKS è integrato con AWS CloudTrail. CloudTrail è un servizio che fornisce un registro delle operazioni eseguite da un utente, un ruolo o un servizio AWS in Amazon EKS. CloudTrail acquisisce tutte le chiamate API per Amazon EKS come eventi. Questi includono le chiamate della console Amazon EKS e le chiamate del codice alle operazioni API Amazon EKS.
Se crei un percorso, puoi abilitare la distribuzione continua di eventi CloudTrail in un bucket Amazon S3, inclusi gli eventi per Amazon EKS. Se non configuri un trail, puoi comunque visualizzare gli eventi più recenti nella console di CloudTrail in **Cronologia eventi**. Utilizzando le informazioni raccolte da CloudTrail, è possibile determinare diversi dettagli su una richiesta. Ad esempio, puoi determinare quando è stata effettuata una richiesta ad Amazon EKS, l’indirizzo IP da cui è stata eseguita e l’autore.
Per ulteriori informazioni su CloudTrail, consulta [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
**Topics**
+ [Visualizzazione dei riferimenti utili per AWS CloudTrail](service-name-info-in-cloudtrail.md)
+ [Analisi delle voci del file di log AWS CloudTrail](understanding-service-name-entries.md)
+ [Visualizzare i parametri per i gruppi Amazon EC2 Auto Scaling](enable-asg-metrics.md)
# Visualizzazione dei riferimenti utili per AWS CloudTrail
Al momento della creazione del tuo account AWS, CloudTrail è abilitato sul tuo account AWS. Quando si verifica un'attività in Amazon EKS, questa viene registrata in un evento CloudTrail insieme ad altri eventi di servizio AWS nella **Cronologia eventi**. È possibile visualizzare, cercare e scaricare gli eventi recenti nell'account AWS. Per ulteriori informazioni, consulta [Visualizzazione di eventi mediante la cronologia eventi di CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Per una registrazione continua degli eventi nell'account AWS, inclusi gli eventi per Amazon EKS, creare un percorso. Un *percorso* consente a CloudTrail di distribuire i file di log in un bucket Amazon S3. Per impostazione predefinita, quando si crea un trail nella console, il trail sarà valido in tutte le Regioni AWS. Il percorso registra gli eventi da tutte le regioni AWSnella partizione AWS e distribuisce i file di log nel bucket Simple Storage Service (Amazon S3) specificato. Inoltre, è possibile configurare altri servizi AWS per analizzare con maggiore dettaglio e utilizzare i dati evento raccolti nei log CloudTrail. Per ulteriori informazioni, consulta le risorse seguenti.
+ [Panoramica della creazione di un percorso](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [Servizi e integrazioni CloudTrail supportati](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configurazione delle notifiche Amazon SNS per CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Ricezione di file di registro CloudTrail da più Regioni](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) e [Ricezione di file di log CloudTrail da più account](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Tutte le operazioni Amazon EKS vengono registrate da CloudTrail e sono documentate nella [Documentazione di riferimento delle API di Amazon EKS](https://docs.aws.amazon.com/eks/latest/APIReference/). Ad esempio, le chiamate alle sezioni [CreateCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), [ListClusters](https://docs.aws.amazon.com/eks/latest/APIReference/API_ListClusters.html) e [DeleteCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DeleteCluster.html) generano voci nei file di log CloudTrail.
Ogni evento o voce di log include informazioni sul tipo di identità IAM che ha effettuato la richiesta e sulle credenziali utilizzate. Se sono state utilizzate credenziali temporanee, la voce mostra il modo in cui tali credenziali sono state ottenute.
Per ulteriori informazioni, consulta [Elemento CloudTrail userIdentity](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
# Analisi delle voci del file di log AWS CloudTrail
Un trail è una configurazione che consente la distribuzione di eventi come i file di log in un bucket Amazon S3 specificato. I file di log di CloudTrail possono contenere una o più voci di log. Un evento rappresenta una singola richiesta da un'origine e include informazioni sull'operazione richiesta, come data e ora dell'operazione e i parametri della richiesta. I file di log CloudTrail non sono una traccia di stack ordinata delle chiamate API pubbliche e di conseguenza non devono apparire in base a un ordine specifico.
L'esempio seguente mostra una voce di registro di CloudTrail che illustra l'operazione [https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html).
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "AKIAIOSFODNN7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/username",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "username"
},
"eventTime": "2018-05-28T19:16:43Z",
"eventSource": "eks.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "region-code",
"sourceIPAddress": "205.251.233.178",
"userAgent": "PostmanRuntime/6.4.0",
"requestParameters": {
"resourcesVpcConfig": {
"subnetIds": [
"subnet-a670c2df",
"subnet-4f8c5004"
]
},
"roleArn": "arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonEKS-CAC1G1VH3ZKZ",
"clusterName": "test"
},
"responseElements": {
"cluster": {
"clusterName": "test",
"status": "CREATING",
"createdAt": 1527535003.208,
"certificateAuthority": {},
"arn": "arn:aws:eks:region-code:111122223333:cluster/test",
"roleArn": "arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonEKS-CAC1G1VH3ZKZ",
"version": "1.10",
"resourcesVpcConfig": {
"securityGroupIds": [],
"vpcId": "vpc-21277358",
"subnetIds": [
"subnet-a670c2df",
"subnet-4f8c5004"
]
}
}
},
"requestID": "a7a0735d-62ab-11e8-9f79-81ce5b2b7d37",
"eventID": "eab22523-174a-499c-9dd6-91e7be3ff8e3",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
## Voci di registro per ruoli collegati ai servizi Amazon EKS
I ruoli collegati ai servizi Amazon EKS effettuano chiamate API alle risorse AWS. Verranno visualizzate le voci di registro CloudTrail con `username: AWSServiceRoleForAmazonEKS` e `username: AWSServiceRoleForAmazonEKSNodegroup` per chiamate effettuate dai ruoli collegati ai servizi Amazon EKS. Per ulteriori informazioni su Amazon EKS e sui ruoli collegati ai servizi, consultare [Utilizzo di ruoli collegati ai servizi per Amazon EKS](using-service-linked-roles.md).
Nell’esempio seguente è illustrata una voce di log CloudTrail che illustra un’operazione [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) eseguita dal ruolo collegato ai servizi `AWSServiceRoleForAmazonEKSNodegroup`, annotato in `sessionContext`.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA3WHGPEZ7SJ2CW55C5:EKS",
"arn": "arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForAmazonEKSNodegroup/EKS",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA3WHGPEZ7SJ2CW55C5",
"arn": "arn:aws:iam::111122223333:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup",
"accountId": "111122223333",
"userName": "AWSServiceRoleForAmazonEKSNodegroup"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2020-02-26T00:56:33Z"
}
},
"invokedBy": "eks-nodegroup.amazonaws.com"
},
"eventTime": "2020-02-26T00:56:34Z",
"eventSource": "iam.amazonaws.com",
"eventName": "DeleteInstanceProfile",
"awsRegion": "region-code",
"sourceIPAddress": "eks-nodegroup.amazonaws.com",
"userAgent": "eks-nodegroup.amazonaws.com",
"requestParameters": {
"instanceProfileName": "eks-11111111-2222-3333-4444-abcdef123456"
},
"responseElements": null,
"requestID": "11111111-2222-3333-4444-abcdef123456",
"eventID": "11111111-2222-3333-4444-abcdef123456",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
# Visualizzare i parametri per i gruppi Amazon EC2 Auto Scaling
Nei gruppi di nodi gestiti da Amazon EKS i parametri dei gruppi di Amazon EC2 Auto Scaling sono abilitati per impostazione predefinita senza costi aggiuntivi. Il gruppo Auto Scaling invia dati campionati ad Amazon CloudWatch ogni minuto. Questi parametri possono essere perfezionati in base al nome dei gruppi Auto Scaling. Con questi parametri, si ottiene una visibilità quasi continua nella cronologia del gruppo Auto Scaling che alimenta i gruppi di nodi gestiti, ad esempio le modifiche delle dimensioni del gruppo nel tempo. I parametri di un gruppo Auto Scaling sono disponibili nella console di [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) o in quella di Auto Scaling. Per ulteriori informazioni, consultare la pagina [Monitor CloudWatch metrics for your Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html).
Abilitando la raccolta dei parametri di un gruppo Auto Scaling, sarà possibile monitorare la scalabilità dei gruppi di nodi gestiti. I parametri di un gruppo con scalabilità automatica riportano la dimensione minima, massima e desiderata di un gruppo con scalabilità automatica. Puoi creare un allarme se il numero di nodi in un gruppo di nodi scende al di sotto della dimensione minima, fatto che indicherebbe un gruppo di nodi non integro. Il monitoraggio delle dimensioni dei gruppi di nodi è utile anche per regolare il numero massimo in modo che il piano dati non esaurisca la capacità.
Se si preferisce non raccogliere questi parametri, è possibile disabilitarli tutti o solo alcuni. Ad esempio, è possibile farlo per evitare il rumore nelle dashboard CloudWatch. Per ulteriori informazioni, consultare la pagina [Amazon CloudWatch metrics for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html).
# Invio di dati metrici e di tracciamento con l’operatore ADOT
Amazon EKS supporta ora l’utilizzo di Console di gestione AWS, AWS CLI e l’API di Amazon EKS per installare e gestire l’operatore [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/). Ciò rende più semplice la possibilità per le applicazioni in esecuzione su Amazon EKS di inviare parametri e dati di traccia a vari servizi di monitoraggio, ad esempio [Amazon CloudWatch](https://console.aws.amazon.com/cloudwatch), [Prometheus](https://console.aws.amazon.com/prometheus) e [X-Ray](https://console.aws.amazon.com/xray).
Per ulteriori informazioni, consulta [Getting Started with AWS Distro for OpenTelemetry using EKS Add-Ons](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on) nella documentazione di AWS Distro per OpenTelemetry.
# Visualizza i dati aggregati sulle risorse del cluster con il pannello di controllo EKS
## Cos’è il pannello di controllo Amazon EKS?
La dashboard di Amazon EKS offre una visibilità consolidata sui cluster Kubernetes in più regioni e account. AWS AWS Con questo pannello di controllo puoi:
+ Tieni traccia dei cluster pianificati per end-of-support gli aggiornamenti automatici entro i prossimi 90 giorni.
+ Progettare i costi del piano di controllo EKS per i cluster con supporto esteso.
+ Esaminare i cluster con approfondimenti che richiedono attenzione prima dell’aggiornamento.
+ Identificare i gruppi di nodi gestiti che eseguono versioni AMI specifiche.
+ Monitorare la distribuzione del tipo di supporto del cluster (standard rispetto al supporto esteso).
La dashboard EKS si integra con EKS Cluster Insights per far emergere problemi con i cluster, come l'uso di Kubernetes obsoleti. APIs Per ulteriori informazioni, consulta [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md).
**Nota**
Il pannello di controllo EKS non è in tempo reale e si aggiorna ogni 12 ore. Per il monitoraggio in tempo reale dei cluster, consulta [Monitoraggio delle prestazioni del cluster e visualizzazione dei log](eks-observe.md)
## In che modo la dashboard utilizza AWS Organizations?
La dashboard di Amazon EKS richiede l'integrazione di AWS Organizations per la funzionalità. Sfrutta AWS Organizations per raccogliere in modo sicuro le informazioni sui cluster tra gli account. Questa integrazione offre gestione e governance centralizzate man mano che l'infrastruttura AWS si espande.
Se AWS Organizations non è abilitato per la tua infrastruttura, consulta la AWS [Organizations User Guide](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) per le istruzioni di configurazione.
### Accesso multi-account e tra regioni
La dashboard EKS può visualizzare le risorse del cluster in qualsiasi account membro dell' AWS organizzazione. Per generare un elenco di AWS account nell'organizzazione, [consulta Esportazione dei dettagli per tutti gli account di un'organizzazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_export.html).
La regione AWS us-east-1 genera il dashboard. Per visualizzare il pannello di controllo, devi accedere a questa regione. La dashboard aggrega i dati tra AWS le regioni, ma non include le `GovCloud` regioni della Cina.
### Termini chiave
+ ** AWS Organizzazione**: una struttura di gestione unificata per più AWS account.
+ **Account di gestione**: l'account principale che controlla l' AWS organizzazione.
+ **Account membro**: qualsiasi account all’interno dell’organizzazione ad eccezione dell’account di gestione.
+ **Amministratore delegato**: account membro a cui sono state concesse autorizzazioni amministrative specifiche per più account. All'interno dell'account di gestione, è possibile selezionare un account amministratore delegato per AWS servizio.
+ **Accesso attendibile**: autorizzazione per il pannello di controllo EKS ad accedere alle informazioni del cluster tra gli account dell’organizzazione.
+ **Service-Linked Role (SLRs)**: un tipo unico di ruolo IAM direttamente collegato a un servizio. AWS Il pannello di controllo EKS usa un SLR per leggere le informazioni sugli account e sulle organizzazioni.
+ Per ulteriori informazioni, vedere [Terminologia e concetti](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) nella AWS Organizations User Guide.
### Panoramica generale
1. Accedi all'account di gestione della tua AWS organizzazione.
+ I passaggi per accedere all'account di gestione dipendono da come hai configurato l' AWS organizzazione. Ad esempio, puoi accedere all’account di gestione tramite AWS [Identity Center](https://aws.amazon.com/iam/identity-center/) o [Okta](https://www.okta.com/partners/aws/).
1. Abilita l’accesso attendibile tramite la console EKS.
1. Assegna un amministratore delegato utilizzando il suo ID AWS account.
1. Passa all’account amministratore delegato.
1. Accedi alla console EKS migliorata con visibilità a livello di organizzazione.
## Abilita la dashboard EKS utilizzando la console AWS
**Importante**
È necessario accedere all'account di gestione della propria AWS organizzazione per abilitare la dashboard EKS.
### Accedi alle impostazioni del pannello di controllo EKS
1. Conferma quanto segue:
1. AWS Organizations è abilitata e configurata.
1. Hai effettuato l’accesso all’account di gestione dell’organizzazione.
1. Stai visualizzando la console AWS di gestione nella regione us-east-1.
1. Passa alla console EKS.
1. Nella barra laterale sinistra, apri Impostazioni del pannello di controllo.
### Configurazione dell’accesso al pannello di controllo Amazon EKS
1. Trova l'ID dell' AWS AWS account a cui desideri consentire la visualizzazione della dashboard EKS.
1. Questo passaggio è facoltativo ma consigliato. In caso contrario, puoi accedere al pannello di controllo solo dall’account di gestione. Come best practice, dovresti limitare gli accessi all’account di gestione.
1. Fai clic su **Abilitazione dell’accesso attendibile**.
1. Ora puoi vedere il pannello di controllo dall’account di gestione.
1. Fai clic su **Registra amministratore delegato** e inserisci l'ID account dell' AWS account che utilizzerai per visualizzare la dashboard.
1. Ora puoi visualizzare il pannello di controllo dall’account amministratore delegato o dall’account di gestione.
Per informazioni sulle autorizzazioni necessarie per abilitare il pannello di controllo, consulta [Policy IAM minime richieste](cluster-dashboard-orgs.md#dashboard-iam-policy).
## Visualizzazione del pannello di controllo EKS
1. Accedi all’account amministratore delegato (consigliato) o all’account di gestione.
1. Accedi alla regione us-east-1.
1. Vai al servizio EKS e seleziona pannello di controllo dalla barra laterale sinistra.
**Nota**
[Controlla le autorizzazioni IAM necessarie per visualizzare il pannello di controllo EKS.](cluster-dashboard-orgs.md#eks-dashboard-view-policy)
## Configura il pannello di controllo
Puoi configurare la visualizzazione del pannello di controllo e filtrare le risorse.
### Risorse disponibili
+ **Cluster**: visualizza informazioni aggregate relative allo stato e alla posizione dei cluster EKS.
+ Cluster con problemi di integrità.
+ Cluster su EKS Extended Support.
+ Suddivisione dei cluster sulla base della versione di Kubernetes.
+ **Gruppi di nodi gestiti**: esamina i gruppi e le EC2 istanze di nodi gestiti.
+ Gruppi di nodi per tipo di AMI, come Amazon Linux o Bottlerocket.
+ Problemi di integrità dei gruppi di nodi.
+ Distribuzione dei tipi di istanza
+ **Componenti aggiuntivi**: scopri quali componenti aggiuntivi Amazon EKS hai installato e qual è il loro stato.
+ Numero di installazioni per componente aggiuntivo.
+ Componenti aggiuntivi con problemi di integrità.
+ Distribuzione della versione per componente aggiuntivo.
### Visualizzazioni disponibili
+ **Vista grafico**
+ Una vista widget personalizzabile che presenta grafici e visualizzazioni della risorsa selezionata.
+ Le modifiche alla vista grafico, come la rimozione di un widget, sono visibili a tutti gli utenti del pannello di controllo EKS.
+ **Vista risorsa**
+ Una vista a elenco della risorsa selezionata, che supporta i filtri.
+ **Vista mappa**
+ Mostra la distribuzione geografica della risorsa selezionata.
### Filtrare il pannello di controllo EKS
Puoi filtrare il pannello di controllo EKS per:
+ AWS Account
+ Unità organizzativa, definita da AWS Organizations
+ AWS Regione
## Disattiva la dashboard EKS utilizzando la AWS console
1. Conferma quanto segue:
1. AWS Organizations è abilitata e configurata.
1. Hai effettuato l’accesso all’account di gestione dell’organizzazione.
1. Stai visualizzando la console AWS di gestione nella regione us-east-1.
1. Passa alla console EKS.
1. Nella barra laterale sinistra, apri Impostazioni del pannello di controllo.
1. Fai clic su **Disabilita accesso attendibile**.
## Risoluzione dei problemi del pannello di controllo EKS
### Problema di attivazione del pannello di controllo EKS
+ È necessario accedere all'account di gestione di un'organizzazione. AWS
+ Se non hai un' AWS organizzazione, creane una. Scopri come [Creare e configurare un’organizzazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html).
+ Se il tuo AWS account è già membro di un' AWS organizzazione, identifica l'amministratore dell'organizzazione.
+ È necessario accedere all' AWS account con autorizzazioni IAM sufficienti per creare e aggiornare le risorse AWS Organizations.
### Problema nella visualizzazione del pannello di controllo EKS
+ Devi aver effettuato l'accesso a uno dei seguenti account: AWS
+ L'account di gestione dell' AWS organizzazione
+ Un account amministratore delegato, identificato nelle impostazioni del pannello di controllo EKS dell’account di gestione.
+ Se hai recentemente abilitato il pannello di controllo EKS, tieni presente che la compilazione iniziale dei dati può richiedere fino a 12 ore.
+ [Prova a riattivare il pannello di controllo usando la CLI](cluster-dashboard-orgs.md#dashboard-enable-cli), inclusa la creazione del ruolo collegato al servizio.
### I widget del pannello di controllo si spostano in modo imprevisto
+ La dashboard EKS salva la visualizzazione configurabile del widget a livello di AWS account. Se modifichi la visualizzazione del widget, le modifiche verranno visualizzate da altre persone che utilizzano lo stesso AWS account.
# Configurare l'integrazione di EKS Dashboard con AWS Organizations
Questa sezione fornisce step-by-step istruzioni per configurare l'integrazione di EKS Dashboard con AWS Organizations. Imparerai come abilitare e disabilitare l’accesso attendibile tra i servizi, nonché come registrare e cancellare gli account di amministratore delegato. Ogni attività di configurazione può essere eseguita utilizzando la AWS console o la AWS CLI.
## Abilitazione dell'accesso attendibile
L’accesso attendibile autorizza il pannello di controllo EKS ad accedere in modo sicuro alle informazioni sui cluster di tutti gli account della tua organizzazione.
### Utilizzo della console AWS
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Accedi alla console EKS nella regione Stati Uniti orientali 1.
1. Nella barra laterale sinistra, seleziona Impostazioni del pannello di controllo.
1. Fai clic su **Abilitazione dell’accesso attendibile**.
**Nota**
Quando abiliti l’accesso attendibile tramite la console EKS, il sistema crea automaticamente il ruolo collegato al servizio `AWSServiceRoleForAmazonEKSDashboard`. Questa creazione automatica non si verifica se si abilita l'accesso affidabile utilizzando la AWS CLI o la console AWS Organizations.
### Utilizzo della AWS CLI
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Esegui i comandi seguenti:
```
aws iam create-service-linked-role --aws-service-name dashboard.eks.amazonaws.com
aws organizations enable-aws-service-access --service-principal eks.amazonaws.com
```
## Disabilitare l'accesso attendibile
La disabilitazione dell’accesso attendibile revoca l’autorizzazione del pannello di controllo EKS ad accedere alle informazioni sui cluster negli account dell’organizzazione.
### Utilizzo della AWS console
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Accedi alla console EKS nella regione Stati Uniti orientali 1.
1. Nella barra laterale sinistra, seleziona Impostazioni del pannello di controllo.
1. Fai clic su **Disabilita accesso attendibile**.
### Utilizzo della AWS CLI
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Esegui il comando seguente:
```
aws organizations disable-aws-service-access --service-principal eks.amazonaws.com
```
## Abilitazione di un account di amministratore delegato
Un amministratore delegato è un account membro a cui è stata concessa l’autorizzazione ad accedere al pannello di controllo EKS.
### Utilizzo della AWS console
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Accedi alla console EKS nella regione Stati Uniti orientali 1.
1. Nella barra laterale sinistra, seleziona Impostazioni del pannello di controllo.
1. Fai clic su **Registrazione degli amministratori delegati**.
1. Inserisci l'ID account dell' AWS account che desideri scegliere come amministratore delegato.
1. Conferma la registrazione.
### Utilizzo della AWS CLI
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Esegui il seguente comando, sostituendo `123456789012` con l’ID del tuo account:
```
aws organizations register-delegated-administrator --account-id 123456789012 --service-principal eks.amazonaws.com
```
## Disabilitare un account di amministratore delegato
La disabilitazione di un amministratore delegato rimuove l’autorizzazione dell’account ad accedere al pannello di controllo EKS.
### Utilizzo della AWS console
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Accedi alla console EKS nella regione Stati Uniti orientali 1.
1. Nella barra laterale sinistra, seleziona Impostazioni del pannello di controllo.
1. Trova l’amministratore delegato nell’elenco.
1. Fai clic su **Annulla registrazione** vicino all’account che vuoi rimuovere come amministratore delegato.
### Utilizzo della AWS CLI
1. Accedi all'account di gestione della tua AWS organizzazione.
1. Esegui il seguente comando, sostituendolo `123456789012` con l’ID dell’account dell’amministratore delegato.
```
aws organizations deregister-delegated-administrator --account-id 123456789012 --service-principal eks.amazonaws.com
```
## Sono richieste policy IAM minime
Questa sezione descrive le politiche IAM minime richieste per consentire l'accesso affidabile e delegare un amministratore per l'integrazione di EKS Dashboard con Organizations AWS .
### Policy per consentire l’accesso attendibile
Per abilitare l'accesso affidabile tra EKS Dashboard e AWS Organizations, sono necessarie le seguenti autorizzazioni:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:EnableAWSServiceAccess",
"organizations:DescribeOrganization",
"organizations:ListAWSServiceAccessForOrganization"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/dashboard.eks.amazonaws.com/AWSServiceRoleForAmazonEKSDashboard"
}
]
}
```
### Policy per la delega di un amministratore
Per registrare o annullare la registrazione di un amministratore delegato per il pannello di controllo EKS, servono le seguenti autorizzazioni:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:RegisterDelegatedAdministrator",
"organizations:DeregisterDelegatedAdministrator",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
}
]
}
```
### Policy per la visualizzazione del pannello di controllo EKS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSDashboardReadOnly",
"Effect": "Allow",
"Action": [
"eks:ListDashboardData",
"eks:ListDashboardResources",
"eks:DescribeClusterVersions"
],
"Resource": "*"
},
{
"Sid": "AmazonOrganizationsReadOnly",
"Effect": "Allow",
"Action": [
"organizations:DescribeOrganization",
"organizations:ListAWSServiceAccessForOrganization",
"organizations:ListRoots",
"organizations:ListAccountsForParent",
"organizations:ListOrganizationalUnitsForParent"
],
"Resource": "*"
},
{
"Sid": "AmazonOrganizationsDelegatedAdmin",
"Effect": "Allow",
"Action": [
"organizations:ListDelegatedAdministrators"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"organizations:ServicePrincipal": "eks.amazonaws.com"
}
}
}
]
}
```
**Nota**
Queste policy devono essere collegate al principale IAM (utente o ruolo) nell'account di gestione dell' AWS organizzazione. Gli account dei membri non possono consentire l’accesso attendibile o delegare amministratori.