Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes liés à Container Insights

Les sections suivantes peuvent aider si vous rencontrez des problèmes avec Container Insights.

Échec du déploiement sur Amazon EKS ou Kubernetes

Si l'agent ne se déploie pas correctement sur un cluster Kubernetes, essayez ce qui suit :

Panique non autorisée : Impossible de récupérer les données cadvisor à partir de kubelet

Si votre déploiement échoue avec l'erreur Unauthorized panic: Cannot retrieve cadvisor data from kubelet, il se peut que le mode d'autorisation Webhook ne soit pas activé pour votre Kubelet. Ce mode est obligatoire pour Container Insights. Pour de plus amples informations, veuillez consulter Vérification des conditions requises pour Container Insights dans CloudWatch.

Déploiement de Container Insights sur un cluster supprimé puis recréé sur Amazon ECS

Si vous supprimez un cluster Amazon ECS existant sur lequel Container Insights n'est pas activé et que vous le recréez avec le même nom, vous ne pouvez pas activer Container Insights sur ce nouveau cluster au moment où vous le recréez. Vous pouvez l'activer en le recréant, puis en entrant la commande suivante :

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

Erreur de point de terminaison non valide

Si un message d'erreur similaire au suivant s'affiche, assurez-vous que vous avez remplacé tous les espaces réservés tels que cluster-name et présents region-name dans les commandes que vous utilisez par les informations correctes pour votre déploiement.

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

Les métriques ne s'affichent pas dans la console

Si vous ne voyez aucune métrique de Container Insights dans le AWS Management Console, assurez-vous d'avoir terminé la configuration de Container Insights. Les métriques n'apparaissent pas avant que Container Insights n'ait été configuré complètement. Pour plus d'informations, consultez . Configuration de Container Insights.

Métriques de pod manquantes sur Amazon EKS ou Kubernetes après la mise à niveau du cluster

Cette section peut être utile si toutes les métriques du pod ou certaines d'entre elles sont manquantes après le déploiement de l' CloudWatch agent en tant que daemonset sur un cluster nouveau ou mis à niveau, ou si un journal des erreurs s'affiche avec le message. W! No pod metric collected

Ces erreurs peuvent être causées par des changements dans l'exécution du conteneur, tels que containerd ou le pilote docker systemd cgroup. Vous pouvez généralement résoudre ce problème en mettant à jour votre manifeste de déploiement afin que le socket containerd de l'hôte soit monté dans le conteneur. Consultez l’exemple suivant:

# 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

Aucune métrique de pod lors de l'utilisation de Bottlerocket pour Amazon EKS

Bottlerocket est un système d'exploitation open source basé sur Linux qui est spécialement conçu par AWS pour exécuter des conteneurs.

Bottlerocket utilise un chemin containerd sur l'hôte, vous devez donc modifier les volumes à son emplacement. Dans le cas contraire, une erreur s'affiche dans les journaux qui incluent W! No pod metric collected. Consultez l'exemple suivant.

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

Aucune métrique de FileSystem de conteneur lors de l'utilisation de l'exécution containerd pour Amazon EKS ou Kubernetes

C'est un problème connu et les contributeurs de la communauté travaillent sur cette question. Pour plus d'informations, consultez les sections Métrique d'utilisation du disque pour les containers et Les métriques du système de fichiers conteneur ne sont pas prises en charge par Cadvisor pour containerd on. GitHub

Augmentation inattendue du volume de logs due à l' CloudWatch agent lors de la collecte des métriques Prometheus

Il s'agit d'une régression introduite dans la version 1.247347.6b250880 de l'agent. CloudWatch Cette régression a déjà été corrigée dans les versions plus récentes de l'agent. Son impact s'est limité aux scénarios dans lesquels les clients collectaient les journaux de l' CloudWatch agent lui-même et utilisaient également Prometheus. Pour plus d'informations, voir [prometheus] L'agent imprime toutes les métriques supprimées lors de la connexion. GitHub

Dernière image docker mentionnée dans les notes de mise à jour introuvables depuis Dockerhub

Nous mettons à jour la note de mise à jour et l'identification sur Github avant de démarrer la version réelle en interne. 1 à 2 semaines sont généralement nécessaires pour voir la dernière image docker sur les registres après avoir élevé le numéro de version sur Github. Il n'y a pas de publication nocturne pour l'image du conteneur de l' CloudWatch agent. Vous pouvez créer l'image directement à partir de la source à l'emplacement suivant : https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile

CrashLoopBackoff erreur sur l' CloudWatch agent

Si un CrashLoopBackOff message d'erreur s'affiche pour l' CloudWatch agent, assurez-vous que vos autorisations IAM sont correctement définies. Pour de plus amples informations, veuillez consulter Vérification des conditions requises pour Container Insights dans CloudWatch.

CloudWatch agent ou module Fluentd bloqué en attente

Si un CloudWatch agent ou un pod Fluentd est bloqué Pending ou s'il présente une FailedScheduling erreur, déterminez si vos nœuds disposent de suffisamment de ressources de calcul en fonction du nombre de cœurs et de la quantité de RAM requis par les agents. Entrez la commande suivante pour décrire le pod :

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