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 : + Exécutez la commande suivante pour obtenir la liste des pods. ``` kubectl get pods -n amazon-cloudwatch ``` + Exécutez la commande suivante et vérifiez les événements au bas de la sortie. ``` kubectl describe pod pod-name -n amazon-cloudwatch ``` + Exécutez la commande suivante pour vérifier les journaux. ``` kubectl logs pod-name -n amazon-cloudwatch ``` ## 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](Container-Insights-prerequisites.md). ## 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](deploy-container-insights.md). ## 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](https://github.com/aws/amazon-cloudwatch-agent/issues/192)](https://github.com/google/cadvisor/issues/2785) 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](https://github.com/aws/amazon-cloudwatch-agent/issues/209) 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](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](Container-Insights-prerequisites.md). ## 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 ```