Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung bei Container Insights

Die folgenden Abschnitte können hilfreich sein, wenn Sie Probleme mit Container Insights haben.

Fehlgeschlagene Bereitstellung auf Amazon EKS oder Kubernetes

Wenn der Agent nicht ordnungsgemäß auf einem Kubernetes-Cluster bereitgestellt wird, versuchen Sie Folgendes:

Nicht autorisierte Panik: Kann keine cadvisor-Daten aus kubelet abrufen

Falls Ihre Bereitstellung mit der Fehlermeldung Unauthorized panic: Cannot retrieve cadvisor data from kubelet fehlschlägt, ist der Webhook-Autorisierungsmodus für kubelet möglicheweise nicht aktiviert. Dieser Modus ist für Container Insights erforderlich. Weitere Informationen finden Sie unter Überprüfung der Voraussetzungen für Container Insights in CloudWatch.

Bereitstellung von Container Insights auf einem gelöschten und neu erstellten Cluster auf Amazon ECS

Wenn Sie einen vorhandenen ECS Amazon-Cluster löschen, für den Container Insights nicht aktiviert ist, und Sie ihn mit demselben Namen neu erstellen, können Sie Container Insights für diesen neuen Cluster nicht aktivieren, wenn Sie ihn neu erstellen. Sie können es aktivieren, indem Sie ihn neu erstellen und dann den folgenden Befehl eingeben:

aws ecs update-cluster-settings --cluster myCICluster --settings name=containerInsights,value=enabled

„Ungültiger Endpunkt“-Fehler

Wenn Sie eine Fehlermeldung ähnlich der folgenden sehen, überprüfen Sie, ob Sie alle Platzhalter ersetzt haben, z. B. cluster-name and region-name in den Befehlen, die Sie verwenden, mit den richtigen Informationen für Ihre Bereitstellung.

"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",

Metriken erscheinen nicht in der Konsole

Wenn Sie in der keine Container Insights-Metriken sehen AWS Management Console, stellen Sie sicher, dass Sie die Einrichtung von Container Insights abgeschlossen haben. Metriken werden erst angezeigt, wenn Container Insights vollständig eingerichtet wurde. Weitere Informationen finden Sie unter Einrichten von Container Insights.

Pod-Metriken fehlen auf Amazon EKS oder Kubernetes nach dem Upgrade des Clusters

Dieser Abschnitt kann nützlich sein, wenn alle oder einige Pod-Metriken fehlen, nachdem Sie den CloudWatch Agenten als Daemonset auf einem neuen oder aktualisierten Cluster bereitgestellt haben, oder wenn Sie ein Fehlerprotokoll mit der Meldung sehen. W! No pod metric collected

Diese Fehler können durch Änderungen in der Container-Laufzeitumgebung verursacht werden, z. B. containerd oder den „docker systemd cgroup“-Treiber. Sie können dies normalerweise lösen, indem Sie Ihr Bereitstellungsmanifest aktualisieren, sodass der containerd-Socket vom Host in den Container gemountet wird. Sehen Sie sich das folgende Beispiel an:

# 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

Keine Pod-Metriken bei der Verwendung von Bottlerocket für Amazon EKS

Bottlerocket ist ein Linux-basiertes Open-Source-Betriebssystem, das von AWS für das Ausführen von Container erstellt wurde.

Bottlerocket verwendet einen anderen containerd-Pfad auf dem Host, daher müssen Sie die Volumes an ihren Speicherort ändern. Wenn Sie dies nicht tun, wird in den Protokollen ein Fehler angezeigt, der W! No pod metric collected enthält. Sehen Sie sich das folgende -Beispiel an.

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

Keine Container-Dateisystem-Metriken bei Verwendung der containerd-Laufzeit für Amazon EKS oder Kubernetes

Dies ist ein bekanntes Problem und wird von Community-Mitwirkenden bearbeitet. Weitere Informationen finden Sie unter Metrik zur Festplattennutzung für containerd und Container-Dateisystemmetriken werden von cadvisor für containerd on nicht unterstützt. GitHub

Unerwarteter Anstieg des Protokollvolumens durch den CloudWatch Agenten beim Sammeln von Prometheus-Metriken

Dies war eine Regression, die in Version 1.247347.6b250880 des Agenten eingeführt wurde. CloudWatch Diese Regression wurde bereits in neueren Versionen des Agenten behoben. Die Auswirkungen beschränkten sich auf Szenarien, in denen Kunden die Protokolle des CloudWatch Agenten selbst sammelten und auch Prometheus verwendeten. Weitere Informationen finden Sie unter [prometheus] Agent druckt alle gesammelten Metriken bei der Anmeldung aus. GitHub

Neueste Docker-Image, das in Versionshinweisen erwähnt wurde, die nicht von Dockerhub gefunden wurden

Wir aktualisieren die Versionshinweise und das Tag auf Github, bevor wir die eigentliche Veröffentlichung intern starten. In der Regel dauert es 1-2 Wochen, um das neueste Docker-Image in Registries zu sehen, nachdem wir die Versionsnummer auf Github stoßen. Es gibt keine nächtliche Veröffentlichung für das Agenten-Container-Image. CloudWatch Sie können das Image direkt aus der Quelle am folgenden Speicherort erstellen: https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile

CrashLoopBackoff Fehler auf dem Agenten CloudWatch

Wenn Sie einen CrashLoopBackOff Fehler für den CloudWatch Agenten sehen, stellen Sie sicher, dass Ihre IAM Berechtigungen richtig eingestellt sind. Weitere Informationen finden Sie unter Überprüfung der Voraussetzungen für Container Insights in CloudWatch.

CloudWatch Der Agent oder der Fluentd-Pod bleiben im Status „Ausstehend“ hängen

Wenn ein CloudWatch Agent oder Fluentd-Pod nicht mehr funktioniert Pending oder ein FailedScheduling Fehler auftritt, stellen Sie anhand der Anzahl der Kerne und der Menge der von den Agenten RAM benötigten Rechenressourcen fest, ob Ihre Knoten über genügend Rechenressourcen verfügen. Geben Sie den folgenden Befehl ein, um den Pod zu beschreiben:

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