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

Last reviewed 2025-02-19 UTC

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 enquêteurs en sécurité, qui souhaitent configurer et exécuter le job d'importation de journaux. Ce document suppose également que vous savez exécuter des jobs d'importation Cloud Run et utiliser Cloud Storage et Cloud Logging.

Architecture

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

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

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 suivants de Google Cloud:

Obtenez une estimation des coûts en fonction de votre utilisation prévue, utilisez le simulateur de coût.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai sans frais.

Avant de commencer

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

  2. Dans la Google Cloud console, activez Cloud Shell.

    Activer Cloud Shell

  3. Créez ou sélectionnez un Google Cloud projet.

    Rôles requis pour sélectionner ou créer un projet

    • Sélectionner un projet : la sélection d'un projet ne nécessite pas de rôle IAM spécifique Vous pouvez sélectionner n'importe quel projet pour lequel un rôle vous a été attribué.
    • Créer un projet : pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.
    • Créez un Google Cloud projet :

      gcloud projects create PROJECT_ID

      Remplacez PROJECT_ID par le nom du Google Cloud projet que vous créez.

    • Sélectionnez le Google Cloud projet que vous avez créé :

      gcloud config set project PROJECT_ID

      Remplacez PROJECT_ID par le nom de votre Google Cloud projet.

    Remplacez PROJECT_ID par l'ID du projet de destination.

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

  5. Activez les API Cloud Run et Identity and Access Management (IAM) :

    Rôles requis pour activer les API

    Pour activer les API, vous devez disposer de l'autorisation serviceusage.services.enable. Si vous avez créé le projet, vous disposez probablement déjà de cette autorisation via le rôle Propriétaire (roles/owner). Sinon, vous pouvez obtenir cette autorisation via le rôle Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin). Découvrez comment attribuer des rôles.

    gcloud services enable run.googleapis.com iam.googleapis.com

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 d'utilisation du service (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 via des rôles personnalisés ou d'autres rôles prédéfinis.

Mettre à niveau le bucket de journaux pour utiliser Observability Analytics

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 les 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 ou l'utilisation d'Observability Analytics n'entraînent aucun frais supplémentaire.

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 Observability 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 la mise en œuvre pour modifier la durée 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 de 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 processeur, qui peut être de 1, 2, 4, 6 ou 8 processeurs. La valeur par défaut est 2. Vous pouvez augmenter le 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 le nombre si des délais avant expiration se produisent. Pour en savoir plus, consultez Configurer les limites de mémoire.
    • END_DATE : fin de la plage de dates au format MM/JJ/AAAA. Les journaux dont l'horodatage est antérieur ou égal à cette date sont importés.
    • LOG_ID : identifiant de journal des journaux que vous souhaitez importer. L'ID de journal fait partie du logName champ de l'entrée de journal. Exemple : cloudaudit.googleapis.com.
    • START_DATE : début de la plage de dates au format MM/JJ/AAAA. Les journaux dont l'horodatage est ultérieur ou égal à 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 augmentation 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 d'objets Storage 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 même 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 précédemment importés 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 journal du même projet, avec le même ID d'insertion et le même horodatage) des résultats de la requête. Pour en savoir plus, consultez le insert_id champ 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 plus d'options et d'informations sur 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 précédemment importés 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
    

Notez 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

Contributeurs

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

Autres contributeurs :