Acheminer les entrées de journal

Vous pouvez utiliser Cloud Logging pour acheminer les entrées de journal des services Google Cloud , de vos applications et d'autres fournisseurs de services cloud vers des destinations de stockage, d'analyse et d'exportation tierce.

Par défaut, Cloud Logging achemine toutes les entrées de journal vers les buckets de journaux du projet, du dossier ou de l'organisation dont elles proviennent. Toutefois, vous pouvez configurer des récepteurs de journaux pour acheminer les données de journaux vers des buckets personnalisés, Cloud Storage, BigQuery ou Pub/Sub. Des services tels que Cloud Storage et Pub/Sub permettent d'exporter vos données de journaux vers des outils tiers.

De manière générale, voici comment Cloud Logging achemine et stocke les entrées de journal :

Schéma illustrant le routage des entrées de journal par Cloud Logging.

La figure précédente s'applique aux buckets de journaux qui se trouvent dans un projet. Vous ne pouvez pas créer de buckets de journaux définis par l'utilisateur dans des dossiers ni des organisations. De plus, vous ne pouvez pas étendre la période de conservation d'un bucket de journaux qui se trouve dans un dossier ou une organisation.

Routage ou exportation des entrées de journal

Le routage est le processus de déplacement des entrées de journal reçues par un projet, un dossier ou une organisation Google Cloud vers une destination. Une destination est un service qui traite les entrées de journal reçues et effectue une action. Par exemple, vous pouvez acheminer des entrées de journal vers un bucket de journaux. Cette destination analyse les entrées de journal pour y trouver des informations sur les erreurs, puis les écrit dans l'espace de stockage.

L'exportation est le processus consistant à déplacer des entrées de journaux de Google Cloud vers un emplacement externe. Par exemple, vous pouvez acheminer des entrées de journal vers Pub/Sub, puis les exporter vers des outils tiers.

Cloud Logging utilise des récepteurs de journaux pour acheminer les entrées de journal vers des destinations. Par défaut, vos entrées de journal sont acheminées vers l'un des deux buckets de journaux de votre projet, dossier ou organisationGoogle Cloud . Vous pouvez créer des récepteurs de journaux pour acheminer vos données de journaux vers d'autres destinations. Vous pouvez également modifier l'un des récepteurs de journaux créés par le système. Ce document décrit ces options.

L'explorateur de journaux vous permet de télécharger les entrées de journaux stockées dans des buckets de journaux vers le stockage local. Toutefois, l'option de téléchargement est limitée à 10 000 entrées de journal. Pour exporter vos entrées de journal depuisGoogle Cloud, envisagez les options suivantes :

  • Configurez un récepteur de journaux pour acheminer les entrées de journal entrantes vers Pub/Sub, puis exportez ces données depuis Google Cloud.

  • Copiez les entrées de journal d'un bucket de journaux vers Cloud Storage, puis exportez les données à partir de Google Cloud. Pour savoir comment copier des journaux, consultez Regrouper et acheminer des journaux de manière rétroactive.

À propos des routeurs de journaux

Chaque projet Google Cloud , compte de facturation, dossier et organisation dispose d'un routeur de journaux, qui gère le flux des entrées de journal via les récepteurs au niveau des ressources. Un routeur de journaux gère également le flux d'une entrée de journal via les récepteurs qui se trouvent dans la hiérarchie des ressources de l'entrée. Les récepteurs contrôlent la manière dont les entrées de journal sont acheminées vers les destinations.

Un routeur de journaux stocke temporairement une entrée de journal. Ce comportement permet de se prémunir contre les perturbations et les pannes temporaires qui peuvent survenir lorsqu'une entrée de journal transite par des récepteurs. Le stockage temporaire ne protège pas contre les erreurs de configuration.

Le stockage temporaire du routeur de journaux est différent du stockage à long terme fourni par les buckets Logging.

Les entrées de journal entrantes dont l'horodatage est antérieur à la période de conservation des journaux ou postérieur de plus de 24 heures sont supprimées.

À propos des récepteurs de journaux

Lorsqu'un récepteur de journaux reçoit une entrée de journal, il détermine s'il doit l'ignorer ou l'acheminer vers la destination du récepteur. Pour prendre cette décision, le récepteur de journaux compare l'entrée de journal à ses filtres. La destination d'un récepteur peut être un projet, un emplacement de stockage ou un service tel que Pub/Sub. Par exemple, un récepteur peut acheminer des entrées de journal vers un bucket de journaux.

Les récepteurs de journaux appartiennent à une ressource Google Cloud donnée : Google Cloud projets, comptes de facturation, dossiers et organisations. Ces ressources contiennent également plusieurs récepteurs de journaux. Lorsqu'une ressource reçoit une entrée de journal, chaque récepteur de journaux de cette ressource l'évalue indépendamment. Par conséquent, plusieurs récepteurs de journaux peuvent acheminer la même entrée de journal.

Par défaut, les données de journaux sont stockées dans le projet dont elles proviennent. Toutefois, vous pouvez avoir plusieurs raisons de modifier cette configuration :

  • Pour centraliser le stockage de vos données de journaux.
  • Pour associer vos données de journaux à d'autres données d'entreprise.
  • Pour organiser vos données de journaux de manière à ce qu'elles vous soient utiles.
  • Diffuser vos journaux vers d'autres applications, d'autres dépôts, ainsi que vers des organisations tierces. Par exemple, vous pouvez exporter vos journaux depuis Google Cloud pour les afficher sur une plate-forme tierce. Pour exporter vos entrées de journal, créez un récepteur de journaux qui les achemine vers Pub/Sub.

Un récepteur de journaux mal configuré n'achemine pas les entrées de journal. Lorsqu'un récepteur est mal configuré, des entrées de journal détaillant l'erreur sont écrites. Un e-mail est également envoyé aux contacts essentiels de la ressource. Pour en savoir plus, consultez Dépannage : afficher les erreurs.

Les récepteurs de journaux ne peuvent pas acheminer les entrées de journal de manière rétroactive. En d'autres termes, un récepteur de journaux ne peut pas acheminer une entrée de journal reçue avant sa création. De même, si un récepteur est mal configuré, il ne route que les entrées de journal qui arrivent après la résolution de l'erreur de configuration. Toutefois, vous pouvez copier rétroactivement les données de journaux d'un bucket de journaux vers Cloud Storage. Pour en savoir plus, consultez Copier les journaux.

Prise en charge des organisations et des dossiers

Pour vous aider à gérer les données de journaux dans une organisation ou un dossier, vous pouvez effectuer les opérations suivantes :

  • Vous pouvez créer des récepteurs agrégés, qui acheminent les entrées de journal d'une organisation ou d'un dossier et de leurs enfants vers la destination spécifiée par le récepteur. Il existe deux types de collecteurs agrégés :

    • Récepteurs agrégés sans interception
    • Récepteurs agrégés d'interception

    Les récepteurs d'interception peuvent remplacer le comportement de routage pour les ressources situées plus bas dans la hiérarchie. Les récepteurs sans interception n'affectent pas le routage des autres ressources. Lorsqu'un récepteur d'interception dans une ressource correspond à une entrée de journal, celle-ci n'est pas envoyée aux récepteurs des ressources enfants. Toutefois, l'entrée de journal est toujours envoyée au récepteur de journaux _Required de la ressource à partir de laquelle elle provient.

  • Vous pouvez configurer des paramètres de ressources par défaut pour Cloud Logging afin de spécifier la configuration du récepteur _Default créé par le système pour les nouvelles ressources d'une organisation ou d'un dossier. Par exemple, vous pouvez utiliser ces paramètres pour désactiver le récepteur _Default ou spécifier les filtres dans ce récepteur.

Exemples de routage

Cette section explique comment une entrée de journal provenant d'un projet peut transiter par les récepteurs de sa hiérarchie de ressources.

Exemple : Aucun récepteur agrégé n'existe

Lorsqu'aucun récepteur agrégé n'existe dans la hiérarchie des ressources de l'entrée de journal, celle-ci est envoyée aux récepteurs de journaux du projet d'où elle provient. Un récepteur au niveau du projet achemine l'entrée de journal vers la destination du récepteur lorsque l'entrée de journal correspond au filtre d'inclusion du récepteur, mais ne correspond à aucun des filtres d'exclusion du récepteur.

Exemple : Un récepteur agrégé non interceptant existe

Supposons qu'un récepteur agrégé non interceptant existe dans la hiérarchie des ressources pour une entrée de journal. Une fois que le routeur de journaux a envoyé l'entrée de journal au récepteur agrégé non intercepté, les événements suivants se produisent :

  1. Le récepteur agrégé sans interception achemine l'entrée de journal vers la destination du récepteur lorsque l'entrée de journal correspond au filtre d'inclusion, mais ne correspond à aucun filtre d'exclusion.

  2. Le routeur de journaux envoie l'entrée de journal aux récepteurs de journaux du projet dans lequel elle a été générée.

    Un récepteur au niveau du projet achemine l'entrée de journal vers la destination du récepteur lorsque l'entrée de journal correspond au filtre d'inclusion du récepteur, mais ne correspond à aucun des filtres d'exclusion du récepteur.

Exemple : Un récepteur agrégé d'interception existe

Supposons qu'un récepteur agrégé d'interception existe dans la hiérarchie des ressources pour une entrée de journal. Une fois que le routeur de journaux a envoyé l'entrée de journal au récepteur agrégé d'interception, l'une des situations suivantes se produit :

  • L'entrée de journal correspond au filtre d'inclusion, mais pas à un filtre d'exclusion :

    1. L'entrée de journal est acheminée vers la destination du récepteur agrégé d'interception.
    2. L'entrée de journal est envoyée au récepteur _Required dans le projet d'où elle provient.

  • L'entrée de journal ne correspond pas au filtre d'inclusion ou correspond à au moins un filtre d'exclusion :

    1. L'entrée de journal n'est pas acheminée par le récepteur agrégé d'interception.

    2. Le routeur de journaux envoie l'entrée de journal aux récepteurs de journaux du projet dans lequel elle a été générée.

      Un récepteur au niveau du projet achemine l'entrée de journal vers la destination du récepteur lorsque l'entrée de journal correspond au filtre d'inclusion du récepteur, mais ne correspond à aucun des filtres d'exclusion du récepteur.

Filtres de récepteur de journaux

Chaque récepteur de journaux contient un filtre d'inclusion et peut contenir plusieurs filtres d'exclusion. Ces filtres déterminent si le récepteur de journaux achemine une entrée de journal vers la destination du récepteur. Si vous ne spécifiez aucun filtre, chaque entrée de journal est acheminée vers la destination du récepteur.

Une entrée de journal est acheminée par un récepteur de journaux en fonction des règles suivantes :

  • Si l'entrée de journal ne correspond pas au filtre d'inclusion, elle n'est pas acheminée. Lorsqu'un récepteur ne spécifie pas de filtre d'inclusion, chaque entrée de journal correspond à ce filtre.

  • Si l'entrée de journal correspond au filtre d'inclusion et à au moins un filtre d'exclusion, elle n'est pas acheminée.

  • Si l'entrée de journal correspond au filtre d'inclusion et à aucun filtre d'exclusion, elle est acheminée vers la destination du récepteur.

Les filtres d'un récepteur de journaux sont spécifiés à l'aide du langage de requête Logging.

Vous ne pouvez pas utiliser de filtres d'exclusion pour réduire la consommation de votre quota d'API entries.write ni le nombre d'appels d'API entries.write. Les filtres d'exclusion sont appliqués une fois que les entrées de journal ont été reçues par l'API Logging.

Récepteurs de journaux créés par le système

Pour chaque projet, compte de facturation, dossier et organisation Google Cloud , Cloud Logging crée deux récepteurs de journaux, l'un nommé _Required et l'autre _Default. Les filtres d'inclusion et d'exclusion de ces récepteurs garantissent que chaque entrée de journal provenant de la ressource est acheminée par l'un de ces récepteurs. Les deux récepteurs acheminent les données de journaux vers un bucket de journaux qui se trouve dans la même ressource que le récepteur de journaux.

Le reste de cette section fournit des informations sur les filtres et les destinations des récepteurs de journaux créés par le système.

Récepteur de journaux _Required

Le récepteur de journaux _Required d'une ressource achemine un sous-ensemble de journaux d'audit vers le bucket de journaux _Required de la ressource. Ce récepteur ne spécifie aucun filtre d'exclusion, et le filtre d'inclusion est le suivant :

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

Le récepteur de journaux _Required ne correspond qu'aux entrées de journal provenant de la ressource dans laquelle il est défini._Required Par exemple, supposons qu'un récepteur de journaux route une entrée de journal d'activité du projet A vers le projet B. Comme l'entrée de journal ne provient pas du projet B, le récepteur de journaux _Required du projet B n'achemine pas cette entrée de journal vers le bucket de journaux _Required.

Vous ne pouvez ni modifier, ni supprimer le récepteur de journaux _Required.

Récepteur de journaux _Default

Le récepteur de journaux _Default d'une ressource achemine les entrées de journal vers le bucket de journaux _Default de la ressource. Étant donné que le filtre d'inclusion de ce récepteur est vide, il correspond à toutes les entrées de journal. Toutefois, le filtre d'exclusion est configuré comme suit :

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

Vous pouvez modifier et désactiver le récepteur de journaux _Default. Par exemple, vous pouvez modifier le récepteur de journaux _Default et changer la destination. Vous pouvez également modifier les filtres existants et ajouter des filtres d'exclusion.

Destinations des récepteurs

La destination d'un récepteur peut se trouver dans une ressource différente de celle du récepteur. Par exemple, vous pouvez utiliser un récepteur de journaux pour acheminer des entrées de journaux d'un projet vers un bucket de journaux stocké dans un autre projet.

Les destinations suivantes sont acceptées :

ProjetGoogle Cloud

Sélectionnez cette destination lorsque vous souhaitez que les récepteurs de journaux du projet de destination réacheminent vos entrées de journal ou lorsque vous avez créé un récepteur agrégé d'interception. Les collecteurs de journaux du projet de destination peuvent rediriger les entrées de journal vers n'importe quelle destination compatible, à l'exception d'un projet.

Les récepteurs de journaux créés par le système dans le projet de destination excluent les entrées de journal qui sont acheminées vers le bucket de journaux _Required dans le projet source. Par exemple, si vous routez des journaux d'activité d'administration vers un autre projet, les récepteurs de journaux _Required et _Default du projet de destination excluent ces entrées de journal. Pour stocker ces entrées de journal, mettez à jour le récepteur de journaux _Default ou créez un récepteur de journaux personnalisé dans le projet de destination.

Bucket de journaux

Sélectionnez cette destination lorsque vous souhaitez stocker vos données de journaux dans des ressources gérées par Cloud Logging. Les données de journaux stockées dans des buckets de journaux peuvent être consultées et analysées à l'aide de services tels que l'explorateur de journaux et l'analyse de l'observabilité.

Si vous souhaitez joindre vos données de journaux à d'autres données d'entreprise, vous pouvez stocker vos données de journaux dans un bucket de journaux et créer un ensemble de données BigQuery associé. Un ensemble de données BigQuery associé est en lecture seule, mais vous pouvez l'interroger comme n'importe quel autre ensemble de données BigQuery.

Ensemble de données BigQuery
 Sélectionnez cette destination lorsque vous souhaitez associer vos données de journaux à d'autres données d'entreprise. L'ensemble de données que vous spécifiez doit être activé en écriture. Ne définissez pas la destination d'un récepteur sur un ensemble de données BigQuery associé. Les ensembles de données BigQuery associés sont en lecture seule.
Bucket Cloud Storage
 Sélectionnez cette destination si vous souhaitez stocker vos données de journaux à long terme. Le bucket Cloud Storage peut se trouver dans le projet d'origine des entrées de journal ou dans un autre projet. Les entrées de journaux sont stockées sous forme de fichiers JSON.
Sujet Pub/Sub
 Sélectionnez cette destination lorsque vous souhaitez exporter vos données de journaux depuisGoogle Cloud , puis utiliser des intégrations tierces comme Splunk ou Datadog. Les entrées de journaux sont mises en forme au format JSON, puis acheminées vers un sujet Pub/Sub.

Limites de destination

Cette section décrit les limites spécifiques aux destinations :

  • Si vous acheminez des entrées de journal vers un bucket de journaux dans un autre projet Google Cloud , Error Reporting n'analyse pas ces entrées de journal. Pour en savoir plus, consultez la présentation d'Error Reporting.

  • Les limites suivantes s'appliquent lorsque la destination d'un récepteur de journaux est un ensemble de données BigQuery :

    • L'ensemble de données BigQuery doit être accessible en écriture. Ne définissez pas l'ensemble de données BigQuery associé comme destination. Les ensembles de données associés sont en lecture seule.
    • La journalisation crée une table dans l'ensemble de données pour chaque nom de journal. Vous ne pouvez pas renommer une table pendant qu'un récepteur y diffuse des données.
  • Le démarrage des nouveaux récepteurs qui acheminent les données de journaux vers des buckets Cloud Storage peut prendre plusieurs heures. Ces récepteurs sont traités toutes les heures.

  • Les limites suivantes s'appliquent lorsque la destination d'un récepteur de journaux est un projet Google Cloud  :

    • Il existe une limite d'un saut.
    • Le récepteur de journaux _Required du projet de destination achemine les entrées de journal vers le bucket de journaux _Required du projet lorsque les entrées de journal correspondent au filtre du récepteur et proviennent du projet de destination.
    • Le récepteur de journaux _Default du projet de destination achemine les entrées de journal qui correspondent à son filtre d'inclusion et à aucun filtre d'exclusion. Le récepteur de journaux _Default exclut certaines entrées de journal. Par exemple, ce récepteur ne route pas les entrées de journaux d'activité d'administration ni d'événements système. Vous pouvez modifier ce récepteur.
    • Seuls les récepteurs agrégés qui se trouvent dans la hiérarchie des ressources d'une entrée de journal traitent l'entrée.

    Par exemple, supposons que la destination d'un récepteur de journaux dans le projet A soit le projet B. Dans ce cas, les règles suivantes s'appliquent :

    • En raison de la limite d'un saut, les récepteurs de journaux du projet B ne peuvent pas rediriger les entrées de journal vers un autre projet Google Cloud .
    • Le bucket de journaux _Required du projet B ne stocke que les entrées de journal provenant du projet B. Ce bucket de journaux ne stocke aucune entrée de journal provenant d'une autre ressource, y compris celles provenant du projet A.
    • Si les hiérarchies de ressources des projets A et B sont différentes, une entrée de journal qu'un récepteur de journaux du projet A achemine vers le projet B n'est pas envoyée aux récepteurs agrégés de la hiérarchie de ressources du projet B.
    • Si les projets A et B ont la même hiérarchie de ressources, les entrées de journal sont envoyées aux collecteurs agrégés de cette hiérarchie. Si une entrée de journal n'est pas interceptée par un récepteur agrégé, le routeur de journaux l'envoie aux récepteurs du projet A.

Impact du routage des entrées de journal sur les métriques basées sur les journaux

Les métriques basées sur les journaux sont des métriques Cloud Monitoring dérivées du contenu des entrées de journal. Par exemple, vous pouvez utiliser une métrique basée sur les journaux pour compter le nombre d'entrées de journal contenant un message particulier ou pour extraire les informations de latence enregistrées dans les entrées de journal. Vous pouvez afficher les métriques basées sur les journaux dans les graphiques Cloud Monitoring, et les règles d'alerte peuvent surveiller ces métriques.

Les métriques basées sur les journaux définies par le système s'appliquent au niveau du projet. Les métriques basées sur les journaux définies par l'utilisateur peuvent s'appliquer au niveau du projet ou du bucket de journaux. Les métriques basées sur les journaux à l'échelle du bucket sont utiles lorsque vous utilisez des collecteurs agrégés pour acheminer les entrées de journal vers un bucket de journaux, et lorsque vous acheminez les entrées de journal d'un projet vers un bucket de journaux dans un autre projet.

Métriques basées sur les journaux définies par le système
Le routeur de journaux comptabilise une entrée de journal lorsque toutes les conditions suivantes sont remplies :
  • L'entrée de journal transite par les récepteurs de journaux du projet dans lequel la métrique basée sur les journaux est définie.

  • L'entrée de journal est stockée dans un bucket de journaux. Le bucket de journaux peut se trouver dans n'importe quel projet.

    Par exemple, supposons que le projet A dispose d'un récepteur de journaux dont la destination est le projet B. Supposons également que les collecteurs de journaux du projet B acheminent les entrées de journal vers un bucket de journaux. Dans ce scénario, les entrées de journal acheminées du projet A vers le projet B contribuent aux métriques basées sur les journaux définies par le système du projet A. Ces entrées de journal contribuent également aux métriques basées sur les journaux définies par le système du projet B.

Métriques basées sur les journaux définies par l'utilisateur
Le routeur de journaux comptabilise une entrée de journal lorsque toutes les conditions suivantes sont remplies :
  • La facturation est activée pour le projet dans lequel la métrique basée sur les journaux est définie.
  • Pour les métriques à l'échelle du bucket, l'entrée de journal est stockée dans le bucket de journaux où la métrique basée sur les journaux est définie.
  • Pour les métriques à l'échelle du projet, l'entrée de journal passe par les collecteurs de journaux du projet dans lequel la métrique basée sur les journaux est définie.

Pour en savoir plus, consultez la présentation des métriques basées sur les journaux.

Bonnes pratiques

Gérez vos récepteurs de journaux lorsque vous gérez votre stockage de journaux. Par exemple, si vous supprimez la destination d'un récepteur de journaux, supprimez ensuite le récepteur de journaux correspondant.

Pour connaître les bonnes pratiques d'utilisation du routage pour la gouvernance des données ou pour les cas d'utilisation courants, consultez les documents suivants :

Exemples : centraliser le stockage de vos journaux

Cette section explique comment configurer le stockage centralisé. Le stockage centralisé fournit un emplacement unique pour interroger les données de journaux, ce qui simplifie vos requêtes lorsque vous recherchez des tendances ou que vous étudiez des problèmes. En termes de sécurité, vous disposez également d'un seul emplacement de stockage, ce qui peut simplifier les tâches de vos analystes de sécurité.

Si vous centralisez le stockage de vos journaux, réfléchissez à l'opportunité de placer un lien sur le projet qui stocke vos données de journaux. Un privilège peut empêcher la suppression accidentelle d'un projet. Pour en savoir plus, consultez Protéger les projets à l'aide de privilèges.

Centraliser le stockage des journaux pour les projets d'un dossier

Supposons que vous gérez un dossier et que vous souhaitez centraliser le stockage de vos entrées de journal. Dans ce cas d'utilisation, vous pouvez procéder comme suit :

  1. Dans votre dossier, créez un projet nommé CentralStorage.
  2. Créez un récepteur agrégé d'interception pour votre dossier et configurez-le pour acheminer toutes les entrées de journal. Vous définissez la destination du récepteur sur le projet nommé CentralStorage.

Lorsqu'une entrée de journal provenant du dossier ou de l'une de ses ressources enfants arrive, elle est envoyée au récepteur agrégé d'interception que vous avez créé. Ce récepteur achemine les entrées de journal vers le projet nommé CentralStorage. Les récepteurs de journaux de ce projet traitent les entrées de journal :

  • Le récepteur de journaux _Default achemine vers le bucket de journaux _Default toutes les entrées de journal qui correspondent au filtre du récepteur. Ce bucket de journaux est votre emplacement de stockage centralisé.

  • Le récepteur de journaux _Required achemine vers le bucket de journaux _Required les entrées de journal qui correspondent aux filtres du récepteur et qui proviennent du projet CentralStorage. Ce bucket de journaux n'est pas un emplacement de stockage centralisé. Toutefois, vous pouvez stocker de manière centralisée toutes vos données de journaux. Pour obtenir un exemple, consultez Stocker les journaux d'audit dans un emplacement centralisé.

Une fois le traitement du récepteur agrégé terminé, l'entrée de journal est envoyée au récepteur de journaux _Required dans la ressource dans laquelle l'entrée de journal a été créée. Lorsque l'entrée de journal correspond au filtre du récepteur de journaux _Required, elle est acheminée vers le bucket de journaux _Required de la ressource. Par conséquent, chaque projet Google Cloud de votre dossier stocke les entrées de journal dans son bucket de journaux_Required.

Centraliser le stockage des journaux pour un ensemble de projets

Vous pouvez également stocker les entrées de journal dans un emplacement unique lorsque vous n'avez pas d'organisation ni de dossier. Par exemple, vous pouvez effectuer les opérations suivantes :

  1. Créez un projet nommé CentralStorage.
  2. Pour chaque projet, à l'exception de CentralStorage, modifiez le récepteur de journaux _Default et définissez la destination sur le projet nommé CentralStorage.

Vous vous demandez peut-être pourquoi l'exemple précédent définit la destination des récepteurs de journaux _Default comme étant un projet, au lieu du bucket de journaux _Default de ce projet. Les principales raisons sont la simplicité et la cohérence. Lorsque vous acheminez des entrées de journal vers un projet, les récepteurs de journaux du projet de destination contrôlent les entrées de journal stockées et leur emplacement. En d'autres termes, vous centralisez les fonctionnalités de filtre et de destination. Si vous souhaitez modifier les entrées de journal stockées ou leur emplacement de stockage, il vous suffit de modifier les collecteurs de journaux dans un seul projet.

Centraliser le stockage des journaux d'audit

Vous pouvez stocker de manière centralisée les entrées de journal qui correspondent au récepteur de journaux _Required. Pour stocker ces entrées de journaux de manière centralisée, effectuez l'une des opérations suivantes :

  • Créez des récepteurs de journaux qui acheminent les entrées de journal correspondant au récepteur de journaux _Required vers un bucket de journaux centralisé.

  • Configurez des récepteurs de journaux comme dans les deux exemples précédents, puis ajoutez un récepteur de journaux dans le projet de destination qui achemine les entrées de journaux correspondant au récepteur de journaux _Required vers un bucket de journaux. Vous pouvez également modifier les filtres dans le récepteur de journaux _Default.

Avant d'implémenter une telle stratégie, consultez les consignes relatives aux prix.

Tarifs

Pour en savoir plus sur les tarifs de Cloud Logging, consultez la page Tarifs de Google Cloud Observability.

Étapes suivantes

Pour vous aider à acheminer et à stocker les données Cloud Logging, consultez les documents suivants :