Résoudre les problèmes de journaux manquants dans GKE

Les problèmes liés au pipeline de journalisation dans Google Kubernetes Engine (GKE) peuvent empêcher l'affichage des journaux de votre cluster dans Cloud Logging, ce qui entrave vos efforts de surveillance et de débogage.

Ce document vous explique comment vérifier les configurations et les autorisations, résoudre les problèmes de ressources et de performances, examiner les filtres et le comportement des applications, et résoudre les problèmes de plate-forme ou de service qui affectent vos journaux.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme qui gèrent l'observabilité des clusters, ainsi que pour tous ceux qui utilisent Cloud Logging pour résoudre les problèmes liés aux opérations GKE. 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.

Pour en savoir plus sur l'utilisation des journaux pour résoudre les problèmes liés à vos charges de travail et clusters, consultez Effectuer une analyse historique avec Cloud Logging.

Trouver votre solution par symptôme

Si vous avez identifié un symptôme spécifique lié à vos journaux manquants, consultez le tableau suivant pour obtenir des conseils de dépannage :

Catégorie Symptôme ou observation Cause possible Procédure de dépannage
Configuration Aucun journal d'aucun cluster du projet n'est visible. L'API Cloud Logging est désactivée pour le projet. Vérifier l'état de l'API Cloud Logging
Il manque des journaux pour un cluster spécifique ou seuls certains types de journaux sont manquants. La journalisation au niveau du cluster est désactivée pour les types de journaux requis. Vérifier la configuration de la journalisation du cluster
Il manque des journaux dans les nœuds d'un pool de nœuds spécifique. Les nœuds du pool de nœuds ne disposent pas du champ d'application requis. Vérifier les niveaux d'accès du pool de nœuds
Des erreurs d'autorisation (401 ou 403) s'affichent dans les journaux de l'agent Logging. Le compte de service du nœud ne dispose pas de l'autorisation requise. Vérifier les autorisations du compte de service du nœud
Ressources et performances Les journaux sont manquants par intermittence ou des erreurs RESOURCE_EXHAUSTED s'affichent. Le projet dépasse le quota d'écriture de l'API Cloud Logging. Examiner l'utilisation des quotas de l'API Cloud Logging
Il manque des journaux d'un nœud spécifique, souvent en cas de trafic ou de charge élevés. Le nœud dépasse les limites de débit de l'agent Logging ou manque de ressources (processeur ou mémoire) pour traiter les journaux. Examiner le débit des nœuds et l'utilisation des ressources
Filtrage et comportement de l'application Des journaux spécifiques correspondant à un certain modèle sont systématiquement manquants. Un filtre d'exclusion de journaux dans Cloud Logging supprime involontairement les journaux. Examiner les filtres d'exclusion de journaux
Les journaux d'un conteneur sont considérablement retardés ou n'apparaissent qu'après la fermeture du conteneur. La sortie de l'application est entièrement mise en mémoire tampon, souvent en raison du piping stdout. Examiner la mise en mémoire tampon et les retards des journaux de conteneur
Les journaux attendus n'apparaissent pas dans les résultats de recherche. Les filtres de requête dans l'explorateur de journaux sont peut-être trop restrictifs. Examiner les requêtes de l'explorateur de journaux
Aucun journal n'est visible à partir d'un pod d'application spécifique, mais d'autres journaux de cluster sont présents. L'application à l'intérieur du conteneur n'écrit pas dans stdout ni dans stderr. Examiner le comportement de journalisation spécifique à l'application
Plate-forme et service Les journaux datant d'avant une certaine date n'apparaissent pas. Les journaux ont dépassé leur période de conservation et ont été supprimés par Cloud Logging. Examiner les périodes de conservation des journaux
Perte ou retard généralisés des journaux dans les projets ou les clusters. Problème lié au service Cloud Logging ou retard d'ingestion. Examiner les problèmes et les retards liés au service Cloud Logging
Les problèmes de journalisation coïncident avec les limites de la version du cluster. Version de GKE non compatible. Examiner la version du cluster

Utiliser des outils de diagnostic automatisés

Les sections suivantes présentent des outils qui peuvent inspecter automatiquement votre cluster pour détecter les erreurs de configuration courantes et vous aider à résoudre les problèmes complexes.

Résoudre les problèmes de journalisation GKE avec gcpdiag

Si vous ne recevez pas de journaux à partir de votre cluster GKE ou si ceux-ci sont incomplets, utilisez l'outil gcpdiag pour le dépannage.

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud officiellement pris en charge. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, consultez le projet gcpdiag sur GitHub.

Lorsque les journaux du cluster GKE sont manquants ou incomplets, examinez les causes potentielles en vous concentrant sur les paramètres de configuration de base suivants :

  • Journalisation au niveau du projet : permet de s'assurer que l'API Cloud Logging est activée dans le projet Google Cloudqui héberge le cluster GKE.
  • Journalisation au niveau du cluster : permet de vérifier que la journalisation est explicitement activée dans la configuration du cluster GKE.
  • Autorisations du pool de nœuds : permet de confirmer que les nœuds des pools de nœuds du cluster ont bien le champ d'application Cloud Logging Write activé, ce qui leur permet d'envoyer des données de journal.
  • Autorisations du compte de service : permet de valider le fait que le compte de service utilisé par les pools de nœuds dispose des autorisations IAM nécessaires pour interagir avec Cloud Logging. Plus précisément, le rôle roles/logging.logWriter est généralement requis.
  • Quotas d'écriture de l'API Cloud Logging : permet de vérifier que les quotas d'écriture de l'API Cloud Logging n'ont pas été dépassés dans le délai spécifié.

ConsoleGoogle Cloud

  1. Terminez l'exécution, puis copiez la commande suivante. 
    2. gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION
  2. Ouvrez la console Google Cloud et activez Cloud Shell.
    3. Ouvrir la console Cloud
  3. Collez la commande copiée.
  4. Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

  1. Copiez et exécutez la commande suivante sur votre station de travail locale.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Exécutez la commande gcpdiag. 
    ./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet contenant la ressource.
  • CLUSTER_NAME : nom du cluster GKE.
  • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

Options utiles :

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Utiliser les investigations Gemini Cloud Assist

Envisagez d'utiliser les investigations Gemini Cloud Assist pour dégager des insights supplémentaires de vos journaux afin d'être en mesure de résoudre les problèmes. Pour en savoir plus sur les différentes façons de lancer une investigation à l'aide de l'explorateur de journaux, consultez Résoudre les problèmes à l'aide des investigations Gemini Cloud Assist dans la documentation Gemini.

Vérifier la configuration de la journalisation et les autorisations

Des paramètres incorrects sont une cause fréquente de journaux GKE manquants. Utilisez les sections suivantes pour vérifier votre configuration Cloud Logging.

Vérifier l'état de l'API Cloud Logging

Pour que les journaux soient collectés à partir de n'importe quel cluster de votre projet, l'API Cloud Logging doit être active.

Symptômes :

Aucun journal provenant de ressources GKE de votre projet n'est visible dans Cloud Logging.

Cause :

L'API Cloud Logging est désactivée pour le projet Google Cloud , ce qui empêche l'agent Logging sur les nœuds d'envoyer des journaux.

Solution :

Pour vérifier que l'API Cloud Logging est activée et l'activer si nécessaire, sélectionnez l'une des options suivantes :

Console

  1. Dans la console Google Cloud , accédez à la page API et services activés.

    Accéder à la page "API et services activés"

  2. Dans le champ Filtrer, saisissez Cloud Logging API, puis appuyez sur Entrée.

  3. Si l'API est activée, elle apparaît dans la liste. Si l'API ne figure pas dans la liste, activez-la :

    1. Cliquez sur Activer les API et les services.
    2. Dans le champ Rechercher, saisissez Cloud Logging API, puis appuyez sur Entrée.
    3. Cliquez sur le résultat API Cloud Logging.
    4. Cliquez sur Activer.

gcloud

  1. Vérifiez si l'API est activée :

    gcloud services list --enabled --filter="NAME=logging.googleapis.com"

    La sortie doit ressembler à l'exemple suivant :

    NAME: logging.googleapis.com
TITLE: Cloud Logging API

  2. Si l'API ne figure pas dans la liste des services activés, activez-la :

    gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet Google Cloud.

Vérifier la configuration de la journalisation du cluster

GKE vous permet de configurer les types de journaux (tels que SYSTEM ou WORKLOAD) collectés à partir d'un cluster.

Symptômes :

Aucun journal n'apparaît dans Cloud Logging à partir d'un cluster GKE spécifique, ou seuls certains types de journaux (comme SYSTEM) sont manquants.

Cause :

La journalisation au niveau du cluster est désactivée pour les types de journaux requis. Si vous utilisez un cluster Autopilot, ce n'est pas la cause de vos problèmes de journalisation. Ce paramètre est configurable pour les clusters Standard, mais il est toujours activé par défaut sur les clusters Autopilot et ne peut pas être désactivé.

Solution :

Pour vérifier et mettre à jour la configuration de journalisation du cluster, sélectionnez l'une des options suivantes :

Console

  1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster que vous souhaitez examiner.

  3. Cliquez sur l'onglet Détails, puis accédez à la section Fonctionnalités.

  4. Dans la ligne Journalisation, vérifiez les types de journaux activés, tels que Système ou Charges de travail.

  5. Si les types de journaux que vous souhaitez collecter sont désactivés ou incorrects, cliquez sur Modifier la journalisation.

  6. Dans la liste Composants, cochez les cases correspondant aux types de journaux que vous souhaitez collecter, puis cliquez sur OK. Pour en savoir plus sur les types de journaux disponibles, consultez À propos des journaux GKE.

  7. Cliquez sur Enregistrer les modifications.

gcloud

  1. Pour vérifier la configuration de la journalisation, décrivez le cluster :

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
    • PROJECT_ID : ID de votre projet Google Cloud .

    Si la journalisation est activée, le résultat est semblable à ce qui suit :

    example-cluster    SYSTEM_COMPONENTS;WORKLOADS

    Si le résultat est NONE, cela signifie que la journalisation est désactivée.

  2. Si les types de journaux souhaités sont désactivés ou incorrects, mettez à jour la configuration de la journalisation :

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE

    Remplacez LOGGING_TYPE par SYSTEM, WORKLOAD ou les deux. Pour collecter des journaux, SYSTEM doit être activé. Les journaux WORKLOAD ne peuvent pas être collectés seuls. Pour en savoir plus sur les types de journaux disponibles, consultez À propos des journaux GKE.

Vérifier les niveaux d'accès du pool de nœuds

Les nœuds d'un cluster GKE utilisent des niveaux d'accès OAuth pour obtenir l'autorisation d'interagir avec les API Google Cloud , y compris Cloud Logging.

Symptômes :

Il manque des journaux pour les nœuds d'un pool de nœuds spécifique.

Cause :

Les nœuds du pool de nœuds ne disposent pas du champ d'application OAuth nécessaire. L'un des champs d'application suivants est nécessaire pour que les nœuds puissent écrire des journaux dans Cloud Logging :

  • https://www.googleapis.com/auth/logging.write : accorde l'autorisation d'écrire des journaux. Il s'agit du champ d'application minimal requis.
  • https://www.googleapis.com/auth/logging.admin : accorde un accès complet à l'API Cloud Logging, y compris les autorisations de logging.write.
  • https://www.googleapis.com/auth/cloud-platform : accorde un accès complet à toutes les API Google Cloud activées, y compris les autorisations de logging.write.

Solution :

Pour vérifier les autorisations et accorder les rôles requis s'ils manquent, sélectionnez l'une des options suivantes :

Console

  1. Vérifiez les niveaux d'accès du pool de nœuds :

    1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

      Accéder à la page "Clusters Kubernetes"

    2. Pour ouvrir la page d'informations du cluster, cliquez sur le nom du cluster que vous souhaitez examiner.

    3. Cliquez sur l'onglet Nœuds.

    4. Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez examiner.

    5. Accédez à la section Sécurité.

    6. Examinez les niveaux d'accès listés dans le champ Niveaux d'accès. Assurez-vous qu'au moins un des niveaux d'accès requis est présent :

      • API Stackdriver Logging : écriture seule
      • API Stackdriver Logging – Complet
      • Cloud Platform : activé

      Si les niveaux d'accès requis sont manquants, recréez le pool de nœuds. Vous ne pouvez pas modifier les niveaux d'accès sur un pool de nœuds existant.

  2. Si nécessaire, créez un pool de nœuds avec le champ d'application requis :

    1. Revenez à la page "Détails du cluster" pour le cluster que vous souhaitez modifier.
    2. Cliquez sur l'onglet Nœuds.
    3. Cliquez sur Créer un pool de nœuds géré par l'utilisateur.
    4. Remplissez la section Détails du pool de nœuds.
    5. Dans le panneau de navigation de gauche, cliquez sur Sécurité.
    6. Dans la section Niveaux d'accès, sélectionnez les rôles que vous souhaitez ajouter :
      • Pour ajouter des niveaux d'accès spécifiques, sélectionnez Définir l'accès pour chaque API.
      • Pour autoriser l'accès complet, sélectionnez Autoriser l'accès complet à l'ensemble des API Cloud.
    7. Configurez les autres sections si nécessaire.
    8. Cliquez sur Créer.

  3. Migrez vos charges de travail vers le nouveau pool de nœuds. Une fois que vous avez migré les charges de travail vers le nouveau pool de nœuds, vos applications s'exécutent sur des nœuds disposant des champs d'application nécessaires pour envoyer des journaux à Cloud Logging.

  4. Supprimez l'ancien pool de nœuds :

    1. Revenez à la page "Détails du cluster" et sélectionnez l'onglet Nœuds.
    2. Dans la section Pools de nœuds, recherchez l'ancien pool de nœuds.
    3. À côté du pool de nœuds, cliquez sur Supprimer .
    4. Lorsque vous y êtes invité, confirmez la suppression en saisissant le nom du pool de nœuds, puis cliquez sur Supprimer.

gcloud

  1. Vérifiez les niveaux d'accès du pool de nœuds :

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
    • PROJECT_ID : ID de votre projet Google Cloud .

    Examinez le résultat pour chaque pool de nœuds. Assurez-vous qu'au moins l'une des portées requises (https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/cloud-platform ou https://www.googleapis.com/auth/logging.admin) est listée. Si les niveaux d'accès requis sont manquants, recréez le pool de nœuds. Vous ne pouvez pas modifier les niveaux d'accès sur un pool de nœuds existant.

  2. Si nécessaire, créez un pool de nœuds avec le champ d'application requis :

    gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES

    Remplacez les éléments suivants :

    • NEW_NODE_POOL_NAME : nom du nouveau pool de nœuds.
    • OTHER_SCOPES : liste des autres niveaux d'accès dont vos nœuds ont besoin, séparés par une virgule. Si vous n'avez pas besoin d'autres niveaux d'accès, supprimez cet espace réservé et la virgule qui le précède.

  3. Migrez vos charges de travail vers le nouveau pool de nœuds. Une fois que vous avez migré les charges de travail vers le nouveau pool de nœuds, vos applications s'exécutent sur des nœuds disposant des champs d'application nécessaires pour envoyer des journaux à Cloud Logging.

  4. Supprimez l'ancien pool de nœuds :

    gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Vérifier les autorisations du compte de service de nœud

Les nœuds utilisent un compte de service pour s'authentifier auprès des services Google Cloud . Ce compte a besoin d'autorisations IAM spécifiques pour écrire des journaux.

Symptômes :

  • Il manque des journaux dans les nœuds.
  • L'inspection des journaux de l'agent Logging (par exemple, Fluent Bit) peut afficher des erreurs liées aux autorisations, telles que les codes 401 ou 403 lors de la tentative d'écriture dans Cloud Logging.
  • Une notification Grant Critical Permissions to Node Service Account peut s'afficher pour le cluster dans la console Google Cloud .

Cause :

Le compte de service utilisé par les nœuds du pool de nœuds ne dispose pas des autorisations IAM nécessaires pour écrire des journaux dans Cloud Logging. Les nœuds nécessitent un compte de service avec le rôle logging.logWriter, qui inclut l'autorisation logging.logEntries.create.

De plus, pour les versions 1.33 ou ultérieures de GKE, l'agent de service de nœud par défaut GKE (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com) doit disposer au minimum du rôle d'agent de service de nœud par défaut Kubernetes (roles/container.defaultNodeServiceAgent). Ce rôle permet à GKE de gérer les ressources et les opérations des nœuds, y compris les composants de journalisation.

Solution :

Pour vérifier les autorisations et accorder les rôles requis s'ils manquent, procédez comme suit :

  • Vérifiez l'autorisation du compte de service du nœud.
  • Vérifiez que l'agent de service GKE dispose du rôle requis.

Vérifier l'autorisation du compte de service de nœud

Le compte de service de nœud est le compte utilisé par votre nœud pour s'authentifier et envoyer des journaux. Pour identifier ce compte de service et vérifier qu'il dispose de l'autorisation roles/logging.logWriter requise, procédez comme suit :

  1. Pour identifier le compte de service utilisé par le pool de nœuds, sélectionnez l'une des options suivantes :

    Console

    1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

      Accéder à la page "Clusters Kubernetes"

    2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez inspecter.

    3. Selon le mode de fonctionnement du cluster, effectuez l'une des opérations suivantes :

      • Pour les clusters standards, procédez comme suit :

        1. Cliquez sur l'onglet Nœuds.
        2. Dans la table Pools de nœuds, cliquez sur le nom d'un pool de nœuds. La page "Détails du pool de nœuds" s'ouvre.
        3. Dans la section Sécurité, recherchez le champ Compte de service.

      • Pour les clusters Autopilot, procédez comme suit :

        1. Accédez à l'onglet Détails.
        2. Dans la section Sécurité, recherchez le champ Compte de service.

      Si la valeur du champ Compte de service est default, vos nœuds utilisent le compte de service Compute Engine par défaut. Si la valeur de ce champ n'est pas default, vos nœuds utilisent un compte de service personnalisé. Pour attribuer le rôle requis à un compte de service personnalisé, consultez Utiliser le principe du moindre privilège pour les comptes de service IAM.

    gcloud

    Exécutez la commande suivante, en fonction du type de cluster que vous utilisez :

    Clusters standards 

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(config.serviceAccount)"

    Remplacez les éléments suivants :

    • NODE_POOL_NAME : nom du pool de nœuds.
    • CLUSTER_NAME : nom de votre cluster Standard.
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
    • PROJECT_ID : ID de votre projet Google Cloud.

    Si le résultat est default, le pool de nœuds utilise le compte de service Compute Engine par défaut. Si la valeur n'est pas default, vos nœuds utilisent un compte de service personnalisé. Pour attribuer le rôle requis à un compte de service personnalisé, consultez Utiliser le principe du moindre privilège pour les comptes de service IAM.

    Clusters Autopilot 

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom de votre cluster Autopilot.
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
    • PROJECT_ID : ID de votre projet Google Cloud .

    Si le résultat est default, le pool de nœuds utilise le compte de service Compute Engine par défaut. Si la valeur n'est pas default, vos nœuds utilisent un compte de service personnalisé. Pour attribuer le rôle requis à un compte de service personnalisé, consultez Utiliser le principe du moindre privilège pour les comptes de service IAM.

    Pour obtenir des scripts plus détaillés permettant d'identifier les autorisations manquantes, consultez Identifier tous les comptes de service de nœud auxquels il manque des autorisations.

  2. GKE recherche automatiquement les autorisations manquantes et fournit des recommandations. Pour utiliser les recommandations afin de vérifier si des autorisations sont manquantes, sélectionnez l'une des options suivantes :

    Console

    1. Sur la page Clusters Kubernetes, recherchez la colonne Notifications.
    2. Dans la colonne Notifications, recherchez la recommandation Accorder des autorisations critiques. Cette recommandation signifie que le contrôle NODE_SA_MISSING_PERMISSIONS a échoué.
    3. Si la recommandation est présente, cliquez dessus. Un panneau de détails s'ouvre, expliquant les autorisations manquantes et fournissant les étapes à suivre pour résoudre le problème.

    gcloud

    1. Lister les recommandations pour les autorisations de compte de service manquantes :

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analysez le résultat de la commande :

      • Si la commande renvoie une liste vide, cela signifie que le système de recommandation n'a trouvé aucune recommandation NODE_SA_MISSING_PERMISSIONS active. Les comptes de service qu'il a vérifiés semblent disposer des autorisations requises.

      • Si la commande renvoie un ou plusieurs blocs YAML, cela signifie que le moteur de recommandation a identifié un problème d'autorisation. Examinez le résultat pour les champs clés suivants :

        • description : fournit un résumé du problème, par exemple en indiquant que votre compte de service de nœud ne dispose pas du rôle roles/logging.logWriter ou que l'agent de service GKE ne dispose pas du rôle roles/container.defaultNodeServiceAgent.
        • resource : spécifie le cluster concerné.
        • content.operations : contient la résolution recommandée. Cette section fournit la commande gcloud projects add-iam-policy-binding exacte requise pour accorder le rôle spécifique manquant.

    Il peut s'écouler jusqu'à 24 heures avant que les modifications récentes ne soient reflétées dans le système de recommandation.

  3. Si vous souhaitez vérifier les autorisations immédiatement, sélectionnez l'une des options suivantes pour vérifier les autorisations et attribuer le rôle :

    Console

    1. Dans la console Google Cloud , accédez à la page IAM.

      Accéder à IAM

    2. Recherchez le compte de service utilisé par le pool de nœuds.

    3. Dans la colonne Rôle, vérifiez si le compte de service dispose du rôle Rédacteur de journaux (roles/logging.logWriter).

    4. Si l'autorisation est manquante, ajoutez-la :

      1. Cliquez sur Modifier le compte principal.
      2. Cliquez sur Ajouter un autre rôle.
      3. Dans le champ de recherche, saisissez Logs Writer.
      4. Cochez la case Rédacteur de journaux, puis cliquez sur Appliquer.
      5. Cliquez sur Enregistrer.

    gcloud

    1. Vérifiez les rôles actuels du compte de service de nœud :

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

    2. Si elle est absente, attribuez le rôle logging.logWriter :

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

Vérifier les autorisations de l'agent de service GKE

Si les journaux sont toujours manquants et que vous utilisez la version 1.33 ou ultérieure, vérifiez que l'agent géré par Google que GKE utilise pour gérer les composants de vos nœuds dispose de l'autorisation requise :

  1. Pour identifier l'adresse e-mail de l'agent de service, obtenez le numéro de votre projet :

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    en remplaçant PROJECT_ID par l'ID de votre projet. Notez le résultat.

    L'adresse e-mail de l'agent de service GKE est la suivante : service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

  2. Pour utiliser les recommandations afin de vérifier si des autorisations sont manquantes, sélectionnez l'une des options suivantes :

    Console

    1. Sur la page Clusters Kubernetes, recherchez la colonne Notifications.
    2. Recherchez la recommandation Accorder des autorisations critiques dans la colonne.
    3. Si la recommandation est présente, cliquez dessus. Un panneau de détails s'ouvre, expliquant les autorisations manquantes et fournissant les étapes à suivre pour résoudre le problème.

    gcloud

    1. Lister les recommandations pour les autorisations de compte de service manquantes :

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analysez le résultat de la commande. Examinez le résultat pour obtenir une description indiquant que l'agent de service GKE (gcp-sa-gkenode) ne dispose pas du rôle roles/container.defaultNodeServiceAgent.

  3. Pour vérifier immédiatement les autorisations et accorder le rôle, sélectionnez l'une des options suivantes :

    Console

    1. Dans la console Google Cloud , accédez à la page IAM.

      Accéder à IAM

    2. Dans le champ Filtrer , saisissez l'adresse e-mail de l'agent de service GKE, puis appuyez sur Entrée.

    3. Dans la liste filtrée, vérifiez si l'agent de service dispose au moins du rôle Agent de service de nœud par défaut Kubernetes (roles/container.defaultNodeServiceAgent).

    4. Si le rôle est manquant, attribuez-le :

      1. Cliquez sur Modifier le compte principal à côté de l'agent de service.
      2. Cliquez sur Ajouter des rôles.
      3. Dans le champ de recherche, saisissez Kubernetes Default Node Service Agent et sélectionnez le rôle.
      4. Cliquez sur Enregistrer.

    gcloud

    1. Vérifiez si le rôle roles/container.defaultNodeServiceAgent est associé à l'agent de service :

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com"

      Dans le résultat, recherchez roles/container.defaultNodeServiceAgent.

    2. Si le rôle est manquant, attribuez le rôle d'agent de service de nœud par défaut Kubernetes :

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAgent"

Résoudre les problèmes de ressources et de performances

Si des journaux sont manquants de manière intermittente ou supprimés des nœuds à fort trafic, la cause peut ne pas être une erreur de configuration, mais un problème de performances. Utilisez les sections suivantes pour déterminer si votre projet dépasse les quotas d'API ou si le volume de journaux élevé submerge les agents sur des nœuds spécifiques.

Examiner l'utilisation du quota de l'API Cloud Logging

Pour protéger le service, Cloud Logging applique un quota d'écriture à tous les projets, ce qui limite le volume total de journaux que Cloud Logging peut ingérer par minute.

Symptômes :

  • Les journaux sont manquants de manière intermittente ou complète.
  • Des erreurs RESOURCE_EXHAUSTED liées à logging.googleapis.com s'affichent dans les journaux de nœud ou de l'agent de journalisation.

Cause :

Le projet dépasse le quota de requêtes en écriture de l'API Cloud Logging. Ce problème empêche l'agent Logging d'envoyer des journaux.

Solution :

Pour vérifier l'utilisation du quota et demander une augmentation, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Quotas.

    Accéder à Quotas

  2. Dans le champ Filtrer, saisissez Cloud Logging API, puis appuyez sur Entrée.

  3. Dans la liste filtrée, recherchez le quota Octets écrits dans les journaux par minute et par région pour la région dans laquelle se trouve votre cluster.

  4. Examinez les valeurs de la colonne Pourcentage d'utilisation actuel. Si l'utilisation est à la limite ou presque, vous avez probablement dépassé le quota.

  5. Pour demander une augmentation, cliquez sur Modifier le quota, puis suivez les instructions. Pour en savoir plus, consultez la page Afficher et gérer les quotas.

Pour réduire l'utilisation, envisagez d'exclure les journaux ou de réduire le niveau de détail des journaux des applications. Vous pouvez également configurer des règles d'alerte pour être averti avant d'atteindre la limite.

Examiner le débit des nœuds et l'utilisation des ressources

L'agent Logging GKE sur chaque nœud a sa propre limite de débit, qui peut être dépassée.

Symptômes :

Les journaux de certains nœuds sont manquants ou retardés par intermittence, en particulier pendant les périodes d'activité élevée du cluster ou d'utilisation intensive des ressources des nœuds.

Cause :

L'agent de journalisation GKE possède une limite de débit par défaut (environ 100 Ko/s par nœud). Si les applications d'un nœud génèrent des journaux plus rapidement que cette limite, l'agent peut supprimer des journaux, même si le quota d'API global du projet n'est pas dépassé. Vous pouvez surveiller le débit de journalisation des nœuds à l'aide de la métrique kubernetes.io/node/logs/input_bytes dans l'explorateur de métriques.

Il est également possible que des journaux soient manquants si le nœud est soumis à une forte pression sur le processeur ou la mémoire, ce qui laisse des ressources insuffisantes à l'agent pour traiter les journaux.

Solution :

Pour réduire le débit, sélectionnez l'une des options suivantes :

Clusters standards

Essayez les solutions suivantes :

  • Activer la journalisation à haut débit : cette fonctionnalité augmente la capacité par nœud. Pour en savoir plus, consultez Ajuster le agent Logging Cloud Logging.

  • Réduisez le volume de journaux : analysez les modèles de journalisation des applications. Réduisez la journalisation inutile ou excessivement détaillée.

  • Déployer un agent de journalisation personnalisé : vous pouvez déployer et gérer votre propre DaemonSet Fluent Bit personnalisé, mais vous êtes alors responsable de sa configuration et de sa maintenance.

  • Vérifiez l'utilisation des ressources des nœuds : même si le volume de journaux respecte les limites, assurez-vous que les nœuds ne sont pas soumis à une forte pression sur le processeur ou la mémoire. Des ressources de nœud insuffisantes peuvent empêcher l'agent de journalisation de traiter et d'envoyer les journaux. Vous pouvez consulter des métriques telles que kubernetes.io/node/cpu/core_usage_time et kubernetes.io/node/memory/used_bytes dans l'explorateur de métriques.

Clusters Autopilot

Essayez les solutions suivantes :

  • Réduisez le volume de journaux : analysez les modèles de journalisation de votre application. Réduisez la journalisation inutile ou excessivement détaillée. Assurez-vous que les journaux sont structurés dans la mesure du possible, car ces types de journaux peuvent aider à un traitement efficace. Excluez les journaux non essentiels.

  • Optimisez les performances des applications : étant donné que les ressources des nœuds sont gérées dans les clusters Autopilot, assurez-vous que vos applications ne consomment pas excessivement de processeur ni de mémoire, ce qui pourrait affecter indirectement les performances des composants des nœuds tels que l'agent de journalisation. Bien que vous ne gériez pas directement les nœuds, l'efficacité des applications a une incidence sur l'état général des nœuds.

Résoudre les problèmes de filtrage et d'application

Lorsque votre application génère des journaux, mais qu'ils n'apparaissent toujours pas dans Cloud Logging, le problème est souvent dû au filtrage ou au comportement de journalisation de l'application. Les sections suivantes abordent des problèmes tels que les filtres d'exclusion des journaux, la mise en mémoire tampon au niveau du conteneur, les requêtes de recherche restrictives et les applications qui n'écrivent pas dans stdout ou stderr.

Examiner les filtres d'exclusion de journaux

L'explorateur de journaux n'affiche que les journaux correspondant à tous les filtres de votre requête et à la plage de dates sélectionnée.

Symptômes :

Des journaux spécifiques correspondant à certains critères sont manquants dans Cloud Logging, mais d'autres journaux provenant des mêmes sources sont présents.

Cause :

Les filtres d'exclusion de journaux sont définis dans vos récepteurs Cloud Logging (souvent le récepteur _Default). Ces règles suppriment silencieusement les journaux qui correspondent à des critères spécifiques, même s'ils ont été envoyés avec succès par le nœud.

Solution :

Pour examiner et modifier les filtres d'exclusion, sélectionnez l'une des options suivantes :

Console

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

    Accéder au routeur de journaux

  2. Identifiez le filtre problématique :

    1. Pour chaque récepteur (à l'exception du récepteur _Required, qui ne peut pas avoir de filtres d'exclusion), cliquez sur Autres actions, puis sélectionnez Afficher les détails du récepteur.
    2. Examinez les requêtes dans la section Filtres d'exclusion. Comparez la logique de filtrage aux attributs de vos journaux manquants (par exemple, le type de ressource, les libellés ou les mots clés).
    3. Copiez la requête du filtre d'exclusion.

    4. Accédez à la page Explorateur de journaux.

      Accéder à l'explorateur de journaux

    5. Collez la requête de filtre d'exclusion dans le volet de requête, puis cliquez sur Exécuter la requête.

    6. Examinez les résultats. Les journaux affichés sont ceux que le filtre exclurait. Si vos journaux manquants apparaissent dans ces résultats, ce filtre est probablement la cause du problème.

  3. Désactivez ou modifiez le filtre :

    1. Revenez à la page Routeur de journaux.
    2. Cliquez sur Autres actions pour le récepteur avec le filtre suspect, puis sélectionnez Modifier le récepteur.
    3. Recherchez la section Choisir des journaux à exclure du récepteur et trouvez le filtre d'exclusion.
    4. Vous pouvez cliquer sur Désactiver pour désactiver le filtre ou modifier sa requête pour la rendre plus spécifique.
    5. Cliquez sur Mettre à jour le récepteur. Les modifications s'appliquent aux nouveaux journaux.

gcloud

  1. Répertoriez tous les récepteurs du projet :

    gcloud logging sinks list --project=PROJECT_ID

  2. Affichez les filtres d'exclusion de chaque récepteur :

    gcloud logging sinks describe SINK_NAME --project=PROJECT_ID

    Dans le résultat, examinez la section exclusions. Comparez la logique de filtrage aux attributs de vos journaux manquants (par exemple, le type de ressource, les libellés ou les mots clés).

  3. Pour modifier les exclusions, mettez à jour la configuration du récepteur :

    1. Exportez la configuration du récepteur dans un fichier local (par exemple, sink-config.yaml) :

      gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml

    2. Ouvrez le fichier sink-config.yaml dans un éditeur de texte.

    3. Recherchez la section exclusions: et supprimez ou modifiez le filtre problématique.

    4. Mettez à jour le récepteur modifié :

      gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID

      Pour en savoir plus sur cette commande, consultez la documentation sur gcloud logging sinks update.

Examiner la mise en mémoire tampon et les retards des journaux de conteneur

Les applications et les systèmes d'exploitation utilisent souvent la mise en mémoire tampon pour écrire les données par blocs plutôt que ligne par ligne, ce qui peut améliorer les performances.

Symptômes :

  • Les journaux de conteneurs spécifiques n'apparaissent dans Cloud Logging qu'une fois le conteneur arrêté ou avec un délai important.
  • Il arrive que les journaux soient incomplets.

Cause :

Ce problème est souvent dû à la mise en mémoire tampon des journaux. Bien que la sortie standard (stdout) soit généralement mise en mémoire tampon par ligne lorsqu'elle est connectée à un terminal, ce comportement change lorsque la sortie est redirigée. Si les journaux ou les scripts de démarrage d'une application dans un conteneur redirigent stdout vers d'autres commandes (par exemple, my-app | grep ...), la sortie peut être entièrement mise en mémoire tampon. Par conséquent, les journaux sont conservés jusqu'à ce que le tampon soit plein ou que le canal se ferme. Ce comportement peut entraîner des retards ou une perte de données si le conteneur se termine de manière inattendue. La mise en mémoire tampon interne à l'application peut également entraîner des retards.

Solution :

Pour résoudre le problème, essayez les solutions suivantes :

  • Évitez de rediriger stdout : si possible, modifiez les points d'entrée du conteneur ou les commandes d'application pour écrire les journaux directement dans stdout ou stderr sans les rediriger vers d'autres commandes telles que grep ou sed dans le conteneur.
  • Assurez-vous que la mise en mémoire tampon des lignes est activée :
    • Si le piping est inévitable, utilisez des outils compatibles avec la mise en mémoire tampon des lignes. Par exemple, utilisez grep --line-buffered.
    • Pour les applications personnalisées, assurez-vous qu'elles vident fréquemment les journaux, idéalement après chaque ligne, lorsqu'elles écrivent dans stdout. De nombreuses bibliothèques de journalisation disposent de paramètres permettant de contrôler la mise en mémoire tampon.

  • Tester le comportement de mise en mémoire tampon : déployez le fichier manifeste de pod suivant et observez les effets dans les journaux à l'aide de la commande kubectl logs -f buffered-pod. Faites des tests en commentant et en décommentant les différents tableaux command dans le fichier manifeste buffered-container :

    # buffered.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: run-script
data:
run.sh: |
    #!/bin/bash
    echo "Starting..."
    for i in $(seq 3600); do
    echo "Log ${i}"
    sleep 1
    done
    echo "Exiting."
---
apiVersion: v1
kind: Pod
metadata:
name: buffered-pod
spec:
containers:
    - name: buffered-container
    image: ubuntu  # Or any other image with bash

    # Case 1: Direct execution - line buffered by default to TTY
    # Logs appear immediately.
    command: ['/bin/bash', '-c', '/mnt/run.sh']

    # Case 2: Piped to grep - fully buffered by default
    # Logs might be delayed or appear in chunks.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']

    # Case 3: Piped to grep with --line-buffered
    # Logs appear immediately.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']

    volumeMounts:
        - name: scripts
        mountPath: /mnt
volumes:
    - name: scripts
    configMap:
        name: run-script
        defaultMode: 0777
restartPolicy: Never

Examiner les requêtes de l'explorateur de journaux

Si vous êtes sûr que vos journaux sont collectés, mais que vous ne les trouvez pas, le problème peut provenir de votre requête de recherche ou de votre plage de dates.

Symptômes :

Les journaux attendus n'apparaissent pas dans les résultats de recherche, même si vous savez que l'application les génère.

Cause :

Il est possible que votre requête dans l'explorateur de journaux comporte des filtres (par exemple, sur les espaces de noms, les libellés, les types de ressources ou le texte) qui excluent involontairement les journaux que vous recherchez.

Solution :

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

    Accéder à l'explorateur de journaux

  2. Cliquez sur Sélectionner une période. Même si vous pensez savoir quand les journaux ont été générés, essayez une plage beaucoup plus large pour exclure les problèmes de timing.

  3. Simplifiez la requête :

    1. Effacez tous les filtres.

    2. Essayez de filtrer uniquement par cluster :

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"

      Remplacez les éléments suivants :

      • CLUSTER_NAME : nom du cluster
      • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

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

  4. Si la requête large fonctionne, réintroduisez vos filtres d'origine un par un :

    • Type de ressource : assurez-vous d'utiliser le bon type de ressource. Par exemple, filtrez-vous par k8s_container alors que vous devriez filtrer par k8s_node ?
    • Libellés : vérifiez l'orthographe des resource.labels, comme namespace_name, container_name ou les libellés personnalisés.
    • Gravité : assurez-vous que le niveau de gravité (par exemple, severity=ERROR) n'est pas trop restrictif.
    • Charge utile du texte : vérifiez les fautes d'orthographe et les chaînes trop restrictives dans les termes de recherche. Par exemple, utilisez : pour "contient" au lieu de = pour une correspondance exacte (jsonPayload.message:"error" au lieu de jsonPayload.message="error").

  5. Vérifiez que vos filtres tiennent compte de la sensibilité à la casse (le texte n'y est généralement pas sensible, mais les libellés peuvent l'être), assurez-vous que les valeurs ne contiennent pas de caractères cachés ni d'espaces supplémentaires, et vérifiez si les termes comportant des caractères spéciaux doivent être placés entre guillemets.

  6. Consultez la chronologie. Les baisses soudaines lorsque vous ajoutez un filtre peuvent vous aider à identifier la partie problématique de la requête.

Pour obtenir d'autres conseils sur les requêtes de journaux efficaces, consultez Rechercher des entrées de journal rapidement dans la documentation Cloud Logging.

Si vous ne trouvez toujours pas les journaux après avoir affiné votre requête, le problème n'est peut-être pas lié à la requête, mais à un problème décrit dans d'autres sections de ce document.

Examiner le comportement de journalisation spécifique à une application

L'agent de journalisation GKE ne collecte que les journaux écrits dans les flux stdout et stderr.

Symptômes :

Aucun journal pour un pod ou un conteneur spécifique n'est visible dans Cloud Logging, même si d'autres journaux du cluster sont présents.

Cause :

L'application n'écrit pas dans stdout ni dans stderr. Il est possible qu'il soit mal configuré pour écrire les journaux dans un fichier à l'intérieur du conteneur, où l'agent de journalisation ne peut pas les collecter.

Il est également possible que l'application mélange du texte JSON et non JSON dans sa sortie. L'analyseur de l'agent de journalisation s'attend à un format cohérent (JSON ou texte) à partir d'un seul flux. Si une application configurée pour la journalisation JSON génère une ligne en texte brut, cela peut interrompre l'analyseur, ce qui peut entraîner la suppression ou l'ingestion incorrecte des journaux.

Solution :

  1. Déterminez le nom et l'espace de noms du pod de l'application dont les journaux sont manquants :

    kubectl get pods -n NAMESPACE_NAME

  2. Vérifiez les journaux du conteneur :

    • Si le pod ne comporte qu'un seul conteneur, exécutez la commande suivante :

      kubectl logs POD_NAME \
    -n NAMESPACE_NAME

      Remplacez les éléments suivants :

      • POD_NAME : nom de votre pod.
      • NAMESPACE_NAME : espace de noms de votre pod.

    • Si le pod comporte plusieurs conteneurs, spécifiez le nom du conteneur :

      kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Remplacez CONTAINER_NAME par le nom du conteneur dans le pod.

    • Pour suivre les journaux en temps réel, exécutez la commande suivante :

      kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Remplacez les éléments suivants :

      • POD_NAME : nom de votre pod.
      • CONTAINER_NAME : nom du conteneur dans le pod.
      • NAMESPACE_NAME : espace de noms de votre pod.

  3. Analysez le résultat :

    • Si la commande kubectl logs ne génère aucun résultat ou si le résultat de la commande ne contient pas les journaux attendus, le problème se situe au niveau de l'application elle-même. La commande kubectl logs lit directement les flux stdout et stderr capturés par le moteur d'exécution du conteneur. Si les journaux ne sont pas affichés, cela signifie que l'agent de journalisation de GKE ne peut pas les voir.

      Modifiez le code ou la configuration de votre application pour arrêter d'écrire dans un fichier et enregistrer plutôt tous les messages directement dans stdout (pour les journaux standards) et stderr (pour les journaux d'erreur).

    • Si vous voyez un mélange de chaînes JSON et de lignes en texte brut, cela indique un problème de format mixte. Configurez votre application pour qu'elle n'écrive que des objets JSON valides sur une seule ligne dans stdout et stderr.

    • Si la commande kubectl logs affiche les journaux attendus, le problème se situe probablement plus loin dans le pipeline de journalisation (par exemple, au niveau de l'agent, des autorisations ou du service Cloud Logging).

Résoudre les problèmes liés à la plate-forme et aux services

Les sections suivantes vous aident à examiner les problèmes externes à votre configuration immédiate, tels que les règles de conservation des journaux, l'état de Cloud Logging ou les versions GKE non compatibles.

Examiner les durées de conservation des journaux

Les journaux sont stockés dans des buckets. Chaque bucket dispose d'une période de conservation qui définit la durée pendant laquelle ses journaux sont conservés avant d'être automatiquement supprimés.

Symptômes :

Il manque des journaux datant d'avant une certaine date.

Cause :

Les journaux que vous recherchez sont antérieurs à la période de conservation du bucket de journaux vers lequel ils ont été acheminés.

Solution :

Pour identifier et modifier la période de conservation, sélectionnez l'une des options suivantes :

Console

  1. Identifiez le bucket vers lequel vos journaux GKE sont acheminés :

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

      Accéder au routeur de journaux

    2. Consultez la colonne Destination, qui indique où les journaux sont acheminés.

      La destination ressemble à ceci :

      logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

      Notez les éléments PROJECT_ID, LOCATION et BUCKET_ID.

      Les journaux sont souvent acheminés vers le bucket _Default, mais ils peuvent également être acheminés vers d'autres buckets si vous avez configuré des récepteurs personnalisés.

  2. Vérifiez la période de rétention du bucket de journaux :

    1. Dans la console Google Cloud , accédez à la page Stockage des journaux.

      Accéder à la page "Stockage des journaux"

    2. Recherchez les buckets correspondant à BUCKET_ID, LOCATION et PROJECT_ID dans la destination du récepteur.

    3. Pour chaque bucket concerné, consultez la colonne Durée de conservation.

    4. Si les journaux que vous souhaitez afficher sont antérieurs à la période de conservation, Cloud Logging les a supprimés. Si vous avez besoin d'une durée de conservation plus longue, procédez comme suit :

      1. Pour le bucket dont vous souhaitez étendre la période de conservation, cliquez sur Autres actions.
      2. Sélectionnez Modifier le bucket, puis modifiez la période de conservation. Tenez compte des implications potentielles en termes de coûts.

gcloud

  1. Identifiez le bucket vers lequel vos journaux GKE sont acheminés :

    gcloud logging sinks list --project=PROJECT_ID

    Examinez le résultat. Le champ destination de chaque récepteur indique où les journaux sont routés. Le format de destination d'un bucket de journaux est le suivant :

    logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

    Notez les éléments PROJECT_ID, LOCATION et BUCKET_ID.

    Les journaux sont souvent acheminés vers le bucket _Default.

  2. Vérifiez la période de rétention du bucket de journaux :

    gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID

    Dans le résultat, recherchez le champ retentionDays. Si les journaux dont vous avez besoin sont plus anciens que la valeur indiquée pour retentionDays, Cloud Logging les a supprimés.

  3. Si vous avez besoin d'une période de conservation plus longue, modifiez-la :

    gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

    Remplacez les éléments suivants :

    • BUCKET_ID : ID du bucket de journaux.
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du bucket.
    • RETENTION_DAYS : nombre de jours de conservation des journaux. Tenez compte des implications potentielles en termes de coûts si vous augmentez la période de conservation.
    • PROJECT_ID : ID de votre projet Google Cloud .

Enquêter sur les problèmes de service et les retards d'ingestion de Cloud Logging

Parfois, le pipeline de journalisation lui-même peut rencontrer des problèmes, qu'il s'agisse d'une interruption de service à l'échelle du service ou d'un retard d'ingestion temporaire à grande échelle.

Symptômes :

  • Perte de journaux généralisée ou intermittente dans plusieurs projets ou clusters.
  • Les journaux apparaissent dans l'explorateur de journaux avec un retard important.

Cause :

  • Indisponibilité du service Cloud Logging : une indisponibilité rare et généralisée du service peut empêcher l'ingestion des journaux, entraînant des retards généralisés ou une perte totale des journaux.
  • Volume de journaux élevé : même en l'absence d'interruption officielle, un volume de journaux élevé provenant de votre projet ou de votre région peut submerger temporairement le service d'ingestion, ce qui retarde l'affichage des journaux.

Solution :

  • Vérifiez l'état des services Google Cloud en accédant au tableau de bord d'état des services.Google CloudRecherchez les incidents ouverts liés à Cloud Logging ou à GKE.

  • Tenez compte des éventuels retards d'ingestion. Si les journaux ne sont pas immédiatement visibles et qu'aucun incident n'est actif, laissez le temps à l'ingestion, surtout si le volume de journaux est élevé. Réessayez dans quelques minutes.

Examiner la version du cluster

GKE publie régulièrement de nouvelles versions qui incluent des corrections de bugs et des améliorations des performances pour les composants, y compris l'agent de journalisation.

Symptômes :

Les problèmes de journalisation coïncident avec les limites de version du cluster.

Cause :

Il est possible que le cluster exécute une version GKE ancienne ou non compatible qui présente des problèmes connus avec l'agent de journalisation ou qui ne dispose pas de certaines fonctionnalités de journalisation.

Solution :

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez la version de votre cluster :

    gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

  2. Pour vous assurer qu'il s'agit d'une version compatible, comparez-la au calendrier des versions de GKE.

  3. Si le cluster utilise une version non compatible, mettez-le à niveau.

Étapes suivantes