Déployer une tâche pour importer des journaux depuis Cloud Storage vers Cloud Logging

Ce document explique comment déployer l'architecture de référence décrite dans Importer des journaux depuis Cloud Storage vers Cloud Logging.

Ces instructions sont destinées 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 également du principe que vous savez exécuter des jobs d'importation 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 :

Pour plus d'informations, consultez la section Importer des journaux depuis Cloud Storage vers Cloud Logging.

Objectifs

• Créer et configurer un job d'importation Cloud Run
• Créer un compte de service pour exécuter le pipeline

Coûts

Dans ce document, vous utilisez les composants facturables de Google Cloudsuivants :

• Cloud Logging
• Cloud Run
• Cloud Storage

Vous pouvez obtenir une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

1. Assurez-vous que les journaux que vous souhaitez importer ont été exportés vers Cloud Storage. Cela signifie qu'ils sont déjà organisés dans le format d'exportation attendu.

2. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

3. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

   Remplacez PROJECT_ID par l'ID du projet de destination.

4. Assurez-vous que la facturation est activée pour votre projet Google Cloud .

Rôles requis

Pour obtenir les autorisations nécessaires afin de déployer cette solution, demandez à votre administrateur de vous accorder les rôles IAM suivants :

• Pour accorder le rôle "Rédacteur de journaux" sur le bucket de journaux : Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) sur le projet de destination
• Pour accorder le rôle Lecteur des objets Storage sur le bucket de stockage : Administrateur de l'espace de stockage (roles/storage.admin) sur le projet où le bucket de stockage est hébergé
• Pour créer un compte de service : Créer des comptes de service (roles/iam.serviceAccountCreator) sur le projet de destination
• Pour activer les services sur le projet : Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin) sur le projet de destination
• Pour mettre à niveau le bucket de journaux et supprimer les journaux importés : Administrateur Logging (roles/logging.admin) sur le projet de destination
• Pour créer, exécuter et modifier le job d'importation : Développeur Cloud Run (roles/run.developer) sur le projet de destination

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Mettre à niveau un bucket de journaux pour utiliser l'Analyse de journaux

Nous vous recommandons d'utiliser le bucket de journaux par défaut et de le mettre à niveau pour utiliser Log Analytics. Toutefois, dans un environnement de production, vous pouvez utiliser votre propre bucket de journaux si le bucket par défaut ne répond pas à vos exigences. Si vous décidez d'utiliser votre propre bucket, vous devez acheminer les journaux ingérés vers le projet de destination vers ce bucket de journaux. Pour en savoir plus, consultez Configurer des buckets de journaux et Créer un récepteur.

Lorsque vous mettez à niveau le bucket, vous pouvez utiliser SQL pour interroger et analyser vos journaux. La mise à niveau du bucket et l'utilisation de l'analyse de journaux n'entraînent aucuns frais supplémentaires.

Pour mettre à niveau le bucket de journaux par défaut dans le projet de destination, procédez comme suit:

• Mettez à niveau le bucket de journaux par défaut pour utiliser Log Analytics:

  gcloud logging buckets update BUCKET_ID --location=LOCATION --enable-analytics
  

  Remplacez les éléments suivants :

  • BUCKET_ID: nom du bucket de journaux (par exemple, _Default)
  • LOCATION : région disponible (par exemple, global)

Créer le job d'importation Cloud Run

Lorsque vous créez le job, vous pouvez utiliser l'image de conteneur prédéfinie fournie pour cette architecture de référence. Si vous devez modifier l'implémentation pour changer la période de conservation de 30 jours ou si vous avez d'autres exigences, vous pouvez créer votre propre image personnalisée.

• Dans Cloud Shell, créez le job avec les configurations et les variables d'environnement :

  gcloud run jobs create JOB_NAME \
  --image=IMAGE_URL \
  --region=REGION \
  --tasks=TASKS \
  --max-retries=0 \
  --task-timeout=60m \
  --cpu=CPU \
  --memory=MEMORY \
  --set-env-vars=END_DATE=END_DATE,LOG_ID=LOG_ID,\
  START_DATE=START_DATE,STORAGE_BUCKET_NAME=STORAGE_BUCKET_NAME,\
  PROJECT_ID=PROJECT_ID
  

  Remplacez les éléments suivants :

  • JOB_NAME : nom de votre job.
  • IMAGE_URL : référence à l'image de conteneur. Utilisez us-docker.pkg.dev/cloud-devrel-public-resources/samples/import-logs-solution ou l'URL de l'image personnalisée si vous en avez créé une en suivant les instructions sur GitHub.
  • REGION : région dans laquelle vous souhaitez placer votre tâche. Pour éviter des coûts supplémentaires, nous vous recommandons de conserver la même région de tâche ou de la laisser dans la même zone multirégionale que la région du bucket Cloud Storage. Par exemple, si votre bucket est multirégional aux États-Unis, vous pouvez utiliser us-central1. Pour en savoir plus, consultez Optimisation des coûts.
  • TASKS : nombre de tâches que le job doit exécuter. La valeur par défaut est 1. Vous pouvez augmenter le nombre de tâches si des délais avant expiration se produisent.
  • CPU : limite de processeurs, qui peut être de 1, 2, 4, 6 ou 8 processeurs. La valeur par défaut est 2. Vous pouvez augmenter ce nombre si des délais avant expiration se produisent. Pour en savoir plus, consultez Configurer les limites de processeur.
  • MEMORY : limite de mémoire. La valeur par défaut est 2Gi. Vous pouvez augmenter ce nombre si des délais d'attente se produisent. Pour en savoir plus, consultez Configurer les limites de mémoire.
  • END_DATE : fin de la période au format MM/JJ/AAAA. Les journaux dont les codes temporels sont antérieurs ou égaux à cette date sont importés.
  • LOG_ID : identifiant de journal des journaux que vous souhaitez importer. L'ID de journal fait partie du champ logName de l'entrée de journal. Par exemple, cloudaudit.googleapis.com.
  • START_DATE : début de la période au format MM/JJ/AAAA. Les journaux dont les codes temporels sont ultérieurs ou égaux à cette date sont importés.
  • STORAGE_BUCKET_NAME : nom du bucket Cloud Storage dans lequel les journaux sont stockés (sans le préfixe gs://).

  L'option max-retries est définie sur zéro pour éviter les nouvelles tentatives pour les tâches ayant échoué, ce qui peut entraîner des entrées de journal en double.

  Si le job Cloud Run échoue en raison d'un délai avant expiration, l'importation peut être incomplète. Pour éviter les importations incomplètes en raison de délais avant expiration, augmentez la valeur tasks, ainsi que les ressources de processeur et de mémoire.

L'augmentation de ces valeurs peut entraîner une hausse des coûts. Pour en savoir plus sur les coûts, consultez Optimisation des coûts.

Créer un compte de service pour exécuter votre tâche Cloud Run

1. Dans Cloud Shell, créez le compte de service géré par l'utilisateur:

   gcloud iam service-accounts create SA_NAME
   

   Remplacez SA_NAME par le nom du compte de service.

2. Attribuez le rôle Lecteur des objets de l'espace de stockage sur le bucket de stockage :

   gcloud storage buckets add-iam-policy-binding gs://STORAGE_BUCKET_NAME \
   --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/storage.objectViewer
   

   Remplacez les éléments suivants :

   • STORAGE_BUCKET_NAME : nom du bucket de stockage que vous avez utilisé dans la configuration du job d'importation. Par exemple, my-bucket.
   • PROJECT_ID: ID du projet de destination.

3. Attribuez le rôle Rédacteur de journaux sur le bucket de journaux :

   gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/logging.logWriter
   

4. Définissez le compte de service pour la tâche Cloud Run:

   gcloud run jobs update JOB_NAME \
   --region=REGION \
   --service-account SA_NAME@PROJECT_ID.iam.gserviceaccount.com
   

   Remplacez REGION par la région dans laquelle vous avez déployé le job d'importation Cloud Run.

Exécuter le job d'importation

• Dans Cloud Shell, exécutez le job créé :

  gcloud run jobs execute JOB_NAME \
  --region=REGION
  

Pour en savoir plus, consultez Exécuter des jobs et Gérer les exécutions de jobs.

Si vous devez réexécuter le job, supprimez les journaux importés précédemment pour éviter de créer des doublons. Pour en savoir plus, consultez Supprimer les journaux importés plus loin dans ce document.

Lorsque vous interrogez les journaux importés, les doublons n'apparaissent pas dans les résultats de la requête. Cloud Logging supprime les doublons (entrées de journaux provenant du même projet, avec le même ID d'insertion et le même code temporel) des résultats de requête. Pour en savoir plus, consultez le champ insert_id dans la documentation de référence de l'API Logging.

Vérifier les résultats

Pour vérifier que le job s'est terminé correctement, vous pouvez interroger les résultats de l'importation dans Cloud Shell :

  gcloud logging read 'log_id("imported_logs") AND timestamp<=END_DATE'

Le résultat affiche les journaux importés. Si ce projet a été utilisé pour exécuter plusieurs jobs d'importation au cours de la période spécifiée, le résultat affiche également les journaux importés à partir de ces jobs.

Pour en savoir plus sur les options et les détails concernant l'interrogation des entrées de journal, consultez gcloud logging read.

Supprimer les journaux importés

Si vous devez exécuter le même job plusieurs fois, supprimez les journaux importés précédemment pour éviter les entrées en double et l'augmentation des coûts.

• Pour supprimer les journaux importés, exécutez la commande de suppression des journaux dans Cloud Shell :

  gcloud logging logs delete imported_logs
  

Sachez que la suppression des journaux importés efface toutes les entrées de journal qui ont été importées dans le projet de destination, et pas seulement les résultats de la dernière exécution du job d'importation.

Étape suivante

• Examinez le code d'implémentation dans le dépôt GitHub.
• Découvrez comment analyser les journaux importés à l'aide de l'Analyse de journaux et de SQL.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.

Contributeurs

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

Autres contributeurs :

• Summit Tuladhar | Ingénieur logiciel senior
• Wilton Wong | Architecte d'entreprise
• Xiang Shen | Architecte de solutions