Corriger les exigences de résidence des données et de CMEK

Vous pouvez reprovisionner un bucket d'observabilité pour répondre aux exigences réglementaires de résidence et de chiffrement des données. Après le reprovisionnement, l'emplacement de stockage et la configuration de chiffrement du bucket _Trace correspondent à vos paramètres par défaut pour les buckets d'observabilité.

Pour réapprovisionner un bucket, configurez vos paramètres par défaut, puis appelez la méthode de réapprovisionnement. L'opération de reprovisionnement peut effectuer l'une des opérations suivantes :

  • Appliquez rétroactivement une clé Cloud Key Management Service à un bucket d'observabilité sans modifier son emplacement de stockage.
  • Modifiez l'emplacement de stockage d'un bucket d'observabilité et utilisez le chiffrement par défaut de Google.
  • Modifiez l'emplacement de stockage d'un bucket d'observabilité et utilisez une clé Cloud KMS pour chiffrer les données stockées.

Ne reprovisionnez pas un bucket d'observabilité lorsque vous souhaitez modifier son nom à afficher, sa description ou sa clé Cloud KMS. Dans ce cas, mettez à jour le bucket d'observabilité.

Fonctionnement du reprovisionnement

Lorsque vous lancez une opération de reprovisionnement, le système effectue les étapes suivantes :

  1. Le système détermine si le bucket d'observabilité est éligible au reprovisionnement. Un bucket d'observabilité est éligible lorsque toutes les vérifications suivantes sont réussies :

    • Le bucket d'observabilité est nommé _Trace.
    • Le bucket n'a pas été reprovisionné.
    • Les paramètres par défaut des buckets d'observabilité sont trouvés.
    • Pour être conforme aux paramètres par défaut, l'emplacement du bucket d'observabilité doit être modifié ou le chiffrement doit passer du chiffrement par défaut de Google à CMEK.

  2. Le système met à jour la configuration du bucket. Ce processus prend quatre à cinq heures.

Limites

Les limites suivantes s'appliquent :

  • Le système n'autorise qu'une seule opération de reprovisionnement par bucket d'observabilité. Les requêtes ultérieures échouent avec une erreur FAILED_PRECONDITION.

  • Vous ne pouvez reprovisionner que les buckets nommés _Trace.

  • Vous ne pouvez pas accéder aux données stockées avant le lancement du reprovisionnement. Ces données ont été supprimées et ne peuvent pas être récupérées.

  • Si l'emplacement du bucket change, les liens et les ensembles de données BigQuery associés sont supprimés. Vous devez recréer tous les liens.

  • Si l'emplacement du bucket change, vous devez mettre à jour manuellement les vues d'analyse existantes.

  • Vous ne pouvez pas annuler une opération de reprovisionnement. Les tentatives d'annulation de l'opération sont ignorées.

  • Le comportement des requêtes lors d'une opération de reprovisionnement n'est pas défini.

Audits

Pour déterminer l'historique de reprovisionnement d'un bucket d'observabilité, vous pouvez utiliser vos journaux d'audit. Les journaux d'activité d'administration enregistrent l'auteur d'une demande de reprovisionnement, le bucket d'observabilité concerné et la réponse initiale.

Pour trouver ces enregistrements, appliquez les filtres suivants dans l'explorateur de journaux :

logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity" AND
resource.type="audited_resource" AND
resource.labels.service="observability.googleapis.com" AND
resource.labels.method="google.cloud.observability.v1.Observability.ReprovisionBucket"

L'exemple partiel suivant montre un journal d'audit des activités d'administration :

  {
    "logName": "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity",
    "resource": {
      "type": "audited_resource",
      "labels": {
        "project_id": "PROJECT_ID",
        "service": "observability.googleapis.com",
        "method": "google.cloud.observability.v1.Observability.ReprovisionBucket"
      }
    },
    "protoPayload": {
      "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
      "status": {
        "code": 0,
        "message": "OK"
      },
      ...
      "serviceName": "observability.googleapis.com",
      "methodName": "google.cloud.observability.v1.Observability.ReprovisionBucket",
      "authorizationInfo": [...]
      "resourceName": "projects/PROJECT_ID/locations/us/buckets/_Trace",
      "request": {
        "@type": "type.googleapis.com/google.cloud.observability.v1.ReprovisionBucketRequest",
        "name": "projects/PROJECT_ID/locations/us/buckets/_Trace"
      },
      "response": {
        "@type": "type.googleapis.com/google.longrunning.Operation",
        "name": "projects/PROJECT_ID/locations/us/operations/reprovision-123456789-0",
        "done": false,
        "metadata": {
          "@type": "type.googleapis.com/google.cloud.observability.v1.OperationMetadata",
          "target": "projects/PROJECT_ID/locations/us/buckets/_Trace",
          "verb": "reprovision",
          "apiVersion": "v1"
        }
      }
    },
    "severity": "NOTICE",
    "timestamp": "2026-06-30T16:54:02.123456Z"
  }

Avant de commencer

  1. Consultez les limites.

  2. Pour obtenir les autorisations nécessaires pour reprovisionner un bucket d'observabilité, demandez à votre administrateur de vous accorder le rôle IAM Éditeur d'observabilité (roles/observability.editor) sur le projet qui héberge votre bucket d'observabilité. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

    Le rôle Éditeur d'observabilité fournit des autorisations pour créer et supprimer des buckets d'observabilité, des ensembles de données d'observabilité et des liens sur des ensembles de données. Vous avez besoin de ces autorisations, car l'opération de reprovisionnement émet des commandes de création et de suppression.

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

Reprovisionner un bucket d'observabilité

Pour reprovisionner un bucket d'observabilité, procédez comme suit :

  1. Configurer les paramètres par défaut des buckets d'observabilité
  2. Reprovisionner le bucket
  3. Surveiller la progression
  4. Créer manuellement des liens et mettre à jour les vues d'analyse

Configurer les paramètres par défaut des buckets d'observabilité

Définissez un emplacement de stockage par défaut et, si vous le souhaitez, une clé Cloud KMS par défaut. Vous pouvez les définir au niveau du projet, du dossier ou de l'organisation. Par exemple, si vous configurez des paramètres par défaut pour un dossier, les descendants de ce dossier utilisent ces paramètres, sauf si des paramètres par défaut sont également configurés pour un descendant.

Pour en savoir plus sur l'affichage et la configuration des paramètres par défaut, consultez Définir les paramètres par défaut des buckets d'observabilité.

Reprovisionner le bucket

Utilisez des scripts qui émettent la requête de reprovisionnement de manière asynchrone et interrogez-les pour déterminer quand l'opération de reprovisionnement est terminée. Pour reprovisionner un bucket d'observabilité, utilisez la méthode projects.locations.buckets.reprovision.

Vous devez spécifier le nom du bucket d'observabilité, qui se présente au format suivant :

projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

Les champs de l'expression précédente ont la signification suivante :

La réponse est un objet Operation. Le champ Operation.done fournit des informations sur la progression :

  • done est false : l'opération est en cours. Pour en savoir plus sur l'interrogation de l'opération, consultez Surveiller la progression.

  • done est true : l'opération est terminée et le champ error ou response est défini :

    • response est défini : indique que l'opération asynchrone s'est terminée avec succès. La valeur reflète l'état le plus récent du bucket d'observabilité qui était la cible du reprovisionnement.

    • error est défini : indique que l'opération asynchrone a échoué. La valeur de ce champ est un objet Status qui contient un code d'erreur gRPC et un message d'erreur. Pour en savoir plus sur les messages d'erreur courants, consultez Messages d'erreur.

Le reprovisionnement prend généralement quatre à cinq heures.

Suivre la progression

L'objet Operation contient des informations sur la progression. Interrogez l'opération jusqu'à ce que la valeur du champ Operation.done soit true. Vous pouvez ensuite utiliser les champs Operation.response et Operation.error pour déterminer si le reprovisionnement a réussi ou échoué.

Pour interroger Operation, utilisez la méthode folders.locations.operations.get.

Définissez le paramètre de chemin d'accès sur le nom de l'opération :

operations/UNIQUE_ID

Le champ UNIQUE_ID est l'identifiant unique de l'opération.

La réponse est un objet Operation mis à jour.

Si votre application reçoit une réponse HTTP 503 / UNAVAILABLE lors de l'interrogation, implémentez un intervalle exponentiel entre les tentatives et réessayez d'envoyer la requête. Cette erreur indique que la requête a échoué au niveau de la couche de transport ou de réseau.

Créer manuellement des liens et mettre à jour les vues d'analyse

Une fois l'opération de reprovisionnement terminée, recréez les liens et mettez à jour vos vues d'analyse.

Par exemple, vous pouvez effectuer les opérations suivantes :

  1. Répertoriez les liens de l'ensemble de données d'observabilité. Dans certains cas, l'opération de reprovisionnement conserve les liens. Pour en savoir plus sur cette étape, consultez Lister les liens d'un ensemble de données.

  2. Recréez l'ensemble de données BigQuery associé. Pour en savoir plus sur cette étape, consultez Créer un lien sur un ensemble de données.

  3. Examinez vos vues d'analyse et mettez à jour le chemin d'accès au bucket d'observabilité si nécessaire.

Messages d'erreur

Cette section liste les codes d'erreur courants et, le cas échéant, les actions de récupération.

FAILED_PRECONDITION

Le message d'erreur FAILED_PRECONDITION indique que le bucket d'observabilité n'est pas éligible au reprovisionnement.

Exemple de message d'erreur :

{
    "error":{
        "code": 400,
        "message": "Only _Trace buckets can be reprovisioned.",
        "status": "FAILED_PRECONDITION",
        "details": [ ... ]
    }
}

Vous ne pouvez effectuer aucune action pour rendre le bucket d'observabilité éligible au reprovisionnement.

INVALID_ARGUMENT

Le message d'erreur INVALID_ARGUMENT indique que l'emplacement du bucket d'observabilité et la configuration CMEK sont cohérents avec les paramètres par défaut des buckets d'observabilité.

Pour résoudre ce problème, mettez à jour les paramètres par défaut des buckets d'observabilité pour le projet, le dossier ou l'organisation, puis réessayez de provisionner le bucket d'observabilité.

PERMISSION_DENIED

Le message d'erreur PERMISSION_DENIED indique que vous ne disposez pas des rôles IAM requis pour reprovisionner un bucket d'observabilité.

Pour résoudre ce problème, demandez à un administrateur de vous accorder les rôles IAM listés dans la section Avant de commencer de ce document.

Dépannage

Cette section explique comment résoudre les problèmes courants et répond aux questions qui peuvent se poser après le reprovisionnement d'un bucket d'observabilité.

Comment savoir si un bucket a été reprovisionné ?

Interrogez vos journaux d'audit et filtrez les entrées de journal par nom de journal, service et méthode. Pour en savoir plus, consultez la section Audit de ce document.

Pourquoi mon projet liste-t-il deux buckets pour les données de trace ?

Lors d'un reprovisionnement du bucket d'observabilité _Trace, le système peut avoir besoin de créer un bucket. Lorsque cette option est définie sur "true", votre projet contient deux buckets d'observabilité nommés _Trace pendant l'opération de reprovisionnement.

Aucune action n'est requise de votre part.

Si le système a créé un bucket d'observabilité dans le cadre d'une opération de reprovisionnement, une fois cette opération terminée, le bucket ciblé par l'opération est supprimé. Si l'opération de reprovisionnement échoue, le nouveau bucket est supprimé.

Pourquoi mes données interrogées sont-elles différentes après le reprovisionnement ?

Une opération de reprovisionnement supprime toutes les données stockées avant le lancement de l'opération. Ces données ne sont pas récupérables.

Pourquoi l'explorateur de traces n'affiche-t-il aucune donnée après le reprovisionnement ?

L'explorateur de traces utilise le cache pour améliorer les performances. Le cache est lié au bucket d'observabilité interrogé. Surtout, si ce bucket n'est pas disponible au moment d'une requête, celle-ci échoue.

Lors d'une opération de reprovisionnement, il est possible que votre projet Google Cloud contienne deux buckets d'observabilité nommés _Trace. De plus, une fois cette opération terminée, l'un de ces buckets est supprimé. Dans ce scénario, il est possible que le cache utilisé par l'explorateur de traces soit lié à un bucket qui n'existe plus.

Cette défaillance se corrige d'elle-même après l'expiration du cache, ce qui prend environ 10 minutes.

Pourquoi mon bucket d'observabilité ne peut-il pas être reprovisionné ?

Si une opération de reprovisionnement échoue avec l'état FAILED_PRECONDITION, le bucket d'observabilité ciblé n'est pas éligible au reprovisionnement. Voici quelques raisons pour lesquelles un bucket n'est pas éligible au reprovisionnement :

  • Le bucket d'observabilité n'est pas nommé _Trace.
  • Le bucket d'observabilité a été reprovisionné plus d'une fois. Vous pouvez interroger vos journaux d'audit pour déterminer si le bucket a été reprovisionné.
  • Les paramètres par défaut des buckets d'observabilité sont introuvables. Pour résoudre ce problème, configurez les paramètres par défaut des buckets d'observabilité, puis réessayez d'exécuter la commande.
  • La configuration du bucket d'observabilité est conforme aux paramètres par défaut. Autrement dit, l'opération de reprovisionnement ne modifiera pas la configuration du bucket d'observabilité.
  • Pour respecter les paramètres par défaut, le système devrait remplacer la CMEK par le chiffrement géré par Google. Cette action n'est pas disponible.