Importer des journaux depuis Cloud Storage vers Cloud Logging

Last reviewed 2024-01-02 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 aux DevOps, aux ingénieurs en fiabilité des sites (SRE) et aux enquêteurs de sécurité, qui souhaitent configurer et exécuter la tâche d'importation des journaux. Ce document part du principe que vous savez exécuter des jobs Cloud Run et utiliser Cloud Storage et Cloud Logging.

Architecture

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

Diagramme de 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. Étant donné que 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 journal à partir de Cloud Storage.
    • Recherche les journaux exportés pour l'ID de journal spécifié, dans la période 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 regroupées par lot pour réduire la consommation de 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 la tâche 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 section 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 nouvelle tentative de base. Si votre quota d'écriture est inférieur au quota par défaut, l'implémentation risque d'é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étrique.
  • BigQuery: utilise SQL pour exécuter des requêtes analytiques sur les journaux importés (facultatif). Pour importer des journaux d'audit à partir de Cloud Storage, cette architecture modifie les ID de journal. 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 d'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 d'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 date de plus de 30 jours à compter de l'heure d'importation ne sont pas stockées.

Cette architecture valide la plage de dates définie dans la tâche Cloud Run pour éviter d'importer des journaux datant de plus de 29 jours, en laissant 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 sur 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 Log Analytics. Pour en savoir plus sur les requêtes et les exemples Log Analytics, consultez la section 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 d'importation des journaux à l'aide de cette architecture de référence est influencé par plusieurs facteurs.

Vous utilisez les composants facturables de Google Cloud suivants:

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

  • Duplication des journaux: pour éviter des coûts de stockage supplémentaires des journaux, n'exécutez pas la tâche d'importation avec la même configuration plusieurs fois.
  • Stockage dans des destinations supplémentaires: pour éviter les coûts supplémentaires liés au stockage des journaux, désactivez les stratégies de routage au niveau du projet de destination afin d'éviter le stockage des journaux dans d'autres emplacements ou le transfert des journaux vers d'autres destinations telles que Pub/Sub ou BigQuery.
  • CPU et mémoire supplémentaires: si votre tâche d'importation expire, vous devrez peut-être augmenter la quantité de CPU et de mémoire de la tâche d'importation dans la configuration de la tâche d'importation. Augmenter 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épartira la période de manière égale entre les tâches. Chaque tâche traitera donc un nombre similaire de jours de la période en même temps. Augmenter le 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 la tâche d'importation pour qu'elle s'exécute dans le même emplacement que le bucket Cloud Storage à partir duquel vous importez les journaux. Sinon, des frais de sortie réseau peuvent s'appliquer.

Pour générer une estimation des coûts en fonction de votre utilisation prévue, y compris des tâches 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 Log Analytics, 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, la tâche peut expirer 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. Augmenter les ressources processeur et mémoire peut également contribuer à améliorer les performances des tâches lorsque vous augmentez leur nombre.

Déploiement

Pour déployer cette architecture, consultez la section Déployer une tâche 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 :