Effectuer des analyses historiques avec Cloud Logging

Lorsqu'un pod échoue ou qu'un service ne fonctionne pas comme prévu dans Google Kubernetes Engine (GKE), il est essentiel de comprendre la séquence d'événements qui a conduit au problème. L'inspection de l'état actuel ne suffit pas toujours à trouver la cause première, ce qui rend les données de journaux historiques inestimables.

Cette page vous explique comment utiliser Cloud Logging pour examiner les échecs passés (par exemple, pourquoi un pod n'a pas démarré ou qui a supprimé un déploiement critique) en interrogeant et en analysant les journaux GKE.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme qui doivent effectuer une analyse des causes premières des problèmes à l'échelle du cluster, auditer les modifications et comprendre les tendances du comportement du système. Il est également essentiel pour les développeurs d'applications afin de déboguer les erreurs spécifiques aux applications, de suivre les chemins de requête et de comprendre comment leur code se comporte dans l'environnement GKE au fil du temps. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Comprendre les principaux types de journaux pour le dépannage

Pour vous aider à résoudre les problèmes, Cloud Logging collecte et agrège automatiquement plusieurs types de journaux clés de vos clusters GKE, de vos applications conteneurisées et d'autres servicesGoogle Cloud  :

  • Journaux de nœud et d'exécution (kubelet, containerd) : journaux des services de nœud sous-jacents. Étant donné que kubelet gère le cycle de vie de tous les pods sur le nœud, ses journaux sont essentiels pour résoudre les problèmes tels que les démarrages de conteneurs, les événements de mémoire insuffisante (OOM), les échecs de vérification et les erreurs de montage de volume. Ces journaux sont également essentiels pour diagnostiquer les problèmes au niveau des nœuds, par exemple un nœud dont l'état est NotReady.

    Comme containerd gère le cycle de vie de vos conteneurs, y compris l'extraction d'images, ses journaux sont essentiels pour résoudre les problèmes qui surviennent avant que le kubelet puisse démarrer le conteneur. Les journaux containerd vous aident à diagnostiquer les problèmes au niveau des nœuds dans GKE, car ils documentent les activités spécifiques et les erreurs potentielles du runtime du conteneur.

  • Journaux d'application (stdout, stderr) : flux de sortie et d'erreur standards de vos processus conteneurisés. Ces journaux sont essentiels pour déboguer les problèmes spécifiques à l'application, tels que les plantages, les erreurs ou les comportements inattendus.

  • Journaux d'audit : ces journaux répondent à la question "Qui a fait quoi, où et quand ?" pour votre cluster. Ils permettent de suivre les actions d'administration et les appels d'API effectués sur le serveur d'API Kubernetes, ce qui est utile pour diagnostiquer les problèmes causés par des modifications de configuration ou un accès non autorisé.

Scénarios de dépannage courants

Une fois que vous avez identifié un problème, vous pouvez interroger ces journaux pour savoir ce qui s'est passé. Pour vous aider à vous lancer, l'examen des journaux peut vous aider à résoudre les problèmes suivants :

  • Si un nœud est à l'état NotReady, consultez ses journaux. Les journaux kubelet et containerd révèlent souvent la cause sous-jacente, comme des problèmes de réseau ou des contraintes de ressources.
  • Si un nouveau nœud ne parvient pas à être provisionné ni à rejoindre le cluster, consultez les journaux du port série du nœud. Ces journaux enregistrent l'activité de démarrage anticipé et de démarrage de kubelet avant que les agents de journalisation du nœud ne soient entièrement actifs.
  • Si un pod n'a pas démarré dans le passé, consultez les journaux d'application de ce pod pour vérifier s'il y a eu des plantages. Si les journaux sont vides ou si le pod ne peut pas être planifié, consultez les journaux d'audit pour trouver les événements pertinents ou les journaux de nœud sur le nœud cible pour obtenir des indices sur la pression des ressources ou les erreurs d'extraction d'image.
  • Si un déploiement critique a été supprimé sans que personne ne sache pourquoi, interrogez les journaux d'audit Activité d'administration. Ces journaux peuvent vous aider à identifier le compte d'utilisateur ou de service qui a émis l'appel d'API de suppression, ce qui constitue un point de départ clair pour votre enquête.

Accéder aux journaux

Utilisez l'explorateur de journaux pour interroger, afficher et analyser les journaux GKE dans la console Google Cloud . L'explorateur de journaux fournit de puissantes options de filtrage qui vous aident à isoler votre problème.

Pour accéder à l'explorateur de journaux et l'utiliser, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le volet Requête, saisissez une requête. Utilisez le langage de requête Logging pour rédiger des requêtes ciblées. Voici quelques filtres courants pour vous aider à démarrer :

    Type de filtre Description Exemple de valeur
    resource.type Type de ressource Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id Flux de journaux de la ressource. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtrez les ressources portant un nom spécifique.
     Remplacez RESOURCE_TYPE par le nom de la ressource que vous souhaitez interroger. Par exemple, namespace ou pod.    		 example-namespace-name, example-pod-name
    severity Niveau de gravité du journal. DEFAULT, INFO, WARNING, ERROR et CRITICAL
    jsonPayload.message=~ Recherche par expression régulière d'un texte dans le message de journal. scale.down.error.failed.to.delete.node.min.size.reached

    Par exemple, pour résoudre les problèmes liés à un pod spécifique, vous pouvez isoler ses journaux d'erreurs. Pour n'afficher que les journaux dont la gravité est définie sur ERROR pour ce pod, utilisez la requête suivante :

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Remplacez les éléments suivants :

    • POD_NAME : nom du pod qui rencontre des problèmes.
    • NAMESPACE_NAME : espace de noms dans lequel se trouve le pod. Si vous n'êtes pas sûr de l'espace de noms, consultez la colonne Namespace dans le résultat de la commande kubectl get pods.

    Pour obtenir d'autres exemples, consultez Requêtes liées à Kubernetes dans la documentation Google Cloud Observability.

  3. Cliquez sur Exécuter la requête.

  4. Pour afficher le message de journal complet, y compris la charge utile JSON, les métadonnées et l'horodatage, cliquez sur l'entrée de journal.

Pour en savoir plus sur les journaux GKE, consultez À propos des journaux GKE.

Étapes suivantes