Résoudre les problèmes liés à la mise à niveau d'un bucket pour utiliser Analyse de l'observabilité

La mise à niveau d'un bucket de journaux pour utiliser Observability Analytics vous permet d'exécuter des requêtes SQL pour analyser les données de journaux stockées dans ce bucket. Si la mise à niveau d'un bucket de journaux échoue ou se bloque, vous pouvez utiliser ce document pour diagnostiquer et résoudre les erreurs de validation synchrone, les erreurs de provisionnement asynchrone et les opérations bloquées. Pour savoir comment mettre à niveau un bucket de journaux, consultez Mettre à niveau un bucket pour utiliser l'Analyse de l'observabilité.

À propos du processus de mise à niveau

Cloud Logging utilise un processus en deux étapes lorsque vous exécutez une commande pour mettre à niveau un bucket de journaux afin d'utiliser l'Analyse de l'observabilité :

  1. Validation synchrone : Logging valide les paramètres de la commande. Si la validation échoue, la commande renvoie immédiatement une erreur.
  2. Provisionnement asynchrone : si la validation réussit, Logging lance une opération de longue durée qui se termine généralement en 10 minutes.

Les mises à niveau des buckets de journaux sont des opérations auditées. Pour vérifier l'état de l'opération de longue durée ou trouver des détails sur l'erreur, vous pouvez interroger l'opération à l'aide de la méthode Operations.GetOperation ou interroger vos journaux d'audit.

État du bucket de journaux pendant une mise à niveau

Lorsque la validation synchrone d'une requête de mise à niveau réussit, Logging remplace l'état du bucket de journaux ACTIVE par UPDATING et démarre l'opération de longue durée. Une fois l'opération terminée, l'état du bucket de journaux repasse à ACTIVE.

Vous pouvez déterminer l'état actuel d'un bucket de journaux en exécutant la commande gcloud logging buckets describe :

gcloud logging buckets describe LOG_BUCKET_ID \
  --location=LOCATION_ID \
  --project=PROJECT_ID

Avant d'exécuter la commande, effectuez les remplacements suivants :

  • PROJECT_ID: ID de votre projet
  • LOCATION_ID : emplacement de votre bucket.
  • LOG_BUCKET_ID : ID de votre bucket.

Le champ lifecycleState de la réponse indique l'état du bucket :

description: Default bucket
lifecycleState: ACTIVE
name: projects/PROJECT_ID/locations/LOCATION_ID/buckets/LOG_BUCKET_ID
retentionDays: 30

Dans la console Google Cloud , lorsque le bucket de journaux est à l'état UPDATING :

  • Sur la page Stockage des journaux, la colonne Analyse de l'observabilité disponible affiche Mise à niveau… tant que l'opération de longue durée est active (ou Non éligible à la mise à niveau si la console ne peut pas récupérer l'état de l'opération).
  • Dans les panneaux Modifier le bucket et Mettre à niveau le bucket de journaux, l'option permettant de mettre à niveau le bucket est désactivée, et l'info-bulle indique Aucune mise à jour en attente comme condition non remplie.

Points à prendre en compte concernant les périmètres VPC Service Controls

Les mises à niveau des buckets de journaux dans un périmètre VPC Service Controls peuvent échouer, car les API sont bloquées par le périmètre ou en raison de configurations multiprojets.

API que le périmètre doit autoriser

Pour mettre à niveau un bucket de journaux situé dans un périmètre VPC Service Controls, le périmètre ne doit pas restreindre les services suivants :

  • logging.googleapis.com
  • cloudkms.googleapis.com : requis pour mettre à niveau un bucket de journaux qui utilise une clé de chiffrement gérée par le client (CMEK).

La restriction de ces services entraîne le comportement suivant :

  • logging.googleapis.com restreint : la commande de mise à niveau échoue immédiatement avec une erreur PERMISSION_DENIED, et votre bucket de journaux reste à l'état ACTIVE.

    Résolution : Mettez à jour le périmètre pour autoriser les API listées au début de cette section, puis réessayez d'exécuter la commande.

  • cloudkms.googleapis.com restreint : pour les buckets de journaux protégés par CMEK, l'opération de longue durée échoue avec une erreur INTERNAL et votre bucket de journaux revient à l'état ACTIVE.

    Résolution : Mettez à jour le périmètre pour autoriser les API listées au début de cette section, puis réessayez d'exécuter la commande.

Configurations CMEK entre périmètres

Vous ne pouvez pas utiliser de règles d'entrée ou de sortie basées sur l'identité pour accorder un accès inter-périmètre à la clé Cloud Key Management Service lorsque votre bucket de journaux et votre clé Cloud KMS se trouvent dans des périmètres VPC Service Controls différents.

Pour cette configuration, si votre règle d'entrée ne spécifie que l'identité du compte de service Logging, voici ce qui se produit :

  • Le provisionnement asynchrone échoue avec une erreur INTERNAL et votre bucket de journaux revient à l'état ACTIVE.
  • Un journal d'audit des règles du projet Cloud KMS enregistre l'échec. Ce journal d'audit montre que la méthode google.cloud.kms.v1.KeyManagementService.Encrypt a échoué avec une violation d'entrée NO_MATCHING_ACCESS_LEVEL et indique qu'elle concerne un compte de service de chiffrement BigQuery.

Solution : Dans la règle d'entrée qui autorise l'accès au périmètre Cloud KMS, définissez identityType sur ANY_IDENTITY et spécifiez le projet contenant le bucket de journaux en tant que ressource source :

- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/PROJECT_NUMBER
  ingressTo:
    operations:
    - serviceName: cloudkms.googleapis.com
      methodSelectors:
      - method: '*'
    resources:
    - projects/KMS_PROJECT_NUMBER

Dans l'exemple précédent, remplacez les éléments suivants :

  • PROJECT_NUMBER : numéro du projet contenant le bucket de journaux.
  • KMS_PROJECT_NUMBER : numéro du projet contenant la clé Cloud KMS.

Si vous spécifiez également une règle de sortie, elle doit également définir identityType: ANY_IDENTITY.

Interroger les journaux d'audit pour obtenir des informations sur les échecs

Les requêtes de cette section peuvent vous aider à trouver les entrées de journal qui signalent des échecs lors de la mise à jour ou de la mise à niveau d'un bucket de journaux. Ces requêtes sont destinées à être utilisées avec l'explorateur de journaux.

Dans la console Google Cloud , accédez à la pageExplorateur de journaux :

Accéder à l'explorateur de journaux

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

Interroger toutes les mises à jour ou mises à niveau de buckets ayant échoué dans un projet

log_id("cloudaudit.googleapis.com/activity")
protoPayload.serviceName="logging.googleapis.com"
(protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucket" OR
 protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucketAsync")
severity=ERROR

Si vous utilisez la console Google Cloud pour mettre à niveau votre bucket de journaux afin d'utiliser l'Analyse de l'observabilité et créer un ensemble de données BigQuery associé, utilisez la requête suivante :

log_id("cloudaudit.googleapis.com/activity")
(protoPayload.serviceName="logging.googleapis.com" OR
 protoPayload.serviceName="bigquery.googleapis.com")
(protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucket" OR
 protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucketAsync" OR
 protoPayload.methodName="google.cloud.bigquery.v2.DatasetService.InsertDataset")
severity=ERROR

Les résultats de la requête précédente incluent des entrées de journal indiquant que la création de l'ensemble de données BigQuery associé a échoué. Le message d'erreur peut vous aider à résoudre la cause de l'échec.

Interroger les mises à jour ou les mises à niveau de bucket ayant échoué pour un bucket spécifique

Avant d'utiliser la requête suivante, effectuez les remplacements suivants :

  • PROJECT_ID: ID de votre projet
  • LOCATION_ID : emplacement de votre bucket.
  • LOG_BUCKET_ID : ID de votre bucket.
log_id("cloudaudit.googleapis.com/activity")
protoPayload.serviceName="logging.googleapis.com"
(protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucket" OR
 protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucketAsync")
protoPayload.resourceName="projects/PROJECT_ID/locations/LOCATION_ID/buckets/LOG_BUCKET_ID"
severity=ERROR

Rechercher les échecs d'opération de longue durée

log_id("cloudaudit.googleapis.com/activity")
protoPayload.serviceName="logging.googleapis.com"
protoPayload.methodName="google.logging.v2.ConfigServiceV2.UpdateBucketAsync"
operation.last=true
severity=ERROR

INVALID_ARGUMENT (3)

Le message d'erreur fourni avec un code d'erreur INVALID_ARGUMENT (3) contient suffisamment d'informations pour vous permettre de résoudre le problème. C'est pourquoi cette section n'énumère pas tous les messages d'erreur possibles.

Problèmes liés aux noms de ressources

Pour résoudre les problèmes liés aux noms de ressources, transmettez un nom de ressource de bucket valide au format projects/PROJECT_ID/locations/LOCATION_ID/buckets/LOG_BUCKET_ID.

Assurez-vous que la longueur du nom de la ressource ne dépasse pas les limites autorisées.

Problèmes de masque de mise à jour

Un message d'erreur contenant le texte update_mask ou Update mask indique une valeur manquante ou incorrecte.

Pour résoudre ce problème, spécifiez update_mask dans la commande API et définissez la valeur sur "analytics_enabled".

Problèmes d'éligibilité des buckets de journaux

  • Vous ne pouvez pas mettre à niveau un bucket de journaux _Default verrouillé ni des buckets personnalisés verrouillés. Vous pouvez mettre à niveau le bucket _Required lorsqu'il est verrouillé.

    Lorsqu'un bucket de journaux est verrouillé, le message d'erreur est "Bucket is not eligible for an upgrade to enable analytics".

    Pour résoudre ce problème, créez un bucket avec analyse activée et acheminez-y les journaux.

  • Vous ne pouvez pas mettre à niveau un bucket de journaux en même temps que vous apportez d'autres modifications au bucket. Par exemple, vous ne pouvez pas mettre à niveau un bucket de journaux et mettre à jour sa description.

    Pour résoudre ce problème, envoyez une requête UpdateBucket ou UpdateBucketAsync distincte avec uniquement analytics_enabled dans update_mask, puis mettez à jour les autres champs du bucket de journaux dans une requête distincte.

  • Vous ne pouvez pas mettre à niveau les buckets de journaux dans les organisations, les dossiers ou les comptes de facturation. Vous ne pouvez mettre à niveau que les buckets de journaux dont le parent est un projet Google Cloud .

  • Vous ne pouvez pas mettre à niveau un bucket de journaux qui a déjà été mis à niveau ou qui est en cours de mise à niveau.

    Utilisez GetBucket ou ListOperations pour déterminer si une mise à niveau est déjà terminée ou en cours.

Problèmes liés aux clés Cloud KMS

Messages d'erreur :

  • "Not a valid key reference (wrong type): 'KMS_KEY_NAME'"
  • "Name "KMS_KEY_NAME" is missing the COMPONENT component. Expected the form projects/[PROJECT_ID]/locations/[ID]/keyRings/[ID]/cryptoKeys/[ID]"

Résolution : Mettez à jour le cmek_settings.kms_key_name du bucket de journaux avec un nom de ressource Cloud KMS CryptoKey valide avant de mettre à niveau le bucket. Vous devez mettre à jour le nom de la ressource, et non la version de la clé, CryptoKeyVersion.

Message d'argument non valide

Si le message "Request contains an invalid argument." s'affiche, essayez de procéder comme suit pour les buckets de journaux pour lesquels CMEK est activé :

  • Assurez-vous que le compte de service Logging associé à la configuration CMEK du bucket est initialisé.
  • Assurez-vous que le bucket est associé à une durée de conservation positive.

Pour trouver le nom du compte de service, exécutez la commande suivante après avoir mis à jour le bucket de journaux, l'emplacement et les ID de projet :

gcloud logging buckets describe LOG_BUCKET_ID --location=LOCATION_ID --project=PROJECT_ID

Le compte de service peut se trouver dans un projet, un dossier ou une organisation.

DEADLINE_EXCEEDED (4)

Utilisez UpdateBucketAsync et interrogez l'opération de longue durée renvoyée à l'aide de la méthode Operations.GetOperation, ou appelez GetBucket une fois la mise à niveau en arrière-plan terminée.

NOT_FOUND (5)

Pour résoudre ces échecs, essayez les solutions suivantes :

  • Vérifiez que l'ID du projet ou le numéro du projet est correct et que le projet est actif. Si le projet est en attente de suppression, restaurez-le d'abord.
  • Assurez-vous que l'emplacement spécifié est compatible avec Logging.
  • Vérifiez que l'ID de bucket de journaux et l'emplacement existent dans le projet et que le bucket cible n'est pas _CloudTrace.

PERMISSION_DENIED (7)

Une erreur d'autorisation refusée indique que l'action demandée n'est pas autorisée.

Autorisations de l'utilisateur manquantes

Pour mettre à niveau un bucket de journaux, assurez-vous que l'appelant dispose d'un rôle Identity and Access Management (IAM) incluant l'autorisation logging.buckets.update (par exemple, roles/logging.configWriter ou roles/logging.admin), et vérifiez qu'aucune règle d'administration personnalisée ne bloque la mise à jour.

Restrictions liées aux règles d'administration

Pour résoudre le message d'erreur "Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: [ID]", assurez-vous que le périmètre VPC Service Controls ne limite pas le service logging.googleapis.com. Pour en savoir plus, consultez Points à prendre en compte concernant les périmètres VPC Service Controls.

Problèmes liés aux points de terminaison régionaux

Pour résoudre les erreurs d'autorisation refusée lorsque des points de terminaison régionaux sont spécifiés, envoyez la requête au point de terminaison global (logging.googleapis.com) ou au point de terminaison régional correspondant à l'emplacement du bucket de journaux.

RESOURCE_EXHAUSTED (8)

Pour résoudre ce problème, attendez que les opérations de provisionnement en cours se terminent, puis réessayez avec un intervalle exponentiel entre les tentatives.

FAILED_PRECONDITION (9)

Pour résoudre ces échecs, essayez les solutions suivantes :

  • Vérifiez que le bucket de journaux est à l'état ACTIVE. Vous ne pouvez pas mettre à niveau un bucket de journaux en cours de suppression, de mise à jour ou de provisionnement.

    Pour savoir comment déterminer l'état d'un bucket de journaux, consultez État du bucket de journaux lors d'une mise à niveau.

  • Vous ne pouvez pas mettre à niveau un bucket de journaux verrouillé.

  • Le message générique "Precondition check failed." indique que l'état du bucket n'est pas ACTIVE. Attendez qu'une opération en cours se termine, puis réessayez d'effectuer la mise à niveau.

INTERNAL (13)

Messages d'erreur :

  • Opération de longue durée (Operations.GetOperation) : "Failed to create analytics enabled bucket."
  • Cloud Audit Logs et UpdateBucket synchrone : "Internal error encountered."

Résolution : essayez les solutions suivantes :

  • Pour un bucket de journaux compatible avec CMEK, vérifiez que la clé Cloud KMS est activée, que le compte de service Logging associé à la configuration CMEK du bucket dispose du rôle roles/cloudkms.cryptoKeyEncrypterDecrypter sur la clé, que la clé est accessible à BigQuery et qu'aucune règle d'administration ni aucun périmètre VPC Service Controls ne bloque l'accès à Cloud KMS.

    Pour trouver le nom du compte de service, exécutez la commande suivante :

    gcloud logging buckets describe LOG_BUCKET_ID --location=LOCATION_ID --project=PROJECT_ID

    Le compte de service peut se trouver dans un projet, un dossier ou une organisation.

  • Inspectez les vues de journaux existantes sur le bucket (logging.views.list) pour vous assurer que leurs filtres sont valides, puis réessayez de mettre à niveau le bucket.

  • Assurez-vous que le bucket de journaux n'a pas été supprimé (DELETE_REQUESTED) et qu'aucune action administrative conflictuelle n'est en cours sur le bucket, puis réessayez d'effectuer la mise à niveau.

  • Réessayez de mettre à niveau le bucket de journaux une fois que les erreurs temporaires de création d'ensemble de données de stockage BigQuery ou d'index de recherche sont résolues, ou une fois que la disponibilité de BigQuery, de Cloud KMS ou du service de provisionnement en aval est rétablie. Si l'échec persiste, contactez Cloud Customer Care.

UNAVAILABLE (14)

Si le message "The service is currently unavailable." s'affiche, relancez la requête UpdateBucketAsync avec un intervalle exponentiel entre les tentatives.