Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Risoluzione dei problemi relativi a Container Insights

Modalità Focus
Risoluzione dei problemi relativi a Container Insights - Amazon CloudWatch

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à.

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à.

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.

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 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 AWS Management Console, 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.

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 e Le metriche del file system del contenitore non sono supportate da cadvisor per 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 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

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.

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
PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.