Résoudre les problèmes de routage et de stockage des journaux

Ce document explique les problèmes de routage et de stockage courants, et comment utiliser la consoleGoogle Cloud pour afficher et résoudre les erreurs de configuration ou les résultats inattendus.

Pour obtenir des informations générales sur l'affichage des données de journaux, consultez Afficher les journaux dans les destinations de récepteurs.

Résoudre les problèmes de routage des journaux

Cette section explique comment résoudre les problèmes courants liés au routage de vos entrées de journaux.

La création d'un récepteur échoue en raison d'une erreur de service inconnue

Vous essayez de créer un récepteur de journaux, mais la commande échoue et une erreur INVALID_ARGUMENT (HTTP 400) s'affiche. Le message d'erreur comprend les éléments suivants :

Sink.destination with unknown service name: [SERVICE_DOMAIN]. Supported services are bigquery.googleapis.com,pubsub.googleapis.com,storage.googleapis.com,logging.googleapis.com

Pour résoudre cette erreur, utilisez le point de terminaison global pour l'un des services compatibles. Une destination de récepteur de journaux ne peut pas spécifier de point de terminaison de service régional (REP), tel que pubsub.LOCATION.rep.googleapis.com.

Le message d'erreur de configuration du récepteur indique qu'une région de sujet n'est pas autorisée

L'un des événements suivants se produit :

  • Vous recevez un e-mail avec l'objet [ACTION REQUIRED] Cloud Logging sink configuration error in [PROJECT_ID] et le code d'erreur topic_region_not_allowed. L'e-mail inclut un message semblable à celui-ci :

    La règle de stockage des messages du sujet exige l'application du transit, mais la requête de publication a été reçue par un serveur Pub/Sub dans une région non autorisée. Veuillez publier les messages via un point de terminaison Cloud Logging régional correspondant à une région autorisée ou mettre à jour la règle de stockage des messages du sujet.

  • Vous remarquez des entrées de journal avec un niveau de gravité ERROR, un code d'erreur "topic_region_not_allowed" et une charge utile de texte semblable à ce qui suit :

    Cloud Logging sink configuration error in [PROJECT_ID], sink [SINK_NAME]: topic_region_not_allowed ()

Ces messages indiquent que la destination du récepteur est un sujet Pub/Sub qui applique des restrictions de transit et que la journalisation achemine les entrées de journaux d'une région non autorisée par la règle du sujet. Les restrictions en transit peuvent être configurées dans la règle de stockage des messages d'un sujet individuel ou appliquées à l'ensemble de l'organisation à l'aide de la contrainte de règle d'administration constraints/pubsub.enforceInTransitRegions.

Pour résoudre ces échecs, effectuez l'une des opérations suivantes :

  • Mettez à jour la règle de stockage des messages du sujet Pub/Sub de destination pour désactiver l'application du transit ou étendre ses régions de persistance autorisées.
  • Si des restrictions en transit sont appliquées par une règle d'administration, mettez à jour la règle d'administration ou demandez une exemption pour le projet.
  • Mettez à jour le récepteur pour acheminer les entrées de journal vers une autre destination.

La destination contient des entrées de journal indésirables

Vous consultez les entrées de journal acheminées vers une destination et constatez que celle-ci contient des entrées de journal indésirables.

Pour résoudre ce problème, mettez à jour les filtres d'exclusion de vos récepteurs qui acheminent les entrées de journaux vers la destination. Les filtres d'exclusion vous permettent d'empêcher le routage de certaines entrées de journal vers une destination.

Par exemple, supposons que vous créez un récepteur agrégé pour acheminer les entrées de journal d'une organisation vers une destination. Pour empêcher le routage des entrées de journal d'un projet spécifique vers la destination, ajoutez le filtre d'exclusion suivant au récepteur :

logName:projects/PROJECT_ID

Vous pouvez également exclure des entrées de journaux de plusieurs projets en utilisant l'opérateur OR logique pour joindre des clauses logName.

Entrées de journal manquantes sur la destination

Le problème le plus courant lié aux récepteurs est peut-être celui où les entrées de journal semblent manquer dans la destination d'un récepteur.

Dans certains cas, il peut arriver qu'aucune erreur ne soit générée, mais que les entrées de journaux soient indisponibles lorsque vous essayez d'y accéder dans votre destination. Si vous pensez que votre récepteur n'achemine pas correctement les entrées de journal, vérifiez ses métriques basées sur les journaux système :

  • exports/byte_count : nombre d'octets dans les entrées de journal qui ont été acheminées.
  • exports/log_entry_count : nombre d'entrées de journal acheminées.
  • exports/error_count : nombre d'entrées de journal dont le routage a échoué.

Les métriques incluent des libellés qui enregistrent les décomptes par nom de récepteur et par nom de destination afin de vous permettre de vérifier si le récepteur parvient à acheminer les entrées de journaux. Pour en savoir plus sur l'affichage des métriques, consultez la présentation des métriques basées sur les journaux.

Si les métriques de votre récepteur indiquent que celui-ci ne fonctionne pas comme prévu, voici quelques-unes des causes possibles et des solutions permettant d'y remédier :

Latence

  • Aucune entrée de journal correspondante n'a été reçue depuis la création ou la mise à jour de votre récepteur. Seules les nouvelles entrées de journal sont acheminées.

    Patientez une heure, puis vérifiez à nouveau votre destination.

  • Les entrées de journal arrivent en retard.

    Il peut y avoir un délai avant que vous puissiez afficher vos entrées de journal dans la destination. Les entrées de journaux tardives sont particulièrement fréquentes pour les récepteurs qui utilisent des buckets Cloud Storage comme destinations. Patientez quelques heures, puis vérifiez à nouveau votre destination.

Le champ d'application/filtre d'affichage est incorrect

Erreur dans le filtre de récepteur

  • Le filtre du récepteur est incorrect et ne capture pas les entrées de journal que vous vous attendiez à voir dans votre destination.

    Modifiez le filtre de votre récepteur à l'aide du routeur de journaux dans la console Google Cloud . Pour vérifier que le filtre saisi est correct, sélectionnez Prévisualiser les journaux dans le panneau Modifier le récepteur. L'explorateur de journaux s'ouvre dans un nouvel onglet avec le filtre prérempli. Pour savoir comment afficher et gérer vos récepteurs, consultez Gérer les récepteurs.

Afficher les erreurs

Pour chacune des destinations de récepteur compatibles, Logging fournit des messages d'erreur pour les récepteurs mal configurés.

Il existe plusieurs façons d'afficher les erreurs liées au récepteur. Les méthodes correspondantes sont décrites dans les sections suivantes :

Journaux d'erreurs

La méthode recommandée pour inspecter en détail les erreurs liées au récepteur consiste à afficher les entrées de journal d'erreurs générées par le récepteur. Pour savoir comment afficher les entrées de journal, consultez Afficher les journaux à l'aide de l'explorateur de journaux.

Vous pouvez utiliser la requête suivante dans le volet de l'éditeur de requête de l'explorateur de journaux pour examiner les journaux d'erreurs de votre récepteur. La même requête fonctionne dans l'API Logging et la gcloud CLI.

Avant de copier la requête, remplacez la variable SINK_NAME par le nom du récepteur que vous essayez de dépanner. Vous trouverez le nom de votre récepteur sur la page Routeur de journaux de la console Google Cloud .

logName:"logging.googleapis.com%2Fsink_error"
resource.type="logging_sink"
resource.labels.name="SINK_NAME"

Par exemple, si le nom de votre récepteur est my-sink-123, l'entrée de journal peut se présenter comme suit :

{
   errorGroups: [
   0: {
   id: "COXu96aNws6BiQE"
   }]
   insertId: "170up6jan"
   labels: {
      activity_type_name: "LoggingSinkConfigErrorV2"
      destination: "pubsub.googleapis.com/projects/my-project/topics/my-topic"
      error_code: "topic_not_found"
      error_detail: ""
      sink_id: "my-sink-123"
   }
   logName: "projects/my-project/logs/logging.googleapis.com%2Fsink_error"
   receiveTimestamp: "2024-07-11T14:41:42.578823830Z"
   resource: {
   labels: {
      destination: "pubsub.googleapis.com/projects/my-project/topics/my-topic"
      name: "my-sink-123"
      project_id: "my-project"
   }
   type: "logging_sink"
   }
   severity: "ERROR"
   textPayload: "Cloud Logging sink configuration error in my-project, sink my-sink-123: topic_not_found ()"
   timestamp: "2024-07-11T14:41:41.296157014Z"
}

Le champ LogEntry labels et ses informations clé-valeur imbriquées vous aident à cibler la source de l'erreur de votre récepteur. Il contient la ressource concernée, le récepteur concerné et le code d'erreur. Le champ labels.error_code contient une description abrégée de l'erreur qui vous indique quel composant de votre récepteur doit être reconfiguré.

Pour résoudre ce problème, modifiez votre récepteur. Par exemple, vous pouvez modifier votre récepteur à l'aide de la page Routeur de journaux :

Accéder au routeur de journaux

Notifications par e-mail

Contacts essentiels envoie des notifications par e-mail pour les erreurs de configuration de récepteur aux contacts attribués à la catégorie de notification technique pour un projet Google Cloud ou sa ressource parente. Si aucune personne n'a été configurée comme contact pour les notifications techniques de la ressource, les utilisateurs listés comme propriétaires du projet roles/owner pour la ressource reçoivent la notification par e-mail.

Pour chaque combinaison de nom de récepteur de journaux et d'erreur, le système envoie une notification par jour.

Le message contient les informations suivantes :

  • ID de ressource : nom du projet Google Cloud ou d'une autre ressourceGoogle Cloud dans laquelle le récepteur a été configuré.
  • Nom du récepteur : nom du récepteur contenant l'erreur de configuration.
  • Destination du récepteur : chemin d'accès complet de la destination de routage du récepteur (par exemple, pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID).
  • Code d'erreur : description abrégée de la catégorie d'erreur (par exemple, topic_not_found).
  • Détails de l'erreur : informations détaillées sur l'erreur, y compris des recommandations pour la résoudre.

L'expéditeur de cet e-mail est logging-noreply@google.com.

L'objet est semblable à : Subject: [ACTION REQUIRED] Cloud Logging sink configuration error in my-project

Pour afficher et gérer vos récepteurs, utilisez la page Routeur de journaux :

Accéder au routeur de journaux

Toutes les erreurs de configuration de récepteur qui s'appliquent à la ressource apparaissent dans la liste sous la forme Cloud Logging sink configuration error. Chaque erreur contient un lien vers l'une des entrées de journal générées par le récepteur défectueux. Pour examiner en détail les erreurs sous-jacentes, consultez la section Journaux d'erreurs.

Destination du récepteur incorrecte

Après avoir configuré un récepteur, si vous rencontrez une erreur indiquant que la destination est introuvable lors de la tentative de routage des entrées de journal par Logging, voici quelques-unes des causes possibles :

  • La configuration de récepteur contient une faute d'orthographe ou une erreur de formatage dans la destination de récepteur spécifiée.

    Vous devez mettre à jour la configuration de récepteur pour spécifier correctement la destination existante.

  • La destination spécifiée a peut-être été supprimée.

    Vous pouvez modifier la configuration de récepteur pour utiliser une destination différente, ou recréer la destination avec le même nom.

Pour résoudre ces types d'échec, modifiez votre récepteur. Par exemple, vous pouvez modifier votre récepteur à l'aide de la page Routeur de journaux :

Accéder au routeur de journaux

Votre récepteur commence à acheminer les entrées de journal lorsque la destination est trouvée et que de nouvelles entrées de journal correspondant à votre filtre sont reçues par Logging.

Problèmes liés à un récepteur désactivé

Si vous avez désactivé un collecteur pour arrêter de stocker les entrées de journal dans un bucket de journaux, mais que vous voyez toujours des entrées de journal en cours de routage, attendez quelques minutes que les modifications apportées au collecteur soient appliquées.

Problèmes d'autorisation avec les récepteurs

Lorsqu'un récepteur tente d'acheminer une entrée de journal, mais qu'il ne dispose pas des autorisations IAM appropriées pour la destination du récepteur, il signale une erreur que vous pouvez afficher et ignore l'entrée de journal.

Lorsque vous créez un récepteur, le compte de service de ce récepteur doit disposer des autorisations de destination appropriées. Si vous créez le récepteur dans la console Google Cloud dans le même projetGoogle Cloud , la console Google Cloud attribue généralement ces autorisations automatiquement. Toutefois, si vous créez le récepteur dans un autre projetGoogle Cloud ou à l'aide de gcloud CLI ou de l'API Logging, vous devez configurer manuellement les autorisations.

Si vous rencontrez des erreurs liées aux autorisations pour votre récepteur, ajoutez les autorisations nécessaires ou mettez à jour votre récepteur pour utiliser une autre destination. Pour savoir comment mettre à jour ces autorisations, consultez la section Autorisations de destination.

Un délai s'applique entre la création du récepteur et l'utilisation du nouveau compte de service du récepteur pour autoriser l'écriture sur la destination. Votre récepteur commence à acheminer les entrées de journal lorsque les autorisations sont corrigées et que de nouvelles entrées de journal correspondant à votre filtre sont reçues par Logging.

Problèmes liés aux règles d'administration avec les récepteurs

Si vous tentez d'acheminer une entrée de journal et qu'une règle d'administration empêche Logging d'écrire dans la destination du récepteur, le récepteur ne peut pas acheminer la requête vers la destination sélectionnée et renvoie une erreur.

Si vous rencontrez des erreurs liées aux règles d'administration, vous pouvez effectuer les opérations suivantes :

  • Mettez à jour la règle d'administration de la destination pour supprimer les contraintes qui empêchent le récepteur d'acheminer les entrées de journal. Cela suppose que vous disposez des autorisations appropriées pour mettre à jour la règle d'administration.

    Vous pouvez vérifier si une restriction d'emplacement de ressource (constraints/gcp.resourceLocations) existe. Cette contrainte détermine les emplacements où les données peuvent être stockées. De plus, certains services sont compatibles avec des contraintes qui peuvent affecter un récepteur de journaux. Par exemple, plusieurs restrictions peuvent s'appliquer lorsqu'une destination Pub/Sub est sélectionnée. Pour obtenir la liste des contraintes possibles, consultez Contraintes liées aux règles d'administration.

    Pour obtenir des instructions, consultez Créer et modifier des règles.

  • Si vous ne pouvez pas mettre à jour la règle d'administration, mettez à jour votre récepteur sur la page Routeur de journaux afin d'utiliser une destination conforme.

    Accéder au routeur de journaux

Votre récepteur commence à acheminer les entrées de journal lorsque la règle d'administration de l'organisation ne l'empêche plus d'écrire dans la destination et que de nouvelles entrées de journal correspondant à votre filtre sont reçues par Logging.

Problèmes liés aux clés de chiffrement avec les collecteurs

Si vous utilisez des clés de chiffrement, qu'elles soient gérées avec Cloud Key Management Service ou par vous, pour chiffrer les données dans la destination du récepteur, des erreurs peuvent s'afficher. Voici quelques problèmes possibles et comment les résoudre :

  • La facturation n'est pas activée pour le projet Google Cloud contenant la clé Cloud KMS.

    • Même si le récepteur a bien été créé avec la destination appropriée, ce message d'erreur s'affiche si aucun compte de facturation valide n'est associé au projet Google Cloud qui contient la clé.

    • Assurez-vous qu'un compte de facturation valide est associé au Google Cloud projet qui contient la clé. Si aucun compte de facturation n'est associé au projetGoogle Cloud , activez la facturation pour ce projet Google Cloud ou utilisez une clé Cloud KMS contenue dans un projet Google Cloud auquel un compte de facturation valide est associé.

  • La clé Cloud KMS est introuvable.

    • Le projet Google Cloud contenant la clé Cloud KMS configurée pour le chiffrement des données est introuvable.

    • Utilisez une clé Cloud KMS valide contenue dans un projetGoogle Cloud existant.

  • L'emplacement de la clé Cloud KMS ne correspond pas à l'emplacement de la destination.

    • Si le projet Google Cloud contenant la clé Cloud KMS se trouve dans une région différente de celle de la destination, le chiffrement échoue et le collecteur ne peut pas acheminer les données vers cette destination.

    • Utilisez une clé Cloud KMS contenue dans un projet Google Cloud dont la région correspond à la destination du récepteur.

  • L'accès à la clé de chiffrement est refusé au compte de service du récepteur.

    • Même si le récepteur a bien été créé avec les autorisations de compte de service appropriées, ce message d'erreur s'affiche si la destination du récepteur utilise une clé de chiffrement qui ne donne pas au compte de service des autorisations suffisantes pour chiffrer ou déchiffrer les données.

    • Accordez le rôle Chiffreur/Déchiffreur de CryptoKey Cloud KMS au compte de service spécifié dans le champ writerIdentity du récepteur pour la clé utilisée dans la destination. Vérifiez également que l'API Cloud KMS est activée.

Problèmes de quota avec les récepteurs

Lorsque les récepteurs écrivent des entrées de journal, des quotas d'exportation et de destination s'appliquent. Selon la destination, les quotas sont appliqués à la ressource où le récepteur a été créé, comme pour Pub/Sub, ou à la destination elle-même, comme pour BigQuery. Si le quota est épuisé, un récepteur cesse d'acheminer les entrées de journal vers sa destination.

  • Les récepteurs qui acheminent les entrées de journal vers un sujet Pub/Sub sont limités à 60 Go/min. Si le volume d'entrées de journal dépasse le quota de débit d'exportation, une entrée de journal avec un code d'erreur topic_over_quota est écrite.
  • Les récepteurs qui acheminent des données vers BigQuery sont limités au quota d'insertion en flux continu par table. Lorsque ce quota est épuisé, une entrée de journal avec un code d'erreur table_resource_exhausted est écrite.

Des quotas s'appliquent également aux récepteurs agrégés. Ces récepteurs acheminent les entrées de journaux pour le dossier ou l'organisation dans lesquels ils ont été créés, ainsi que pour les ressources enfants.

Pour les récepteurs au niveau du projet, les types de métriques suivants peuvent vous aider à surveiller votre utilisation du quota et à identifier les erreurs :

  • logging.googleapis.com/exports/byte_count : volume, en octets, des entrées de journal exportées vers une destination.
  • logging.googleapis.com/exports/log_entry_count : nombre d'entrées de journal exportées vers une destination.
  • logging.googleapis.com/exports/error_count : nombre d'entrées de journal dont l'exportation a échoué.

Pour représenter un type de métrique sous forme de graphique, utilisez l'explorateur de métriques et filtrez les données pour une destination spécifique. Ces types de métriques ne sont pas disponibles pour les récepteurs au niveau du dossier ou de l'organisation.

Pour résoudre les problèmes d'épuisement du quota, essayez les solutions suivantes :

  • Diminuez la quantité de données de journaux routées en mettant à jour le filtre de votre récepteur afin d'obtenir moins d'entrées de journaux. Vous pouvez utiliser la fonction sample de votre filtre pour sélectionner une fraction du nombre total d'entrées de journal.

  • Envoyez une demande d'assistance pour augmenter votre quota.

Pour en savoir plus sur les limites pouvant s'appliquer lorsque vous routez des entrées de journal, consultez les informations sur les quotas de la destination appropriée :

Routage des erreurs vers Cloud Storage

Voici les erreurs les plus courantes lors du routage des entrées de journaux vers Cloud Storage :

  • Entrées de journal tardives :

    • Les entrées de journal acheminées sont enregistrées par lot toutes les heures dans des buckets Cloud Storage. L'affichage des premières entrées peut prendre 2 à 3 heures.

    • Les partitions de fichiers journaux acheminées qui possèdent le suffixe An ("Append", ajout) contiennent les entrées de journal arrivées en retard. Si la destination Cloud Storage cesse de fonctionner, Cloud Logging conserve les données en mémoire tampon jusqu'à la fin de l'interruption.

  • Impossible d'accorder les autorisations appropriées à la destination :

    Pour résoudre ce problème, vérifiez que le compte de service du récepteur de journaux dispose des autorisations appropriées. Pour en savoir plus, consultez la section Problèmes d'autorisation de ce document.

  • Vous recevez une notification par e-mail ou voyez une entrée de journal indiquant une erreur dans la configuration d'un récepteur de journaux. Le code d'erreur est bucket_changed_parent_project.

    Ce code d'erreur indique que le récepteur de journaux listé dans la notification est configuré pour acheminer les entrées de journal vers un bucket Cloud Storage et que le projet parent du bucket Cloud Storage a changé. Dans ce scénario, Cloud Logging marque le récepteur de journaux comme mal configuré, ce qui l'empêche de router les entrées de journal vers le bucket Cloud Storage.

    Pour résoudre cette erreur de configuration, effectuez l'une des opérations suivantes :

    • Supprimez le récepteur de journaux existant et créez-en un qui achemine les entrées de journal vers le bucket Cloud Storage.

    • Déplacez le bucket Cloud Storage vers le projet Google Cloud d'origine.

Erreurs de routage vers BigQuery

Voici les erreurs les plus courantes lors de l'acheminement des entrées de journal vers BigQuery :

  • Schéma de table non valide :

    • Les entrées de journaux diffusées vers le tableau de votre ensemble de données BigQuery ne correspondent pas au schéma de tableau actuel. Les problèmes courants incluent le fait de transférer des entrées de journal avec différents types de données, ce qui entraîne une incohérence de schéma. Par exemple, l'un des champs de l'entrée de journal est un nombre entier, tandis que la colonne correspondante dans le schéma correspond à un type de chaîne.

    • Assurez-vous que vos entrées de journal correspondent au schéma du tableau. Après avoir corrigé la source de l'erreur, vous pouvez renommer votre tableau actuel et laisser Stackdriver Logging recréer le tableau.

    • BigQuery accepte le chargement de données imbriquées dans ses tables. Toutefois, lors du chargement de données depuis Logging, la limite maximale de profondeur des données imbriquées pour une colonne est de 13 niveaux.

    Lorsque BigQuery identifie une incohérence de schéma, il crée une table dans l'ensemble de données correspondant pour stocker les informations d'erreur. Le type de table détermine le nom de la table. Pour les tables segmentées par date, le format des noms est export_errors_YYYYMMDD. Pour les tables partitionnées, le format des noms est export_errors. Pour en savoir plus sur le schéma des tables d'erreurs et sur la façon d'éviter les futurs problèmes d'incompatibilité de type de champ, consultez Incohérences de schéma.

  • Les entrées de journal dépassent les limites temporelles autorisées :

    • Les entrées de journaux diffusées vers la table BigQuery partitionnée sont en dehors des limites temporelles autorisées. BigQuery n'accepte pas les entrées de journal trop éloignées dans le passé ou le futur.

    • Vous pouvez mettre à jour votre récepteur pour acheminer ces entrées de journal vers Cloud Storage et utiliser une tâche de chargement BigQuery. Consultez la documentation BigQuery pour obtenir des instructions.

  • Un ensemble de données n'est pas autorisé à accéder au compte de service associé au récepteur de journaux :

    • Même si le récepteur a bien été créé avec les autorisations de compte de service appropriées, ce message d'erreur s'affiche si aucun compte de facturation valide n'est associé au projet Google Cloud qui contient le récepteur de destination.

    • Assurez-vous qu'un compte de facturation est associé à votre projet Google Cloud . Si aucun compte de facturation n'est associé au projetGoogle Cloud de destination du collecteur, activez la facturation pour ce projet Google Cloud ou mettez à jour la destination du collecteur afin qu'elle se trouve dans un projetGoogle Cloud auquel un compte de facturation valide est associé.

  • L'ensemble de données contient des entrées de journaux en double :

    • Des entrées de journaux en double peuvent se produire en cas d'échec du streaming des entrées de journaux vers BigQuery, y compris en raison de nouvelles tentatives ou de configurations incorrectes. Cloud Logging déduplique les entrées de journal avec le même timestamp et le même insertId au moment de la requête. BigQuery n'élimine pas les entrées de journaux en double.

    • Pour ignorer les entrées de journal en double dans BigQuery, incluez la clause SELECT DISTINCT dans votre requête. Exemple :

    SELECT DISTINCT insertId, timestamp FROM TABLE_NAME

  • Les entrées de journal sont complétées après un incident Cloud Logging :

    La journalisation génère automatiquement des tables avec un préfixe backfill_ dans le cadre d'une opération de remplissage qui se produit lorsqu'un incident Cloud Logging empêche le routage des données de journaux vers BigQuery.

    Les tables avec un préfixe backfill_ contiennent toutes les entrées de journal qui devaient être routées vers BigQuery pendant la période de l'incident. Ces tables peuvent contenir des entrées de journal qui ont été correctement acheminées vers la table spécifiée par le récepteur.

    Pour éviter les doublons, nous vous recommandons de fusionner les données des tables de remplissage dans les tables d'origine, puis de supprimer les tables de remplissage.

Routage des erreurs vers des buckets Cloud Logging

Il peut arriver que vous puissiez voir dans l'explorateur de journaux des entrées de journal que vous avez exclues avec votre récepteur. Vous pouvez toujours consulter ces entrées de journaux si l'une des conditions suivantes est satisfaite :

  • Vous exécutez votre requête dans le projet Google Cloud qui a généré les entrées de journal.

    Pour résoudre ce problème, vérifiez que vous exécutez votre requête dans le bon projetGoogle Cloud .

  • Les entrées de journaux exclues ont été envoyées à plusieurs buckets de journaux. Vous voyez donc une copie du même journal que vous vouliez exclure.

    Pour résoudre ce problème, vérifiez vos récepteurs sur la page Routeur de journaux afin de vous assurer que vous n'incluez pas les entrées de journal dans les filtres d'autres récepteurs.

  • Vous avez accès aux vues du bucket de journaux dans lequel les entrées de journal ont été envoyées. Dans ce cas, vous pouvez voir ces entrées de journal par défaut.

    Pour éviter de voir ces entrées de journal dans l'explorateur de journaux, vous pouvez affiner le champ d'application de votre recherche sur votre projet ou bucket Google Cloud source.

Résoudre les problèmes de stockage des journaux

Pourquoi ne puis-je pas supprimer ce bucket ?

Si vous essayez de supprimer un bucket, procédez comme suit :

  • Vérifiez que vous disposez des autorisations appropriées pour supprimer le bucket. Pour obtenir la liste des autorisations dont vous avez besoin, consultez Contrôle des accès avec IAM.

  • Déterminez si le bucket est verrouillé en répertoriant les attributs du bucket. Si le bucket est verrouillé, vérifiez sa période de conservation. Vous ne pouvez pas supprimer un bucket verrouillé tant que la période de conservation de ce dernier n'a pas été atteinte pour tous les journaux qu'il contient.

  • Vérifiez que le bucket de journaux ne comporte aucun lien. Vous ne pouvez pas supprimer un bucket de journaux contenant des liens.

    L'erreur suivante s'affiche en réponse à une commande delete sur un bucket de journaux associé à un ensemble de données BigQuery :

    FAILED_PRECONDITION: This bucket is used for advanced analytics and has an active link. The link must be deleted first before deleting the bucket

    Pour lister les liens associés à un bucket de journaux, exécutez la commande gcloud logging links list ou la méthode d'API projects.locations.buckets.links.list.

    Pour supprimer des liens, utilisez la commande gcloud logging links delete.

Quels comptes de service acheminent les journaux vers mon bucket ?

Pour déterminer si des comptes de service disposent d'autorisations IAM pour acheminer les journaux vers votre bucket, procédez comme suit :

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

    Accéder à IAM

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.

  2. À partir de l'onglet Autorisations, affichez la liste par Rôles. Un tableau contenant tous les rôles et comptes principaux IAM associés à votre projetGoogle Cloud s'affiche.

  3. Dans la tableFiltre zone de texte, saisissez Rédacteur de bucket de journaux.

    Tous les comptes principaux dotés du rôle Rédacteur de bucket de journaux s'affichent. Si un compte principal est un compte de service, son ID contient la chaîne gserviceaccount.com.

  4. Facultatif : si vous souhaitez empêcher un compte de service d'acheminer les journaux vers votre projet Google Cloud , cochez la case pour le compte de service, puis cliquez sur Supprimer.

Pourquoi les journaux d'un projet Google Cloud apparaissent-ils alors que je les ai exclus de mon récepteur_Default ?

Vous consultez peut-être des journaux dans un bucket de journaux d'un projet Google Cloud centralisé, qui agrège les journaux de toute votre organisation.

Si vous utilisez l'explorateur de journaux pour accéder à ces journaux et que vous voyez les journaux que vous avez exclus du récepteur _Default, il est possible que votre vue soit définie au niveau du projetGoogle Cloud .

Pour résoudre ce problème, sélectionnez Vue des journaux dans le menu Affiner le champ d'application, puis sélectionnez la vue des journaux associée au bucket _Default dans votre projetGoogle Cloud . Vous ne devriez plus voir les journaux exclus.