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:

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 Verifica dei prerequisiti per Container Insights in CloudWatch.

Implementazione di Container Insights su un cluster eliminato e ricreato su Amazon ECS

Se elimini un ECS cluster Amazon esistente che non ha Container Insights abilitato e lo ricrei con lo stesso nome, non puoi abilitare Container Insights su questo nuovo cluster nel momento in cui lo crei nuovamente. 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 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

Nessuna metrica del 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

Nessuna metrica del file system dei container quando si utilizza il runtime containerd per Amazon o Kubernetes EKS

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 visualizzi un CrashLoopBackOff errore relativo all' CloudWatch agente, assicurati che le IAM autorizzazioni 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 core richiesta dagli agenti. RAM Immetti il seguente comando per descrivere il pod:

kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch