Importer des journaux depuis Cloud Storage vers Cloud Logging

Last reviewed 2025-02-19 UTC

Cette architecture de référence explique comment importer des journaux précédemment exportés vers Cloud Storage et les réimporter dans Cloud Logging.

Cette architecture de référence est destinée aux ingénieurs et aux développeurs, y compris les professionnels DevOps, les ingénieurs en fiabilité des sites (SRE) et les analystes de sécurité, qui souhaitent configurer et exécuter le job d'importation de journaux. Ce document part du principe que vous savez exécuter des jobs Cloud Run et utiliser Cloud Storage et Cloud Logging.

Architecture

Le diagramme suivant montre comment les services Google Cloud sont utilisés dans cette architecture de référence :

Diagramme du workflow d'importation de journaux depuis Cloud Storage vers Cloud Logging.

Ce workflow comprend les composants suivants :

  • Bucket Cloud Storage : contient les journaux précédemment exportés que vous souhaitez réimporter dans Cloud Logging. Comme ces journaux ont déjà été exportés, ils sont organisés dans le format d'exportation attendu.
  • Job Cloud Run : exécute le processus d'importation des journaux :
    • Lit les objets qui stockent les entrées de journaux à partir de Cloud Storage.
    • Recherche les journaux exportés pour l'ID de journal spécifié, dans la plage de dates demandée, en fonction de l'organisation des journaux exportés dans le bucket Cloud Storage.
    • Convertit les objets en structures LogEntry de l'API Cloud Logging. Plusieurs structures LogEntry sont agrégées en lots pour réduire la consommation du quota de l'API Cloud Logging. L'architecture gère les erreurs de quota si nécessaire.
    • Écrit les entrées de journal converties dans Cloud Logging. Si vous réexécutez le même job plusieurs fois, des entrées en double peuvent être créées. Pour en savoir plus, consultez Exécuter le job d'importation.
  • Cloud Logging : ingère et stocke les entrées de journal converties. Les entrées de journal sont traitées comme décrit dans la présentation du routage et du stockage.
    • Les quotas et limites de Logging s'appliquent, y compris les quotas et limites de l'API Cloud Logging, ainsi qu'une durée de conservation de 30 jours. Cette architecture de référence est conçue pour fonctionner avec les quotas d'écriture par défaut, avec un mécanisme de réessai de base. Si votre quota d'écriture est inférieur à la valeur par défaut, l'implémentation peut échouer.
    • Les journaux importés ne sont pas inclus dans les métriques basées sur les journaux, car leurs codes temporels sont dans le passé. Toutefois, si vous choisissez d'utiliser un libellé, l'horodatage enregistre l'heure d'importation et les journaux sont inclus dans les données de métriques.
  • BigQuery : utilise SQL pour exécuter des requêtes analytiques sur les journaux importés (facultatif). Pour importer des journaux d'audit depuis Cloud Storage, cette architecture modifie les ID de journaux. Vous devez tenir compte de ce changement de nom lorsque vous interrogez les journaux importés.

Cas d'utilisation

Vous pouvez choisir de déployer cette architecture si votre organisation requiert une analyse des journaux supplémentaire pour les enquêtes sur les incidents ou d'autres audits d'événements antérieurs. Par exemple, vous pouvez analyser les connexions à vos bases de données pour le premier trimestre de l'année dernière, dans le cadre d'un audit des accès aux bases de données.

Alternatives de conception

Cette section décrit des alternatives à la conception par défaut présentée dans ce document sur l'architecture de référence.

Durée de conservation et journaux importés

Cloud Logging exige que les entrées de journal entrantes aient un horodatage ne dépassant pas la durée de conservation de 30 jours. Les entrées de journal importées dont l'horodatage est antérieur de plus de 30 jours à la date d'importation ne sont pas stockées.

Cette architecture valide la plage de dates définie dans le job Cloud Run pour éviter d'importer des journaux datant de plus de 29 jours, ce qui laisse une marge de sécurité d'un jour.

Pour importer des journaux datant de plus de 29 jours, vous devez apporter les modifications suivantes au code de mise en œuvre, puis créer une image de conteneur à utiliser dans la configuration de la tâche Cloud Run.

  • Supprimer la validation de la plage de dates de 30 jours
  • Ajouter l'horodatage d'origine en tant que libellé utilisateur à l'entrée de journal
  • Réinitialiser le libellé d'horodatage de l'entrée de journal pour permettre son ingestion avec l'horodatage actuel

Lorsque vous utilisez cette modification, vous devez utiliser le champ labels au lieu du champ timestamp dans vos requêtes d'analyse des journaux. Pour en savoir plus sur les requêtes et les exemples d'analyse de journaux, consultez Exemples de requêtes SQL.

Considérations de conception

Les consignes suivantes peuvent vous aider à développer une architecture répondant aux exigences de votre organisation.

Optimisation des coûts

Le coût de l'importation de journaux à l'aide de cette architecture de référence dépend de plusieurs facteurs.

Vous allez utiliser les composants facturables suivants de Google Cloud :

Tenez compte des facteurs suivants qui peuvent augmenter les coûts :

  • Duplication des journaux : pour éviter des coûts de stockage de journaux supplémentaires, n'exécutez pas la tâche d'importation plusieurs fois avec la même configuration.
  • Stockage dans des destinations supplémentaires : pour éviter des coûts de stockage de journaux supplémentaires, désactivez les règles de routage dans le projet de destination afin d'empêcher le stockage des journaux dans des emplacements supplémentaires ou le transfert des journaux vers d'autres destinations telles que Pub/Sub ou BigQuery.
  • Processeur et mémoire supplémentaires : si votre tâche d'importation expire, vous devrez peut-être augmenter le processeur et la mémoire de la tâche d'importation dans la configuration de la tâche d'importation. L'augmentation de ces valeurs peut entraîner une augmentation des coûts Cloud Run.
  • Tâches supplémentaires: si le nombre attendu de journaux à importer chaque jour au cours de la période est élevé, vous devrez peut-être augmenter le nombre de tâches dans la configuration de la tâche d'importation. Le job répartit la plage de temps de manière égale entre les tâches. Chaque tâche traite donc simultanément un nombre de jours similaire de la plage. L'augmentation du nombre de tâches peut entraîner une augmentation des coûts Cloud Run.
  • Classe de stockage: si la classe de stockage de votre bucket Cloud Storage est autre que Standard, par exemple Nearline, Durable Reduced Availability (DRA) ou Coldline, des frais supplémentaires peuvent vous être facturés.
  • Trafic de données entre différents emplacements : configurez le job d'importation pour qu'il s'exécute dans le même emplacement que le bucket Cloud Storage à partir duquel vous importez les journaux. Sinon, des coûts de sortie réseau peuvent s'appliquer.

Pour obtenir une estimation des coûts en fonction de votre utilisation prévue, y compris pour les jobs Cloud Run, utilisez le simulateur de coût.

Efficacité opérationnelle

Cette section décrit les considérations relatives à la gestion des requêtes analytiques après le déploiement de la solution.

Noms et requêtes de journaux

Les journaux sont stockés dans le projet défini dans le champ logName de l'entrée de journal. Pour importer les journaux dans le projet sélectionné, cette architecture modifie le champ logName de chaque journal importé. Les journaux d'importation sont stockés dans le bucket de journaux par défaut du projet sélectionné, avec l'ID de journal imported_logs (sauf si le projet dispose d'une règle de routage des journaux qui modifie la destination de stockage). La valeur d'origine du champ logName est conservée dans le champ labels avec la clé original_logName.

Vous devez tenir compte de l'emplacement de la valeur logName d'origine lorsque vous interrogez les journaux importés. Pour en savoir plus sur les requêtes et les exemples d'analyse de journaux, consultez Exemples de requêtes SQL.

Optimisation des performances

Si le volume de journaux que vous importez dépasse les limites de capacité de Cloud Run, le délai d'expiration de la tâche peut être dépassé avant la fin de l'importation. Pour éviter une importation de données incomplète, envisagez d'augmenter la valeur tasks dans la tâche d'importation. L'augmentation des ressources de processeur et de mémoire peut également améliorer les performances des tâches lorsque vous augmentez leur nombre.

Déploiement

Pour déployer cette architecture, consultez Déployer un job pour importer des journaux depuis Cloud Storage vers Cloud Logging.

Étape suivante

Contributeurs

Auteur : Leonid Yankulin | Ingénieur en relations avec les développeurs

Autres contributeurs :