Ce document explique les problèmes de routage et de stockage courants, et comment utiliser la consoleTrusted 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 journal.
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 journal 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 journaux 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 de récepteur le plus courant est le fait d'avoir des entrées de journal manquantes sur 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.
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. Patientez quelques heures, puis vérifiez à nouveau votre destination.
Le champ d'application/filtre d'affichage est incorrect
Le champ d'application que vous utilisez pour afficher les entrées de journal stockées dans un bucket de journaux est incorrect.
Limitez votre recherche à une ou plusieurs vues de journaux comme suit :
Si vous utilisez l'explorateur de journaux, utilisez le bouton Affiner le champ d'application.
Si vous utilisez gcloud CLI, exécutez la commande
gcloud logging read
et ajoutez l'option--view=AllLogs
.
La plage de dates que vous utilisez pour sélectionner et afficher les données dans la destination de votre récepteur est trop étroite.
Essayez d'élargir la plage de dates que vous utilisez lorsque vous sélectionnez des données dans la destination de votre récepteur.
Erreur dans le filtre de récepteur
Le filtre de récepteur est incorrect et ne capture pas les entrées de journal que vous souhaitez transférer vers votre destination.
Modifiez le filtre de votre récepteur à l'aide du routeur de journaux dans la console Trusted 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 :
- Afficher les journaux d'erreurs générés pour le récepteur.
- Recevoir des notifications d'erreur de récepteur par e-mail. L'expéditeur de cet e-mail est
logging-noreply@google.com
.
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 Trusted 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 de clé-valeur imbriquées vous aident à cibler la source de l'erreur de récepteur. Ce champ 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 évier. 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 Trusted Cloud ou sa ressource parente.
Si aucun contact n'est configuré pour les notifications techniques de la ressource, les utilisateurs bénéficiant du rôle IAM Propriétaire de projet roles/owner
pour la ressource reçoivent la notification par e-mail.
Le message envoyé par e-mail contient les informations suivantes :
- ID de ressource : nom du projet Trusted Cloud ou d'une autre ressourceTrusted 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
.
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.
Types d'erreurs de récepteur
Les sections suivantes décrivent des catégories générales d'erreurs liées aux récepteurs et indiquent comment les résoudre.
Destination 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.
Gérer les problèmes liés aux récepteurs
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
Lorsqu'un récepteur tente d'acheminer une entrée de journal sans disposer des autorisations IAM appropriées pour sa destination, 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 du récepteur doit disposer des autorisations de destination appropriées. Si vous créez le récepteur dans la console Trusted Cloud dans le même projetTrusted Cloud , la console Trusted Cloud attribue généralement ces autorisations automatiquement. Toutefois, si vous créez le récepteur dans un autre projetTrusted Cloud ou à l'aide de gcloud CLI ou de l'API Logging, vous devez configurer les autorisations manuellement.
Si vous constatez des erreurs liées aux autorisations pour votre récepteur, ajoutez les autorisations nécessaires ou mettez à jour votre récepteur afin d'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
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.
Votre récepteur commence à acheminer les entrées de journal lorsque la règle d'administration ne l'empêche plus d'écrire sur la destination et que de nouvelles entrées de journal correspondant au filtre sont reçues par Logging.
Problèmes liés aux clés de chiffrement
Si vous utilisez des clés de chiffrement gérées par vos soins ou avec Cloud Key Management Service pour chiffrer les données dans la destination du récepteur, des erreurs correspondantes peuvent survenir. Voici quelques problèmes possibles et des solutions pour les résoudre :
La clé Cloud KMS est introuvable.
Le Trusted Cloud projet contenant la clé Cloud KMS configurée pour le chiffrement des données est introuvable.
Utilisez une clé Cloud KMS valide contenue dans un projetTrusted Cloud existant.
L'emplacement de la clé Cloud KMS ne correspond pas à l'emplacement de la destination.
Si le projet Trusted Cloud contenant la clé Cloud KMS se trouve dans une région différente de la région de destination, le chiffrement échoue et le récepteur ne peut pas acheminer les données vers cette destination.
Utilisez une clé Cloud KMS résidant dans un projet Trusted 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
Lorsque les récepteurs écrivent des entrées de journal, les quotas spécifiques à la destination s'appliquent aux projetsTrusted Cloud dans lesquels les récepteurs ont été créés. Si les quotas sont épuisés, le récepteur arrête d'acheminer les entrées de journal vers la destination.
Par exemple, le récepteur achemine peut-être trop d'entrées de journal, trop rapidement.
Pour résoudre les problèmes d'épuisement des quotas, réduisez la quantité de données de journalisation acheminées en mettant à jour le filtre de votre récepteur afin de conserver 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.
Lorsque du quota est disponible, votre récepteur achemine les entrées de journal vers la destination du récepteur.
Pour en savoir plus sur les limites qui peuvent s'appliquer lorsque vous routez des entrées de journal, consultez les informations de quota de la destination correspondante :
Outre les types d'erreurs de récepteur généraux, voici les types d'erreurs de destination les plus courants ainsi que la façon de les résoudre.
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 Trusted 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 projetTrusted Cloud .
Les entrées de journal exclues ont été envoyées à plusieurs buckets de journaux et l'entrée que vous voyez est une copie du journal que vous souhaitez exclure.
Pour résoudre ce problème, vérifiez l'état des récepteurs sur la page Routeur de journaux afin de ne pas inclure ces 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 pour votre projet ou votre bucket Trusted 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 durée de conservation. Vous ne pouvez pas supprimer un bucket verrouillé tant que tous les journaux qu'il contient n'ont pas atteint la date limite de conservation du bucket.
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 :
-
Dans la console Trusted Cloud , accédez à la page 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.
À 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 projetTrusted Cloud s'affiche.
Dans la tableFiltre zone de texte filter_list, 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
s3ns-system.iam.gserviceaccount.com
.Facultatif : Si vous souhaitez empêcher un compte de service d'acheminer les journaux vers votre projet Trusted Cloud , cochez la case check_box_outline_blank correspondant au compte de service, puis cliquez sur Supprimer.
Pourquoi les journaux d'un projet Trusted Cloud apparaissent-ils alors que je les ai exclus de mon récepteur _Default
?
Vous pouvez consulter les journaux d'un bucket de journaux dans un projet Trusted Cloud centralisé qui regroupe les journaux de 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 projetTrusted 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 projetTrusted Cloud . Vous ne devriez plus voir les journaux exclus.