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à. # Risoluzione dei problemi relativi a Container Insights Le seguenti sezioni possono supportare il processo di risoluzione dei problemi relativi a Container Insights. ## Implementazione non riuscita su Amazon EKS o Kubernetes Se l'agente non viene implementato correttamente su un cluster Kubernetes, prova quanto segue: + Per ottenere l'elenco di pod esegui il seguente comando. ``` kubectl get pods -n amazon-cloudwatch ``` + Esegui il comando seguente e controlla gli eventi nella parte inferiore dell'output. ``` kubectl describe pod pod-name -n amazon-cloudwatch ``` + Esegui il comando seguente per controllare i log. ``` kubectl logs pod-name -n amazon-cloudwatch ``` ## Unauthorized panic: Cannot retrieve cadvisor data from kubelet (Operazione non autorizzata: impossibile recuperare i dati cadvisor dal kubelet) Se l'implementazione non riesce e restituisce l'errore `Unauthorized panic: Cannot retrieve cadvisor data from kubelet`, è possibile che per il kubelet non sia stata abilitata la modalità di autorizzazione Webhook. Questa modalità è necessaria per Container Insights. Per ulteriori informazioni, consulta la pagina [Verifica dei prerequisiti per Container Insights in CloudWatch](Container-Insights-prerequisites.md). ## Implementazione di Container Insights su un cluster eliminato e ricreato in Amazon ECS Se elimini un cluster Amazon ECS esistente in cui Container Insights non è abilitato e lo crei nuovamente con lo stesso nome, non puoi abilitare Container Insights su questo nuovo cluster al momento della nuova creazione. Puoi abilitarlo ricreandolo e quindi immettendo il comando seguente: ``` aws ecs update-cluster-settings --cluster myCICluster --settings name=container Insights,value=enabled ``` ## Errore di endpoint non valido Se visualizzi un messaggio di errore simile al seguente, assicurati di aver sostituito tutti i segnaposto, ad esempio *cluster-name* e *region-name* presenti nei comandi che stai utilizzando, con le informazioni corrette per la distribuzione. ``` "log": "2020-04-02T08:36:16Z E! cloudwatchlogs: code: InvalidEndpointURL, message: invalid endpoint uri, original error: &url.Error{Op:\"parse\", URL:\"https://logs.{{region_name}}.amazonaws.com/\", Err:\"{\"}, &awserr.baseError{code:\"InvalidEndpointURL\", message:\"invalid endpoint uri\", errs:[]error{(*url.Error)(0xc0008723c0)}}\n", ``` ## I parametri non vengono visualizzati nella console Se non vedi alcuna metrica di Container Insights in Console di gestione AWS, assicurati di aver completato la configurazione di Container Insights. I parametri vengono visualizzati solo dopo aver completato la configurazione di Container Insights. Per ulteriori informazioni, consulta la pagina [Configurazione di Container Insights](deploy-container-insights.md). ## Parametri dei pod mancanti su Amazon EKS o Kubernetes dopo l'aggiornamento del cluster Questa sezione può essere utile se mancano tutte o alcune metriche del pod dopo aver distribuito l' CloudWatch agente come demonset su un cluster nuovo o aggiornato oppure se viene visualizzato un registro degli errori con il messaggio. `W! No pod metric collected` Questi errori possono essere causati da modifiche nel runtime del container, ad esempio containerd o il driver cgroup systemd docker. Di solito è possibile risolvere questo problema aggiornando il manifesto di implementazione in modo che il socket containerd dall'host sia montato nel container. Fai riferimento al file di esempio seguente: ``` # For full example see https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: cloudwatch-agent namespace: amazon-cloudwatch spec: template: spec: containers: - name: cloudwatch-agent # ... # Don't change the mountPath volumeMounts: # ... - name: dockersock mountPath: /var/run/docker.sock readOnly: true - name: varlibdocker mountPath: /var/lib/docker readOnly: true - name: containerdsock # NEW mount mountPath: /run/containerd/containerd.sock readOnly: true # ... volumes: # ... - name: dockersock hostPath: path: /var/run/docker.sock - name: varlibdocker hostPath: path: /var/lib/docker - name: containerdsock # NEW volume hostPath: path: /run/containerd/containerd.sock ``` ## Nessun parametro dei pod quando si utilizza Bottlerocket per Amazon EKS Bottlerocket è un sistema operativo open source basato su Linux creato appositamente da AWS per eseguire container. Bottlerocket utilizza un percorso `containerd` diverso sull'host, quindi è necessario modificare i volumi nella sua posizione. In caso contrario, verrà visualizzato un messaggio di errore nei log che include `W! No pod metric collected`. Guarda l'esempio seguente. ``` volumes: # ... - name: containerdsock hostPath: # path: /run/containerd/containerd.sock # bottlerocket does not mount containerd sock at normal place # https://github.com/bottlerocket-os/bottlerocket/commit/91810c85b83ff4c3660b496e243ef8b55df0973b path: /run/dockershim.sock ``` ## Nessun parametro del filesystem del container quando si utilizza il runtime containerd per Amazon EKS o Kubernetes Si tratta di un problema noto ed è in fase di elaborazione con il contributo della community. Per ulteriori informazioni, vedere La [metrica di utilizzo del disco per containerd](https://github.com/google/cadvisor/issues/2785) [e Le metriche del file system del contenitore non sono supportate da cadvisor](https://github.com/aws/amazon-cloudwatch-agent/issues/192) for containerd on. GitHub ## Aumento imprevisto del volume di log da parte CloudWatch dell'agente durante la raccolta delle metriche di Prometheus Si tratta di una regressione introdotta nella versione 1.247347.6b250880 dell'agente. CloudWatch Questa regressione è già stata risolta nelle versioni più recenti dell'agente. L'impatto è stato limitato agli scenari in cui i clienti raccoglievano i log dell' CloudWatch agente stesso e utilizzavano anche Prometheus. Per ulteriori informazioni, consulta [[prometheus] L'agente stampa tutte le](https://github.com/aws/amazon-cloudwatch-agent/issues/209) metriche eliminate in log on. GitHub ## Ultima immagine Docker menzionata nelle note di rilascio non trovata da Dockerhub Aggiorniamo la nota di rilascio e il tag su Github prima di avviare internamente la versione effettiva. Di solito ci vogliono 1-2 settimane per vedere l'ultima immagine Docker sui log dopo aver pubblicato il numero di versione su Github. Non è prevista una release notturna per l'immagine del contenitore dell'agente. CloudWatch [È possibile creare l'immagine direttamente dal codice sorgente nella seguente posizione: https://github.com/aws/amazon-cloudwatch-agent/-agent-dockerfile tree/main/amazon-cloudwatch-container-insights/cloudwatch](https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile) ## CrashLoopBackoff errore sull'agente CloudWatch Se vedi un `CrashLoopBackOff` errore relativo all' CloudWatch agente, assicurati che le autorizzazioni IAM siano impostate correttamente. Per ulteriori informazioni, consulta [Verifica dei prerequisiti per Container Insights in CloudWatch](Container-Insights-prerequisites.md). ## CloudWatch agente o pod Fluentd bloccato in sospeso Se hai un CloudWatch agente o un pod Fluentd bloccato `Pending` o con un `FailedScheduling` errore, determina se i tuoi nodi dispongono di risorse di elaborazione sufficienti in base al numero di core e alla quantità di RAM richiesta dagli agenti. Immetti il seguente comando per descrivere il pod: ``` kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch ```