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à.
# Installa l' CloudWatch agente con il componente aggiuntivo Amazon CloudWatch Observability EKS o il grafico Helm
Puoi utilizzare il componente aggiuntivo Amazon CloudWatch Observability EKS o il grafico Amazon CloudWatch Observability Helm per installare l' CloudWatch agente e l'agente Fluent-bit su un cluster Amazon EKS. Puoi anche utilizzare il grafico Helm per installare l' CloudWatch agente e l'agente Fluent-bit su un cluster Kubernetes che non è ospitato su Amazon EKS.
L'uso di entrambi i metodi su un cluster Amazon EKS abilita sia [Container Insights](ContainerInsights.md) con osservabilità migliorata per Amazon EKS che [CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) per impostazione predefinita. Utilizzando il componente aggiuntivo, è possibile raccogliere le metriche dell'infrastruttura, la telemetria delle prestazioni delle applicazioni e i log dei container dal cluster.
Con la versione `v6.0.1-eksbuild.1` o successiva del componente aggiuntivo, è abilitato Container Insights with OpenTelemetry metrics, che raccoglie i parametri utilizzando il OpenTelemetry protocollo (OTLP) e supporta le query PromQL. Per ulteriori informazioni, consulta [Container Insights con OpenTelemetry metriche per Amazon EKS](container-insights-otel-metrics.md).
Con Approfondimenti sui container con osservabilità migliorata per Amazon EKS, i parametri di Approfondimenti sui container vengono addebitati per osservazione anziché per parametro archiviato o log importato. Per Application Signals, la fatturazione si basa sulle richieste in entrata alle applicazioni, sulle richieste in uscita dalle applicazioni e su ogni obiettivo del livello di servizio (SLO) configurato. Ogni richiesta in entrata ricevuta e ogni richiesta in uscita effettuata genera un segnale di applicazione. Ogni SLO crea due segnali di applicazione per ciascun periodo di misurazione. Per ulteriori informazioni sui CloudWatch prezzi, consulta la pagina [ CloudWatch dei prezzi di Amazon](https://aws.amazon.com/cloudwatch/pricing/).
Entrambi i metodi abilitano Approfondimenti sui container su nodi di lavoro Linux e Windows nel cluster Amazon EKS. Per abilitare Approfondimenti sui container su Windows, è necessario utilizzare la versione 1.5.0 o successiva del componente aggiuntivo Amazon EKS o il grafico Helm. Application Signals non è supportato su Windows nei cluster Amazon EKS.
Il componente aggiuntivo Amazon CloudWatch Observability EKS è supportato sui cluster Amazon EKS in esecuzione con Kubernetes versione 1.23 o successiva.
Quando installi il componente aggiuntivo o il grafico Helm, devi inoltre concedere le autorizzazioni IAM per consentire all' CloudWatch agente di inviare metriche, log e tracce a. CloudWatch Ci sono due modi per effettuare questa operazione:
+ Collega una policy al ruolo IAM dei nodi di lavoro. Questa opzione concede ai nodi di lavoro le autorizzazioni a cui inviare telemetria. CloudWatch
+ Utilizza un ruolo IAM per gli account di servizio per i pod dell'agente e collega la policy a questo ruolo. Questo metodo funziona solo per i cluster Amazon EKS. Questa opzione consente l' CloudWatch accesso solo ai pod degli agenti appropriati.
**Topics**
+ [Opzione 1: installazione utilizzando EKS Pod Identity](#install-CloudWatch-Observability-EKS-pod-identity)
+ [Opzione 2: installazione con autorizzazioni IAM sui nodi di lavoro](#install-CloudWatch-Observability-EKS-addon-workernodes)
+ [Opzione 3: installazione tramite il ruolo dell'account di servizio IAM (si applica solo all'utilizzo del componente aggiuntivo)](#install-CloudWatch-Observability-EKS-addon-serviceaccountrole)
+ [(Facoltativo) Configurazione aggiuntiva](#install-CloudWatch-Observability-EKS-addon-configuration)
+ [Raccolta delle metriche di Java Management Extensions (JMX)](#install-CloudWatch-Observability-EKS-addon-JMX-metrics)
+ [Abilitazione delle metriche di Kueue](#enable-Kueue-metrics)
+ [Aggiungere file di configurazione del collettore OpenTelemetry](#install-CloudWatch-Observability-EKS-addon-OpenTelemetry)
+ [Abilitazione di APM tramite Application Signals per il tuo cluster Amazon EKS](#Container-Insights-setup-EKS-appsignalsconfiguration)
+ [Considerazioni per i cluster Kubernetes di grandi dimensioni](#install-CloudWatch-Observability-EKS-addon-large-clusters)
+ [Considerazioni per Amazon EKS Hybrid Nodes](#install-CloudWatch-Observability-EKS-addon-hybrid)
+ [Risoluzione dei problemi relativi al componente aggiuntivo Amazon CloudWatch Observability EKS o al diagramma Helm](#Container-Insights-setup-EKS-addon-troubleshoot)
+ [Disattiva Application Signals](#Opting-out-App-Signals)
## Opzione 1: installazione utilizzando EKS Pod Identity
Se si utilizza la versione 3.1.0 o successiva del componente aggiuntivo, è possibile utilizzare EKS Pod Identity per concedere le autorizzazioni richieste al componente aggiuntivo. EKS Pod Identity è l'opzione consigliata e offre vantaggi come il privilegio minimo, la rotazione delle credenziali e la verificabilità. Inoltre, l'utilizzo di EKS Pod Identity consente di installare il componente aggiuntivo EKS come parte della creazione del cluster stesso.
Per utilizzare questo metodo, segui innanzitutto i passaggi di [Associazione EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/) per creare il ruolo IAM e configurare l'agente EKS Pod Identity.
Quindi installa il componente aggiuntivo Amazon CloudWatch Observability EKS. Per installare il componente aggiuntivo, puoi utilizzare la AWS CLI console Amazon EKS o Terraform. CloudFormation
------
#### [ AWS CLI ]
**Per utilizzare il AWS CLI componente aggiuntivo Amazon CloudWatch Observability EKS**
Esegui i comandi seguenti: Sostituiscilo `{{my-cluster-name}}` con il nome del cluster e sostituiscilo {{111122223333}} con l'ID dell'account. Sostituiscilo {{my-role}} con il ruolo IAM creato nella fase di associazione EKS Pod Identity.
```
aws iam attach-role-policy \
--role-name {{my-role}} \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name {{my-cluster-name}} \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::{{111122223333}}:role/{{my-role}}
```
------
#### [ Amazon EKS console ]
**Per utilizzare la console Amazon EKS per aggiungere il componente aggiuntivo Amazon CloudWatch Observability EKS**
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\#/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Scegli il nome del cluster per cui desideri configurare il componente aggiuntivo Amazon CloudWatch Observability EKS.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Scegli **Ottieni altri componenti aggiuntivi**.
1. Nella pagina **Seleziona componenti aggiuntivi**, procedi come segue:
1. Nella sezione **Amazon EKS-Addons**, seleziona la casella di controllo **Amazon CloudWatch ** Observability.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, procedi come segue:
1. Seleziona la **Versione** che desideri utilizzare.
1. Per **Accesso al componente aggiuntivo**, seleziona **EKS Pod Identity**
1. Se non hai configurato un ruolo IAM, scegli **Crea ruolo consigliato**, quindi scegli **Avanti** fino al **Passaggio 3: Nomina, verifica e crea**. Se lo desideri, puoi modificare il nome del ruolo, altrimenti scegli **Crea ruolo**, quindi torna alla pagina del componente aggiuntivo e seleziona il ruolo IAM che hai appena creato.
1. (Facoltativo) È possibile espandere le **Impostazioni di configurazione facoltative**. Se selezioni **Sostituisci** per **Metodo di risoluzione dei conflitti**, una o più impostazioni per il componente aggiuntivo esistente possono essere sovrascritte con le impostazioni del componente aggiuntivo di Amazon EKS. Se rimuovi questa opzione e c'è un conflitto con le impostazioni esistenti, l'operazione non va a buon fine e viene visualizzato un messaggio di errore per aiutarti a risolvere il conflitto. Prima di selezionare questa opzione, assicurarsi che il componente aggiuntivo Amazon EKS non gestisca le impostazioni che devono essere gestite dall'utente.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e aggiungi**, scegli **Crea**. Una volta completata l'installazione, viene visualizzato il componente aggiuntivo.
------
#### [ CloudFormation ]
**Da utilizzare CloudFormation per installare il componente aggiuntivo Amazon CloudWatch Observability EKS**
1. Innanzitutto, esegui il AWS CLI comando seguente per allegare la politica IAM necessaria al tuo ruolo IAM. Sostituiscilo {{my-role}} con il ruolo che hai creato nella fase di associazione EKS Pod Identity.
```
aws iam attach-role-policy \
--role-name {{my-role}} \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. Successivamente, crea le seguenti risorse. Sostituiscilo `{{my-cluster-name}}` con il nome del cluster, sostituiscilo {{111122223333}} con l'ID dell'account e sostituiscilo {{my-role}} con il ruolo IAM creato nella fase di associazione EKS Pod Identity. Per ulteriori informazioni, consulta [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "{{my-cluster-name}}",
"PodIdentityAssociations": [
{
"ServiceAccount": "cloudwatch-agent",
"RoleArn": "arn:aws:iam::{{111122223333}}:role/{{my-role}}"
}
]
}
}
}
}
```
------
#### [ Terraform ]
**Per utilizzare Terraform per installare il componente aggiuntivo Amazon CloudWatch Observability EKS**
1. Utilizza quanto segue. Sostituiscilo `{{my-cluster-name}}` con il nome del cluster, sostituiscilo {{111122223333}} con l'ID dell'account e sostituiscilo {{my-service-account-role}} con il ruolo IAM creato nella fase di associazione EKS Pod Identity.
Per ulteriori informazioni, consulta [ Resource: aws\_eks\_addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon) nella documentazione di Terraform.
1.
```
resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = "my-role"
}
resource "aws_eks_addon" "example" {
cluster_name = "my-cluster-name"
addon_name = "amazon-cloudwatch-observability"
pod_identity_associations {
roleArn = "arn:aws:iam::111122223333:role/my-role"
serviceAccount = "cloudwatch-agent"
}
}
```
------
## Opzione 2: installazione con autorizzazioni IAM sui nodi di lavoro
Per utilizzare questo metodo, collega innanzitutto la policy **CloudWatchAgentServerPolicy**IAM ai nodi di lavoro inserendo il seguente comando. In questo comando, sostituiscilo {{my-worker-node-role}} con il ruolo IAM utilizzato dai nodi di lavoro Kubernetes.
```
aws iam attach-role-policy \
--role-name {{my-worker-node-role}} \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
Quindi installa il componente aggiuntivo Amazon CloudWatch Observability EKS. Per installare il componente aggiuntivo, puoi utilizzare la AWS CLI console o Terraform CloudFormation.
------
#### [ AWS CLI ]
**Per utilizzare il AWS CLI componente aggiuntivo Amazon CloudWatch Observability EKS**
Inserire il seguente comando. Sostituisci `{{my-cluster-name}}` con il nome del cluster.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name {{my-cluster-name}}
```
------
#### [ Amazon EKS console ]
**Per utilizzare la console Amazon EKS per aggiungere il componente aggiuntivo Amazon CloudWatch Observability EKS**
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\#/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Scegli il nome del cluster per cui desideri configurare il componente aggiuntivo Amazon CloudWatch Observability EKS.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Scegli **Ottieni altri componenti aggiuntivi**.
1. Nella pagina **Seleziona componenti aggiuntivi**, procedi come segue:
1. Nella sezione **Amazon EKS-Addons**, seleziona la casella di controllo **Amazon CloudWatch ** Observability.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, procedi come segue:
1. Seleziona la **Versione** che desideri utilizzare.
1. (Facoltativo) È possibile espandere le **Impostazioni di configurazione facoltative**. Se selezioni **Sostituisci** per **Metodo di risoluzione dei conflitti**, una o più impostazioni per il componente aggiuntivo esistente possono essere sovrascritte con le impostazioni del componente aggiuntivo di Amazon EKS. Se rimuovi questa opzione e c'è un conflitto con le impostazioni esistenti, l'operazione non va a buon fine e viene visualizzato un messaggio di errore per aiutarti a risolvere il conflitto. Prima di selezionare questa opzione, assicurarsi che il componente aggiuntivo Amazon EKS non gestisca le impostazioni che devono essere gestite dall'utente.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e aggiungi**, scegli **Crea**. Una volta completata l'installazione, viene visualizzato il componente aggiuntivo.
------
#### [ CloudFormation ]
**Da utilizzare CloudFormation per installare il componente aggiuntivo Amazon CloudWatch Observability EKS**
Sostituisci `{{my-cluster-name}}` con il nome del cluster. Per ulteriori informazioni, consulta [ AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html).
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "{{my-cluster-name}}"
}
}
}
}
```
------
#### [ Helm chart ]
**Per utilizzare il grafico Helm `amazon-cloudwatch-observability`**
1. È necessario che Helm sia installato per utilizzare questo grafico. Per ulteriori informazioni sull'installazione di Helm, consulta la [documentazione di Helm](https://helm.sh/docs/).
1. Dopo aver installato Helm, immetti i seguenti comandi. Sostituiscilo {{my-cluster-name}} con il nome del cluster e sostituiscilo {{my-cluster-region}} con la regione in cui viene eseguito il cluster.
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName={{my-cluster-name}} --set region={{my-cluster-region}}
```
------
#### [ Terraform ]
**Per utilizzare Terraform per installare il componente aggiuntivo Amazon CloudWatch Observability EKS**
Sostituisci `{{my-cluster-name}}` con il nome del cluster. Per ulteriori informazioni, consulta la sezione [Risorsa: aws\_eks\_addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_ad).
```
resource "aws_eks_addon" "example" {
addon_name = "amazon-cloudwatch-observability"
cluster_name = "{{my-cluster-name}}"
}
```
------
## Opzione 3: installazione tramite il ruolo dell'account di servizio IAM (si applica solo all'utilizzo del componente aggiuntivo)
Questo metodo è valido solo se utilizzi il componente aggiuntivo Amazon CloudWatch Observability EKS. Prima di utilizzare questo metodo, verifica di soddisfare i seguenti prerequisiti:
+ Disponi di un cluster Amazon EKS funzionale con nodi collegati in una delle Regioni AWS che supportano Approfondimenti sui container. Per l'elenco delle regioni supportate, consulta [Container Insights](ContainerInsights.md).
+ `kubectl` deve essere installato e configurato per il cluster. Per ulteriori informazioni, consulta la pagina relativa all'[installazione di `kubectl`](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) nella *Guida per l'utente di Amazon EKS*.
+ `eksctl` deve essere installato. Per ulteriori informazioni, consulta la pagina [Installing or updating `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html) nella *Guida per l'utente di Amazon EKS*.
------
#### [ AWS CLI ]
**Per utilizzare l' AWS CLI installazione del componente aggiuntivo Amazon CloudWatch Observability EKS utilizzando il ruolo dell'account del servizio IAM**
1. Immetti il comando seguente per creare un provider OpenID Connect (OIDC), se il cluster non ne ha già uno. Per ulteriori informazioni, consulta la pagina [Configuring a Kubernetes service account to assume an IAM role](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) nella *Guida per l'utente di Amazon EKS*.
```
eksctl utils associate-iam-oidc-provider --cluster {{my-cluster-name}} --approve
```
1. Immetti il seguente comando per creare il ruolo IAM con la **CloudWatchAgentServerPolicy**policy allegata e configura l'account del servizio agente in modo che assuma quel ruolo utilizzando OIDC. Sostituiscilo {{my-cluster-name}} con il nome del cluster e sostituiscilo {{my-service-account-role}} con il nome del ruolo a cui desideri associare l'account di servizio. Se il ruolo non esiste ancora, `eksctl` lo crea per tuo conto.
```
eksctl create iamserviceaccount \
--name cloudwatch-agent \
--namespace amazon-cloudwatch --cluster {{my-cluster-name}} \
--role-name {{my-service-account-role}} \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-only \
--approve
```
1. Installa il componente aggiuntivo immettendo il seguente comando. Sostituiscilo {{my-cluster-name}} con il nome del cluster, sostituiscilo {{111122223333}} con l'ID dell'account e sostituiscilo {{my-service-account-role}} con il ruolo IAM creato nel passaggio precedente.
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name {{my-cluster-name}} --service-account-role-arn arn:aws:iam::{{111122223333}}:role/{{my-service-account-role}}
```
------
#### [ Amazon EKS console ]
**Per utilizzare la console per installare il componente aggiuntivo Amazon CloudWatch Observability EKS utilizzando il ruolo dell'account del servizio IAM**
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\#/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Scegli il nome del cluster per cui desideri configurare il componente aggiuntivo Amazon CloudWatch Observability EKS.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Scegli **Ottieni altri componenti aggiuntivi**.
1. Nella pagina **Seleziona componenti aggiuntivi**, procedi come segue:
1. Nella sezione **Amazon EKS-Addons**, seleziona la casella di controllo **Amazon CloudWatch ** Observability.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, procedi come segue:
1. Seleziona la **Versione** che desideri utilizzare.
1. Per **Accesso al componente aggiuntivo**, seleziona **Ruoli IAM per gli account di servizio (IRSA)**
1. Seleziona il ruolo IAM nella casella **Accesso al componente aggiuntivo**.
1. (Facoltativo) È possibile espandere le **Impostazioni di configurazione facoltative**. Se selezioni **Sostituisci** per **Metodo di risoluzione dei conflitti**, una o più impostazioni per il componente aggiuntivo esistente possono essere sovrascritte con le impostazioni del componente aggiuntivo di Amazon EKS. Se rimuovi questa opzione e c'è un conflitto con le impostazioni esistenti, l'operazione non va a buon fine e viene visualizzato un messaggio di errore per aiutarti a risolvere il conflitto. Prima di selezionare questa opzione, assicurarsi che il componente aggiuntivo Amazon EKS non gestisca le impostazioni che devono essere gestite dall'utente.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e aggiungi**, scegli **Crea**. Una volta completata l'installazione, viene visualizzato il componente aggiuntivo.
------
## (Facoltativo) Configurazione aggiuntiva
**Topics**
+ [Disattivazione della raccolta di log di container](#CloudWatch-Observability-EKS-addon-OptOutContainerLogs)
+ [Utilizzo di una configurazione Fluent Bit personalizzata](#CloudWatch-Observability-EKS-addon-CustomFluentBit)
+ [Gestione delle tolleranze di Kubernetes per i carichi di lavoro dei pod installati](#CloudWatch-Observability-EKS-addon-Tolerations)
+ [Disattivazione della raccolta di metriche di calcolo accelerato](#CloudWatch-Observability-EKS-addon-OptOutAccelerated)
+ [Utilizzare una configurazione personalizzata CloudWatch dell'agente](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)
+ [Gestisci i certificati webhook di ammissione TLS](#CloudWatch-Observability-EKS-addon-Webhook)
+ [Raccogli il volume Amazon EBS IDs](#CloudWatch-Observability-EKS-addon-VolumeIDs)
### Disattivazione della raccolta di log di container
Per impostazione predefinita, il componente aggiuntivo utilizza Fluent Bit per raccogliere i log dei container da tutti i pod e quindi invia i log a Logs. CloudWatch Per informazioni su quali log vengono raccolti, consulta la pagina [Configurazione di Fluent Bit](Container-Insights-setup-logs-FluentBit.md#Container-Insights-FluentBit-setup).
**Nota**
Né il componente aggiuntivo né il grafico Helm gestiscono le risorse Fluentd o Fluent Bit esistenti in un cluster. È possibile eliminare le risorse Fluentd o Fluent Bit esistenti prima di installare il componente aggiuntivo o il grafico Helm. In alternativa, per mantenere la configurazione esistente ed evitare che il componente aggiuntivo o il grafico Helm installino anche Fluent Bit, è possibile disabilitarla seguendo le istruzioni in questa sezione.
Per disattivare la raccolta dei log dei container se utilizzi il componente aggiuntivo Amazon CloudWatch Observability EKS, utilizza la seguente opzione quando crei o aggiorni il componente aggiuntivo:
```
--configuration-values '{ "containerLogs": { "enabled": false } }'
```
Per annullare la raccolta dei log dei container se utilizzi il grafico Helm, utilizza la seguente opzione quando crei o aggiorni il componente aggiuntivo:
```
--set containerLogs.enabled=false
```
### Utilizzo di una configurazione Fluent Bit personalizzata
A partire dalla versione 1.7.0 del componente aggiuntivo Amazon CloudWatch Observability EKS, puoi modificare la configurazione Fluent Bit quando crei o aggiorni il componente aggiuntivo o il grafico Helm. Fornisci la configurazione Fluent Bit personalizzata nella sezione di livello root `containerLogs` della configurazione avanzata del componente aggiuntivo o sostituisci i valori nel grafico Helm. All'interno di questa sezione, fornisci la configurazione Fluent Bit personalizzata nella sezione `config` (per Linux) o nella sezione `configWindows` (per Windows). `config` è ulteriormente suddiviso nelle seguenti sottosezioni:
+ `service`: questa sezione rappresenta la configurazione `SERVICE` per definire il comportamento globale del motore Fluent Bit.
+ `customParsers`: questa sezione rappresenta tutti i `PARSER` globali che si desidera includere in grado di prendere voci di log non strutturate e fornire loro una struttura per facilitarne l'elaborazione e il successivo filtraggio.
+ `extraFiles`: questa sezione può essere utilizzata per fornire file `conf` Fluent Bit aggiuntivi da includere. Per impostazione predefinita, sono inclusi i seguenti tre file `conf`:
+ `application-log.conf`— Un `conf` file per inviare i log delle applicazioni dal cluster al gruppo di log in Logs. `/aws/containerinsights/{{my-cluster-name}}/application` CloudWatch
+ `dataplane-log.conf`— Un `conf` file per inviare i log corrispondenti ai componenti del piano dati del cluster, inclusi i log CRI, i log kubelet, i log kube-proxy e i log CNI di Amazon VPC VPC, al gruppo di log in Logs. `/aws/containerinsights/{{my-cluster-name}}/dataplane` CloudWatch
+ `host-log.conf`— Un `conf` per inviare i log da `/var/log/dmesg` e su Linux e System su Windows al gruppo di log in. `/var/log/messages` `/var/log/secure` `winlogs` `/aws/containerinsights/{{my-cluster-name}}/host` CloudWatch
**Nota**
Fornisci la configurazione completa per ciascuna di queste singole sezioni anche se stai modificando solo un campo all'interno di una sottosezione. Ti consigliamo di utilizzare la configurazione predefinita fornita di seguito come base e di modificarla di conseguenza in modo da non disabilitare la funzionalità abilitata per impostazione predefinita. Puoi utilizzare la seguente configurazione YAML quando modifichi la configurazione avanzata per il componente aggiuntivo Amazon EKS o quando fornisci valori sostitutivi per il grafico Helm.
Per trovare la `config` sezione relativa al tuo cluster, consulta [aws-observability/helm-charts](https://github.com/aws-observability/helm-charts/releases) su GitHub e trova la versione corrispondente alla versione del componente aggiuntivo o Helm chart che stai installando. Quindi vai a `/charts/amazon-cloudwatch-observability/values.yaml` per individuare la sezione `config` (per Linux) e la sezione `configWindows` (per Windows) all'interno della sezione `fluentBit` sotto `containerLogs`.
Ad esempio, la configurazione predefinita di Fluent Bit per la versione 1.7.0 è disponibile [qui](https://github.com/aws-observability/helm-charts/blob/v1.7.0/charts/amazon-cloudwatch-observability/values.yaml#L44)).
Ti consigliamo di fornire `config` sotto forma di YAML quando lo fornisci utilizzando la configurazione avanzata del componente aggiuntivo Amazon EKS o come valori sostitutivi per l'installazione con Helm. Assicurati che YAML sia conforme alla seguente struttura.
```
containerLogs:
fluentBit:
config:
service: |
...
customParsers: |
...
extraFiles:
application-log.conf: |
...
dataplane-log.conf: |
...
host-log.conf: |
...
```
L'esempio seguente di `config` modifica l'impostazione globale per l'intervallo di flush in modo che sia di 45 secondi. Anche se l'unica modifica riguarda il campo `Flush`, è comunque necessario fornire la definizione di `SERVICE` completa per la sottosezione del servizio. Poiché questo esempio non ha specificato le sostituzioni per le altre sottosezioni, per esse vengono utilizzate le impostazioni predefinite.
```
containerLogs:
fluentBit:
config:
service: |
[SERVICE]
Flush 45
Grace 30
Log_Level error
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
```
La configurazione di esempio seguente include un file `conf` Fluent bit aggiuntivo. In questo esempio, stiamo aggiungendo un `my-service.conf` personalizzato sotto `extraFiles`, che verrà incluso in aggiunta ai tre `extraFiles` predefiniti.
```
containerLogs:
fluentBit:
config:
extraFiles:
my-service.conf: |
[INPUT]
Name tail
Tag myservice.*
Path /var/log/containers/*myservice*.log
DB /var/fluent-bit/state/flb_myservice.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Ignore_Older 1d
Refresh_Interval 10
[OUTPUT]
Name cloudwatch_logs
Match myservice.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice
log_stream_prefix ${HOST_NAME}-
auto_create_group true
```
Il prossimo esempio rimuove completamente un file `conf` esistente da `extraFiles`. Ciò lo esclude completamente da `application-log.conf` sovrascrivendolo con una stringa vuota. La semplice omissione di `application-log.conf` da `extraFiles` implicherebbe invece l'utilizzo del valore predefinito, che non è quello che stiamo cercando di ottenere in questo esempio. Lo stesso vale per la rimozione di qualsiasi file `conf` personalizzato che potresti aver aggiunto in precedenza a `extraFiles`.
```
containerLogs:
fluentBit:
config:
extraFiles:
application-log.conf: ""
```
### Gestione delle tolleranze di Kubernetes per i carichi di lavoro dei pod installati
A partire dalla versione 1.7.0 del componente aggiuntivo Amazon CloudWatch Observability EKS, il componente aggiuntivo e il grafico Helm impostano per impostazione predefinita le tolleranze di Kubernetes per *tollerare tutte le contaminazioni* sui carichi di lavoro dei pod installati dal componente aggiuntivo o dal grafico Helm. Ciò garantisce che i daemonset come l'agente e Fluent Bit possano pianificare i pod su tutti i nodi del cluster per impostazione predefinita. CloudWatch Per ulteriori informazioni su taint e tolleranze, consulta [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nella documentazione di Kubernetes.
Le tolleranze predefinite impostate dal componente aggiuntivo o dal grafico Helm sono le seguenti:
```
tolerations:
- operator: Exists
```
È possibile sovrascrivere le tolleranze predefinite impostando il campo `tolerations` al livello root quando si utilizza la configurazione avanzata del componente aggiuntivo o quando si installa o si aggiorna il grafico Helm con sostituzioni dei valori. Di seguito è riportato un possibile esempio:
```
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
Per omettere completamente le tolleranze, puoi utilizzare una configurazione simile alla seguente:
```
tolerations: []
```
Qualsiasi modifica alle tolleranze si applica a tutti i carichi di lavoro dei pod installati dal componente aggiuntivo o dal grafico Helm.
### Disattivazione della raccolta di metriche di calcolo accelerato
Per impostazione predefinita, Container Insights con osservabilità migliorata raccoglie metriche per il monitoraggio di Accelerated Compute, tra cui le metriche della GPU NVIDIA, le metriche AWS Neuron per AWS Trainium e Inferentia e le metriche Elastic Fabric Adapter (EFA). AWS AWS
Le metriche delle GPU NVIDIA dei carichi di lavoro Amazon EKS vengono raccolte per impostazione predefinita a partire dalla versione `v1.3.0-eksbuild.1` del componente aggiuntivo EKS o dal grafico Helm e dalla versione dell'agente. `1.300034.0` CloudWatch Per un elenco delle metriche raccolte e dei prerequisiti, consulta [Metriche della GPU NVIDIA](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU).
AWS Le metriche Neuron per gli acceleratori AWS Trainium e AWS Inferentia vengono raccolte per impostazione predefinita a partire dalla versione del componente aggiuntivo EKS o dal grafico Helm e dalla versione `v1.5.0-eksbuild.1` dell'agente. `1.300036.0` CloudWatch Per un elenco delle metriche raccolte e dei prerequisiti, consulta [AWS Metriche neuronali per AWS Trainium e Inferentia AWS](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-Neuron).
AWS Le metriche Elastic Fabric Adapter (EFA) dei nodi Linux sui cluster Amazon EKS vengono raccolte per impostazione predefinita a partire dalla versione `v1.5.2-eksbuild.1` del componente aggiuntivo EKS o dal grafico Helm e dalla versione dell'agente. `1.300037.0` CloudWatch Per un elenco delle metriche raccolte e dei prerequisiti, consulta [AWS Metriche Elastic Fabric Adapter (EFA)](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EFA).
Puoi scegliere di non raccogliere queste metriche impostando il `accelerated_compute_metrics` campo nel file di configurazione dell'agente su. CloudWatch `false` Questo campo si trova nella `kubernetes` sezione della `metrics_collected` sezione del file di CloudWatch configurazione. Di seguito è riportato un esempio di configurazione di non adesione. Per ulteriori informazioni su come utilizzare le configurazioni degli CloudWatch agenti personalizzate, vedere la sezione seguente,[Utilizzare una configurazione personalizzata CloudWatch dell'agente](#CloudWatch-Observability-EKS-addon-CustomAgentConfig).
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true,
"accelerated_compute_metrics": false
}
}
}
}
```
### Utilizzare una configurazione personalizzata CloudWatch dell'agente
Per raccogliere altre metriche, log o tracce utilizzando l' CloudWatch agente, puoi specificare una configurazione personalizzata mantenendo attivi Container Insights e CloudWatch Application Signals. A tale scopo, incorpora il file di configurazione dell' CloudWatch agente nella chiave di configurazione sotto la chiave dell'agente della configurazione avanzata che puoi utilizzare durante la creazione o l'aggiornamento del componente aggiuntivo EKS o del grafico Helm. Di seguito è rappresentata la configurazione predefinita dell'agente quando non si fornisce alcuna configurazione aggiuntiva.
**Importante**
Qualsiasi configurazione personalizzata fornita utilizzando impostazioni di configurazione aggiuntive ha la precedenza sulla configurazione predefinita utilizzata dall'agente. Fai attenzione a non disattivare involontariamente funzionalità abilitate di default, come Container Insights con osservabilità migliorata e Application Signals. CloudWatch Se è necessario fornire una configurazione personalizzata dell'agente, consigliamo di utilizzare la seguente configurazione predefinita come base e modificarla di secondo le necessità.
+ Per utilizzare il componente aggiuntivo Amazon CloudWatch observability EKS
```
--configuration-values '{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}'
```
+ Per utilizzare il grafico Helm
```
--set agent.config='{
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}'
```
L'esempio seguente mostra la configurazione predefinita dell' CloudWatch agente su Windows. L' CloudWatch agente su Windows non supporta la configurazione personalizzata.
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
},
}
}
}
```
### Gestisci i certificati webhook di ammissione TLS
Il componente aggiuntivo Amazon CloudWatch Observability EKS e il grafico Helm sfruttano i [webhook di ammissione](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) di Kubernetes per convalidare e modificare le richieste di risorse (CR) `Instrumentation` personalizzate `AmazonCloudWatchAgent` e, facoltativamente, le richieste pod Kubernetes sul cluster se Application Signals è abilitato. CloudWatch In Kubernetes, i webhook richiedono un certificato TLS configurato per stabilire una relazione di attendibilità con il server API per garantire una comunicazione sicura.
Per impostazione predefinita, il componente aggiuntivo Amazon CloudWatch Observability EKS e il grafico Helm generano automaticamente una CA autofirmata e un certificato TLS firmato da questa CA per proteggere la comunicazione tra il server API e il server webhook. Questo certificato generato automaticamente ha una scadenza predefinita di 10 anni e non viene rinnovato automaticamente alla scadenza. Inoltre, il bundle CA e il certificato vengono rigenerati ogni volta che il componente aggiuntivo o il grafico Helm viene aggiornato o reinstallato, reimpostando così la scadenza. Se desideri modificare la scadenza predefinita del certificato generato automaticamente, puoi utilizzare le seguenti configurazioni aggiuntive durante la creazione o l'aggiornamento del componente aggiuntivo. Sostituiscilo con la durata {{expiry-in-days}} di scadenza desiderata in giorni.
+ Usalo per il componente aggiuntivo Amazon CloudWatch Observability EKS
```
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": {{expiry-in-days}} } } }'
```
+ Utilizzare questo per il grafico Helm
```
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
```
Per una soluzione di autorità di certificazione più sicura e ricca di funzionalità, il componente aggiuntivo offre il supporto opt-in per [cert-manager](https://cert-manager.io/docs/), una soluzione ampiamente adottata per la gestione dei certificati TLS in Kubernetes che semplifica il processo di ottenimento, rinnovo, gestione e utilizzo di tali certificati. Garantisce che i certificati siano validi e aggiornati e tenta di rinnovarli in un momento impostato prima della scadenza. cert-manager facilita anche l'emissione di certificati da una varietà di fonti supportate, tra cui [AWS Certificate Manager Private Certificate Authority](https://aws.amazon.com/private-ca/).
Ti consigliamo di esaminare le best practice per la gestione dei certificati TLS sui tuoi cluster e di scegliere di utilizzare cert-manager per gli ambienti di produzione. Tieni presente che se scegli di abilitare cert-manager per la gestione dei certificati TLS del webhook di ammissione, devi preinstallare cert-manager sul tuo cluster Amazon EKS prima di installare il componente aggiuntivo Amazon Observability EKS o il grafico Helm CloudWatch . Per ulteriori informazioni sulle opzioni di installazione disponibili, consulta la [ documentazione di cert-manager](https://cert-manager.io/docs/installation/). Dopo l'installazione, puoi scegliere di utilizzare cert-manager per la gestione dei certificati TLS webhook di ammissione utilizzando la seguente configurazione aggiuntiva.
+ Se utilizzi il componente aggiuntivo Amazon CloudWatch Observability EKS
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
+ Se stai usando il grafico Helm
```
--set admissionWebhooks.certManager.enabled=true
```
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
La configurazione avanzata descritta in questa sezione utilizza per impostazione predefinita un [ SelfSigned](https://cert-manager.io/docs/configuration/selfsigned/)emittente.
### Raccogli il volume Amazon EBS IDs
Se desideri raccogliere il volume Amazon EBS IDs nei log delle prestazioni, devi aggiungere un'altra policy al ruolo IAM collegata ai nodi di lavoro o all'account di servizio. Aggiungi quanto segue come una policy inline. Per ulteriori informazioni, consulta la pagina [Adding and Removing IAM Identity Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## Raccolta delle metriche di Java Management Extensions (JMX)
L' CloudWatch agente supporta la raccolta di metriche Java Management Extensions (JMX) su Amazon EKS. Ciò consente di raccogliere metriche aggiuntive dalle applicazioni Java in esecuzione su cluster Amazon EKS, consentendo di ottenere informazioni dettagliate su prestazioni, utilizzo della memoria, traffico e altre metriche critiche. Per ulteriori informazioni, consulta [Raccolta delle metriche di Java Management Extensions (JMX)](CloudWatch-Agent-JMX-metrics.md).
## Abilitazione delle metriche di Kueue
A partire dalla versione `v2.4.0-eksbuild.1` del componente aggiuntivo CloudWatch Observability EKS, Container Insights for Amazon EKS supporta la raccolta di metriche Kueue dai cluster Amazon EKS. Per ulteriori informazioni su questi parametri, consulta [Metriche Kueue](Container-Insights-metrics-EKS.md#Container-Insights-metrics-Kueue).
**Se utilizzi il componente aggiuntivo Amazon SageMaker AI Hyperpod Task Governance EKS, puoi saltare i passaggi nella sezione Prerequisiti e seguire semplicemente i passaggi indicati.** [Abilitazione del flag di configurazione](#enable-Kueue-metrics-flag)
### Prerequisiti
Prima di installare Kueue nel cluster Amazon EKS, apporta le seguenti modifiche al file manifesto:
1. Abilita le metriche opzionali delle risorse della coda del cluster per Kueue. Per fare ciò, modifica la riga in. `controller_manager_config.yaml` `kueue-system` ConfigMap Nella sezione `metrics`, aggiungi o togli il commento dalla riga `enableClusterQueueResources: true`.
```
apiVersion: v1
data:
controller_manager_config.yaml: |
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8080
enableClusterQueueResources: true {{<-- ADD/UNCOMMENT THIS LINE}}
```
1. Per impostazione predefinita, tutti i servizi `k8s` sono disponibili a livello di cluster. Kueue crea un servizio `kueue-controller-manager-metrics-service` per esporre le metriche. Per evitare osservazioni duplicate per le metriche, modifica questo servizio per consentire l'accesso solo al servizio della metrica dallo stesso nodo. Per fare ciò, aggiungi la riga `internalTrafficPolicy: Local` alla definizione `kueue-controller-manager-metrics-service`.
```
apiVersion: v1
kind: Service
metadata:
labels:
...
name: kueue-controller-manager-metrics-service
namespace: kueue-system
spec:
ports:
- name: https
port: 8443
protocol: TCP
targetPort: https
internalTrafficPolicy: Local {{<-- ADD THIS LINE}}
selector:
control-plane: controller-manager
```
1. Infine, il pod `kueue-controller-manager` crea un container `kube-rbac-proxy`. Questo container ha attualmente un alto livello di verbosità di registrazione, il che fa sì che il token bearer del cluster venga registrato da quel container quando lo scraper di metriche accede a `kueue-controller-manager-metrics-service`. Si consiglia di ridurre questa verbosità della registrazione. Il valore predefinito nel manifesto distribuito da Kueue è 10, si consiglia di impostarlo su 0.
```
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
...
name: kueue-controller-manager
namespace: kueue-system
spec:
...
template:
...
spec:
containers:
...
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0 {{<-- CHANGE v=10 TO v=0}}
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
name: kube-rbac-proxy
...
```
### Abilitazione del flag di configurazione
Per abilitare le metriche di Kueue, è necessario abilitare `kueue_container_insights` nella configurazione aggiuntiva del componente aggiuntivo. Puoi farlo utilizzando AWS CLI per configurare il componente aggiuntivo EKS Observability o utilizzando la console Amazon EKS.
**Dopo aver installato correttamente il componente aggiuntivo EKS Observability con uno dei seguenti metodi, puoi visualizzare i parametri del cluster Amazon EKS nella scheda Dashboard della HyperPod console.**
------
#### [ AWS CLI ]
**Per abilitare le metriche Kueue utilizzando il AWS CLI**
+ Immettete il seguente AWS CLI comando per installare il componente aggiuntivo.
```
aws eks create-addon --cluster-name {{cluster-name}} --addon-name amazon-cloudwatch-observability --configuration-values "{{configuration_json_file}}"
```
Di seguito è riportato un esempio del file JSON con i valori di configurazione.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Amazon EKS console ]
**Per abilitare le metriche di Kueue tramite la console Amazon EKS**
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\#/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster.
1. Scegli **Componente aggiuntivo**.
1. Trova il componente aggiuntivo **Amazon CloudWatch Observability** nell'elenco e installalo. Quando lo fai, scegli **Configurazione facoltativa** e includi i seguenti valori di configurazione JSON.
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
## Aggiungere file di configurazione del collettore OpenTelemetry
L' CloudWatch agente supporta file di configurazione dei OpenTelemetry raccoglitori supplementari oltre ai propri file di configurazione. Questa funzionalità consente di utilizzare funzionalità CloudWatch dell'agente come CloudWatch Application Signals o Container Insights tramite la configurazione dell' CloudWatch agente e di inserire la configurazione del OpenTelemetry raccoglitore esistente con un singolo agente.
Per evitare conflitti di fusione con le pipeline create automaticamente dall' CloudWatch agente, si consiglia di aggiungere un suffisso personalizzato a ciascuno dei componenti e delle pipeline nella configurazione del collettore. OpenTelemetry In questo modo si eviteranno scontri e conflitti di unione.
+ Se utilizzi il componente aggiuntivo Amazon CloudWatch Observability EKS
```
--configuration-values file://values.yaml
```
or
```
--configuration-values '
agent:
otelConfig:
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
+ Se stai usando il grafico Helm
```
--set agent.otelConfig='
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
## Abilitazione di APM tramite Application Signals per il tuo cluster Amazon EKS
Per impostazione predefinita, il monitoraggio delle prestazioni delle applicazioni OpenTelemetry (APM) basato su (OTEL) è abilitato tramite Application Signals quando si installa il componente aggiuntivo CloudWatch Observability EKS (V5.0.0 o versione successiva) o il grafico Helm. Puoi personalizzare ulteriormente impostazioni specifiche utilizzando la configurazione avanzata per il componente aggiuntivo Amazon EKS o sovrascrivendo i valori con il grafico Helm.
**Nota**
Se si utilizza una soluzione APM basata su OpenTelemetry (OTEL), l'attivazione di Application Signals influisce sulla configurazione di osservabilità esistente. Rivedi l'implementazione corrente prima di procedere. Per mantenere la configurazione APM esistente dopo l'aggiornamento alla versione 5.0.0 o successiva, consulta. [Disattiva Application Signals](#Opting-out-App-Signals)
**Monitor automatico di Application Signals**
La versione 5.0.0 del componente aggiuntivo CloudWatch Observability Amazon EKS e del grafico Helm introducono nuove funzionalità. Ora puoi abilitare automaticamente Application Signals per tutti o specifici carichi di lavoro di servizio nel tuo cluster EKS tramite la configurazione di Monitor automatico. Le seguenti impostazioni `autoMonitor` possono essere specificate nella sezione `applicationSignals` sotto la sezione `manager` della configurazione avanzata.
+ *monitorAllServices*— Un flag booleano per abilitare (vero) o disabilitare (falso) il monitoraggio di tutti i carichi di lavoro del servizio tramite Auto monitor. Il valore predefinito è true. L'attivazione di questo flag garantirà che tutti i carichi di lavoro Kubernetes (Deployments e StatefulSets) nel cluster mappati su un servizio Kubernetes rientrino nell'ambito dell'abilitazione automatica di Application Signals quando vengono richiamati per la prima volta (o quando vengono riavviati per carichi di lavoro esistenti). DaemonSets Per impostazione predefinita, il sistema esclude i carichi di lavoro nei namespace `kube-system` e `amazon-cloudwatch`.
+ *languages*: un elenco di stringhe che specificano il set di linguaggi con cui Application Signals cercherà di instrumentare automaticamente i tuoi servizi, quando `monitorAllServices` è abilitato. L'impostazione predefinita è tutti i [linguaggi supportati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html).
+ *restartPods*: un flag booleano controlla se i carichi di lavoro vengono riavviati dopo le modifiche alla configurazione. Il valore predefinito è false (falso). L'abilitazione di questo flag su `true` controlla se i carichi di lavoro Kubernetes nell'ambito di Monitor automatico si riavviano automaticamente quando si salvano le modifiche alla configurazione. Verranno prese in considerazione tutte le impostazioni dei carichi di lavoro Kubernetes che influiscono sul riavvio dei pod, ad esempio `updateStrategy`. Tieni presente che il riavvio può causare tempi di inattività del servizio.
+ *customSelector*: impostazioni per selezionare namespace o carichi di lavoro Kubernetes specifici per Monitor automatico.
+ *java*: specifica i carichi di lavoro per l'instrumentazione automatica con Java
+ *python*: specifica i carichi di lavoro per l'instrumentazione automatica con Python
+ *nodejs*: specifica i carichi di lavoro per l'instrumentazione automatica con Node.js
+ *dotnet*: specifica i carichi di lavoro per l'instrumentazione automatica con .NET
Per ciascuno dei linguaggi di cui sopra, è possibile configurare i seguenti campi.
+ *namespaces*: un elenco di stringhe che specifica i namespace da selezionare. Il valore predefinito è un elenco vuoto, ossia []
+ *implementazioni*: un elenco di stringhe che specifica le implementazioni da selezionare. Specifica il valore nel formato `namespace/deployment`. Il valore predefinito è un elenco vuoto, ossia []
+ *daemonsets*: un elenco di stringhe che specifica i daemonsets da selezionare. Specifica il valore nel formato `namespace/daemonset`. Il valore predefinito è un elenco vuoto, ossia []
+ *statefulsets*: un elenco di stringhe che specifica gli statefulsets da selezionare. Specifica il valore nel formato `namespace/statefulset`. Il valore predefinito è un elenco vuoto, ossia []
+ *exclude*: impostazioni per escludere namespace o carichi di lavoro Kubernetes specifici da Monitor automatico. L'esclusione di un carico di lavoro ha la precedenza quando lo stesso carico di lavoro rientra anche nell'ambito di `monitorAllServices` o `customSelector`.
+ *java*: specifica i carichi di lavoro da escludere dall'instrumentazione automatica con Java
+ *python*: specifica i carichi di lavoro da escludere dall'instrumentazione automatica con Python
+ *nodejs*: specifica i carichi di lavoro da escludere dall'instrumentazione automatica con Node.js
+ *dotnet*: specifica i carichi di lavoro da escludere dall'instrumentazione automatica con .NET
Per ciascuno dei linguaggi di cui sopra, è possibile configurare i seguenti campi.
+ *namespaces*: un elenco di stringhe che specifica i namespace da escludere. Il valore predefinito è un elenco vuoto, ossia []
+ *implementazioni*: un elenco di stringhe che specifica le implementazioni da escludere. Specifica il valore nel formato `namespace/deployment`. Il valore predefinito è un elenco vuoto, ossia []
+ *daemonsets*: un elenco di stringhe che specifica i daemonsets da escludere. Specifica il valore nel formato `namespace/daemonset`. Il valore predefinito è un elenco vuoto, ossia []
+ *statefulsets*: un elenco di stringhe che specifica gli statefulsets da escludere. Specifica il valore nel formato `namespace/statefulset`. Il valore predefinito è un elenco vuoto, ossia []
Di seguito è riportato un esempio di configurazione che abilita automaticamente Application Signals per tutti i carichi di lavoro di servizio esistenti e nuovi sul cluster.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
restartPods: true
```
Di seguito è riportato un esempio di configurazione che abilita automaticamente Application Signals per ogni nuovo carico di lavoro di servizio che viene attivato e per qualsiasi carico di lavoro di servizio esistente che viene riavviato in modo esplicito nel cluster.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
```
Di seguito è riportato un esempio di configurazione che abilita automaticamente Application Signals con Java per tutti i pod esistenti e nuovi che corrispondono a un carico di lavoro nel namespace `pet-warehouse`.
```
manager:
applicationSignals:
autoMonitor:
restartPods: true
customSelector:
java:
namespaces: ["pet-warehouse"]
```
Di seguito è riportato un esempio di configurazione che abilita automaticamente Application Signals con Python per tutti i carichi di lavoro di servizio esistenti e nuovi sul cluster, ad eccezione dell'implementazione `pet-clinic`.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["python"]
restartPods: true
exclude:
python:
deployments: ["pet-warehouse/pet-clinic"]
```
Di seguito è riportato un esempio di configurazione che abilita automaticamente Application Signals con Java per tutti i carichi di lavoro di servizio nel cluster, ad eccezione di quelli nel namespace `python-apps`, e inoltre abilita Application Signals con Python specificamente per l'implementazione `sample-python-app` nel namespace `python-apps`.
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["java"]
restartPods: true
customSelector:
python:
deployments: ["python-apps/sample-python-app"]
exclude:
java:
namespaces: ["python-apps"]
```
## Considerazioni per i cluster Kubernetes di grandi dimensioni
Se gestisci cluster Kubernetes di grandi dimensioni, potresti aver bisogno di una configurazione aggiuntiva per garantire che l'agente funzioni in modo affidabile. CloudWatch Le sezioni seguenti descrivono i problemi comuni e le configurazioni consigliate per i cluster di grandi dimensioni.
**Installazioni di agenti separate per metriche a livello di cluster e a livello di nodo**
**Nota**
Questa sezione si applica solo se hai abilitato [Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/container-insights-detailed-metrics.html) con osservabilità avanzata. Se utilizzi [Container Insights esclusivamente con OpenTelemetry metriche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/container-insights-otel-metrics.html), l'installazione predefinita implementa già installazioni di agenti separate.
Per impostazione predefinita, l' CloudWatch agente viene eseguito come demonset su ogni nodo del cluster. Un agente Pod viene eletto leader per raccogliere le metriche a livello di cluster. Queste metriche includono metriche del piano di controllo e metriche dello stato del carico di lavoro. Nei cluster di grandi dimensioni, questo leader Pod può essere interrotto con un errore out-of-memory (OOM) perché esegue attività aggiuntive condividendo gli stessi limiti di risorse di tutti gli altri agenti. Pod
Per determinare se stai riscontrando questo problema, verifica se gli agenti Pod sono in stato di errore indicando il codice di uscita `137` e il motivo. `OOMKilled` Un sintomo comune è che un agente Pod (il leader) si blocca, viene eletto un nuovo leader e Pod anche questo si blocca, creando un ciclo ricorrente. Per confermare questo comportamento, controllate l'elezione del leader ConfigMap eseguendo il seguente comando.
```
kubectl describe configmap cwagent-clusterleader -n amazon-cloudwatch
```
Se ConfigMap mostra modifiche frequenti alla voce del leader, ciò indica che un nuovo leader viene eletto ripetutamente, il che conferma il problema.
Per evitare questo problema, è possibile separare l'agente in due installazioni:
+ Un demonset per metriche a livello di nodo e segnali applicativi
+ Una distribuzione per metriche a livello di cluster
Questa separazione consente di gestire e scalare ogni installazione in modo indipendente.
Per abilitare questa configurazione, utilizzate la configurazione avanzata per definire due voci nella `agents` sezione:
1. Imposta la variabile di `CWAGENT_ROLE` ambiente su `NODE` on the daemonset agent.
1. Imposta la variabile di `CWAGENT_ROLE` ambiente su `LEADER` on the deployment agent.
**Importante**
La configurazione dell'agente di distribuzione deve abilitare solo Container Insights. Non abilitare Application Signals sull'agente di distribuzione. Per impostazione `hostNetwork` predefinita, entrambe le installazioni vengono eseguite con Application Signals e l'attivazione di Application Signals su entrambe causa conflitti di associazione delle porte.
L'esempio seguente mostra una configurazione avanzata che separa l'agente in due installazioni.
```
agents:
- name: cloudwatch-agent
env:
- name: CWAGENT_ROLE
value: NODE
- name: cloudwatch-agent-ci-leader
mode: deployment
config:
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
}
}
}
}
env:
- name: CWAGENT_ROLE
value: LEADER
resources:
limits:
memory: 10Gi
cpu: 2000m
```
In questo esempio, oltre a impostare la variabile di `CWAGENT_ROLE` ambiente su ogni installazione dell'agente, sostituisce la modalità, la configurazione e i limiti di risorse predefiniti solo per l'agente di distribuzione. L'`cloudwatch-agent`installazione di base utilizza le impostazioni predefinite.
È possibile personalizzare ulteriormente l'installazione di ogni agente aggiungendo `nodeSelector` o `nodeAffinity` campi per pianificare il leader Pod su un nodo specifico. `tolerations` I limiti di risorse mostrati nell'esempio precedente sono illustrativi. Modifica questi valori in base alle dimensioni del cluster e al numero di metriche raccolte dal leader. Pod
## Considerazioni per Amazon EKS Hybrid Nodes
Le metriche a livello di nodo non sono disponibili per i nodi ibridi perché [Container Insights](ContainerInsights.md) dipende dalla disponibilità del [servizio di metadati di istanza (IMDS) EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) per le metriche a livello di nodo. Per i nodi ibridi sono disponibili metriche a livello di cluster, Pod, carico di lavoro e container.
Dopo aver installato il componente aggiuntivo, applica una patch alla `amazoncloudwatchagents` risorsa per aggiungere la variabile di `RUN_WITH_IRSA` ambiente in modo che l'agente funzioni correttamente sui nodi ibridi:
```
kubectl patch amazoncloudwatchagents cloudwatch-agent -n amazon-cloudwatch --type=json -p '[{"op":"add","path":"/spec/env/-","value":{"name":"RUN_WITH_IRSA","value":"True"}}]'
```
## Risoluzione dei problemi relativi al componente aggiuntivo Amazon CloudWatch Observability EKS o al diagramma Helm
Utilizza le seguenti informazioni per risolvere i problemi con il componente aggiuntivo Amazon CloudWatch Observability EKS o il grafico Helm
**Topics**
+ [Aggiornamento ed eliminazione del componente aggiuntivo Amazon CloudWatch Observability EKS o del grafico Helm](#EKS-addon-troubleshoot-update)
+ [Verifica la versione dell' CloudWatch agente utilizzato dal componente aggiuntivo Amazon CloudWatch Observability EKS o dal grafico Helm](#EKS-addon-troubleshoot-version)
+ [Gestione di un ConfigurationConflict durante la gestione del componente aggiuntivo o del grafico Helm](#EKS-addon-troubleshoot-conflict)
### Aggiornamento ed eliminazione del componente aggiuntivo Amazon CloudWatch Observability EKS o del grafico Helm
Per istruzioni sull'aggiornamento o l'eliminazione del componente aggiuntivo Amazon CloudWatch Observability EKS, consulta Managing [Amazon](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html) EKS add-on. Usa `amazon-cloudwatch-observability` come nome del componente aggiuntivo.
Per eliminare il grafico Helm in un cluster, immetti il comando seguente.
```
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
```
### Verifica la versione dell' CloudWatch agente utilizzato dal componente aggiuntivo Amazon CloudWatch Observability EKS o dal grafico Helm
Il componente aggiuntivo Amazon CloudWatch Observability EKS e il grafico Helm installano una risorsa personalizzata `AmazonCloudWatchAgent` che controlla il comportamento del daemset dell' CloudWatch agente sul cluster, inclusa la versione dell'agente utilizzata. CloudWatch È possibile ottenere un elenco di tutte le risorse `AmazonCloudWatchAgent` personalizzate installate sul cluster u immettendo il seguente comando:
```
kubectl get amazoncloudwatchagent -A
```
Nell'output di questo comando, dovresti essere in grado di controllare la versione dell'agente. CloudWatch In alternativa, puoi anche descrivere la risorsa `amazoncloudwatchagent` o uno dei pod `cloudwatch-agent-*` in esecuzione sul cluster per ispezionare l'immagine utilizzata.
### Gestione di un ConfigurationConflict durante la gestione del componente aggiuntivo o del grafico Helm
Quando installi o aggiorni il componente aggiuntivo Amazon CloudWatch Observability EKS o il grafico Helm, se noti un errore causato dalle risorse esistenti, probabilmente è perché hai già l' CloudWatch agente e i relativi componenti associati come ServiceAccount, il ClusterRole e il ClusterRoleBinding installato nel cluster.
L'errore visualizzato dal componente aggiuntivo includerà `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`,
L'errore visualizzato dal grafico Helm sarà simile a `Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.`.
Quando il componente aggiuntivo o il grafico Helm tenta di installare l' CloudWatch agente e i componenti associati, se rileva modifiche nei contenuti, per impostazione predefinita fallisce l'installazione o l'aggiornamento per evitare di sovrascrivere lo stato delle risorse sul cluster.
Se stai tentando di effettuare l'onboarding al componente aggiuntivo Amazon CloudWatch Observability EKS e riscontri questo errore, ti consigliamo di eliminare una configurazione di CloudWatch agente esistente che avevi precedentemente installato sul cluster e quindi di installare il componente aggiuntivo EKS o il grafico Helm. Assicurati di eseguire il backup di tutte le personalizzazioni che potresti aver apportato alla configurazione originale dell' CloudWatch agente, ad esempio una configurazione personalizzata dell'agente, e di fornirle al componente aggiuntivo o al diagramma di Helm alla successiva installazione o aggiornamento. Se in precedenza avevi installato l' CloudWatch agente per l'onboarding su Container Insights, consulta per ulteriori informazioni. [Eliminazione dell' CloudWatch agente e di Fluent Bit for Container Insights](ContainerInsights-delete-agent.md)
In alternativa, il componente aggiuntivo supporta un'opzione di configurazione per la risoluzione dei conflitti che può specificare `OVERWRITE`. È possibile utilizzare questa opzione per procedere con l'installazione o l'aggiornamento del componente aggiuntivo sovrascrivendo i conflitti nel cluster. Se utilizzi la console Amazon EKS, trovi il **metodo di risoluzione dei conflitti** selezionando le **impostazioni di configurazione facoltative** quando crei o aggiorni il componente aggiuntivo. Se utilizzi il AWS CLI, puoi fornire il comando `--resolve-conflicts OVERWRITE` al tuo comando per creare o aggiornare il componente aggiuntivo.
## Disattiva Application Signals
Ottimizza le tue preferenze di monitoraggio del servizio nella CloudWatch console o con l'SDK.
Per le versioni precedenti alla 5.0.0, per disabilitare il monitoraggio automatico di Application Signals, segui la procedura seguente:
**Utilizzo di CLI o SDK**
La seguente configurazione può essere applicata come configurazione avanzata al componente aggiuntivo EKS o come sovrascrittura dei valori quando si utilizza il helm chart.
```
{
"manager": {
"applicationSignals": {
"autoMonitor": {
"monitorAllServices": false
}
}
}
}
```
Riavvia i servizi per rendere effettive le modifiche.
**Utilizzo della console**
Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel pannello di navigazione, in **Application Signals (APM)**, scegli **Servizi**.
1. Scegli **Abilita Application Signals** per visualizzare la pagina di abilitazione.
1. Deseleziona la casella di controllo **Auto-Monitor** per ogni servizio che non desideri monitorare.
1. Riavvia i servizi per rendere effettive le modifiche.