Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

データ所在地と CMEK の要件を修正する

オブザーバビリティバケットを再プロビジョニングして、データ所在地と暗号化の規制要件を満たすことができます。再プロビジョニング後、_Trace バケットのストレージロケーションと暗号化構成は、オブザーバビリティバケットのデフォルト設定と一致します。

バケットを再プロビジョニングするには、デフォルト設定を構成してから、再プロビジョニングメソッドを呼び出します。再プロビジョニングオペレーションでは、次のいずれかを行うことができます。

ストレージロケーションを変更せずに、Cloud Key Management Service 鍵をオブザーバビリティバケットに遡及的に適用します。
オブザーバビリティバケットのストレージロケーションを変更し、Google のデフォルトの暗号化を使用します。
オブザーバビリティバケットの保存場所を変更し、Cloud KMS 鍵を使用して保存データを暗号化します。

オブザーバビリティバケットの表示名、説明、Cloud KMS 鍵を変更する場合は、オブザーバビリティバケットを再プロビジョニングしないでください。このような場合は、オブザーバビリティバケットを更新します。

再プロビジョニングの仕組み

再プロビジョニングオペレーションを開始すると、システムは次の手順を実行します。

システムは、オブザーバビリティバケットが再プロビジョニングの対象かどうかを判断します。オブザーバビリティバケットは、次のすべてのチェックに合格すると対象となります。
- オブザーバビリティバケットの名前は _Trace です。
- バケットが再プロビジョニングされていない。
- オブザーバビリティバケットのデフォルト設定が見つかりました。
- デフォルト設定に合わせるには、オブザーバビリティバケットのロケーションを変更するか、暗号化を Google のデフォルトの暗号化から CMEK に変更する必要があります。
システムがバケット構成を更新します。このプロセスには 4 ～ 5 時間かかります。

制限事項

次の制限が適用されます。

システムでは、オブザーバビリティバケットごとに最大 1 つの再プロビジョニングオペレーションが許可されます。後続のリクエストは FAILED_PRECONDITION エラーで失敗します。
再プロビジョニングできるのは、_Trace という名前のバケットのみです。
再プロビジョニングが開始される前に保存されたデータにはアクセスできません。このデータは削除されており、復元できません。
バケットのロケーションが変更されると、リンクとリンクされた BigQuery データセットが削除されます。リンクを再作成する必要があります。
バケットのロケーションが変更された場合は、既存のアナリティクスビューを手動で更新する必要があります。
再プロビジョニングオペレーションをキャンセルしたり、元に戻したりすることはできません。オペレーションをキャンセルしようとしても無視されます。
再プロビジョニングオペレーション中のクエリの動作は定義されていません。

注: 再プロビジョニングオペレーション中に Trace Explorer ページまたはオブザーバビリティ分析ページを使用することはおすすめしません。オペレーションが完了するまで使用を延期します。

監査

オブザーバビリティバケットの再プロビジョニング履歴を確認するには、監査ログを使用します。管理アクティビティログには、再プロビジョニングリクエストを行ったユーザー、影響を受けるオブザーバビリティバケット、初期レスポンスが記録されます。

これらのレコードを見つけるには、ログエクスプローラで次のフィルタを適用します。

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"

次の部分的な例は、管理アクティビティ監査ログを示しています。

  {
    "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"
  }

始める前に

制限事項を確認します。
オブザーバビリティバケットを再プロビジョニングするために必要な権限を取得するには、オブザーバビリティバケットをホストするプロジェクトに対するオブザーバビリティ編集者（roles/observability.editor）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

オブザーバビリティ編集者のロールには、オブザーバビリティバケット、オブザーバビリティデータセット、データセットのリンクを作成および削除する権限が付与されます。再プロビジョニングオペレーションでは作成コマンドと削除コマンドの両方が発行されるため、これらの権限が必要です。

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

オブザーバビリティバケットを再プロビジョニングする

オブザーバビリティバケットを再プロビジョニングする手順は次のとおりです。

オブザーバビリティバケットのデフォルト設定を構成する
バケットを再プロビジョニングする
進捗状況をモニタリングする
リンクを手動で作成してアナリティクスビューを更新する

オブザーバビリティバケットのデフォルト設定を構成する

デフォルトのストレージロケーションを設定し、必要に応じてデフォルトの Cloud KMS 鍵を設定します。これらは、プロジェクト、フォルダ、または組織レベルで設定できます。たとえば、フォルダのデフォルト設定を構成すると、そのフォルダの子孫は、子孫にもデフォルト設定が構成されていない限り、それらの設定を使用します。

デフォルト設定を表示して構成する方法については、オブザーバビリティバケットのデフォルトを設定するをご覧ください。

バケットを再プロビジョニングする

再プロビジョニングリクエストを非同期で発行し、ポーリングして再プロビジョニングオペレーションの完了を判断するスクリプトを使用します。オブザーバビリティバケットを再プロビジョニングするには、projects.locations.buckets.reprovision メソッドを使用します。

オブザーバビリティバケットの名前を指定する必要があります。形式は次のとおりです。

projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

上記の式のフィールドの意味は次のとおりです。

PROJECT_ID: プロジェクトの ID。
LOCATION: オブザーバビリティバケットのロケーション。
BUCKET_ID: オブザーバビリティバケットの ID。この ID は _Trace にする必要があります。

レスポンスは Operation オブジェクトです。Operation.done フィールドには、進行状況に関する情報が格納されます。

done が false: オペレーションが進行中です。オペレーションのポーリングについては、進行状況をモニタリングするをご覧ください。
done が true の場合、オペレーションは完了し、error フィールドまたは response フィールドが設定されます。
- response が設定されている: 非同期オペレーションが正常に完了したことを示します。この値は、再プロビジョニングのターゲットであったオブザーバビリティバケットの最新の状態を反映しています。
- error が設定されている: 非同期オペレーションが失敗したことを示します。このフィールドの値は、gRPC エラーコードとエラーメッセージを含む Status オブジェクトです。一般的なエラーメッセージについては、エラーメッセージをご覧ください。

再プロビジョニングが完了するまでに通常 4 ～ 5 時間かかります。

進捗の確認

Operation オブジェクトには、進行状況に関する情報が含まれます。Operation.done フィールドの値が true になるまで、オペレーションをポーリングします。その後、Operation.response フィールドと Operation.error フィールドを使用して、再プロビジョニングが成功したか失敗したかを判断できます。

Operation をポーリングするには、folders.locations.operations.get メソッドを使用します。

パスパラメータをオペレーションの名前に設定します。

operations/UNIQUE_ID

UNIQUE_ID フィールドは、オペレーションの固有識別子です。

レスポンスは、更新された Operation オブジェクトです。

ポーリング時にアプリケーションが HTTP 503 / UNAVAILABLE レスポンスを受け取った場合は、指数バックオフを実装してリクエストを再試行します。このエラーは、トランスポート層またはネットワーク層でリクエストが失敗したことを示します。

リンクを手動で作成してアナリティクスビューを更新する

再プロビジョニングオペレーションが完了したら、リンクを再作成してアナリティクスビューを更新します。

たとえば、次のことを行います。

オブザーバビリティデータセットのリンクを一覧表示します。シナリオによっては、再プロビジョニングオペレーションでリンクが保持されます。この手順については、データセットのリンクを一覧表示するをご覧ください。
リンクされた BigQuery データセットを再作成します。この手順については、データセットにリンクを作成するをご覧ください。
アナリティクスビューを確認し、必要に応じてオブザーバビリティバケットへのパスを更新します。

エラーメッセージ

このセクションでは、一般的なエラーコードと、該当する場合は復旧アクションについて説明します。

FAILED_PRECONDITION

FAILED_PRECONDITION エラーメッセージは、オブザーバビリティバケットが再プロビジョニングの対象ではないことを示します。

エラーメッセージの例:

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

オブザーバビリティバケットを再プロビジョニングの対象にするために実行できる操作はありません。

INVALID_ARGUMENT

INVALID_ARGUMENT エラーメッセージは、オブザーバビリティバケットのロケーションと CMEK 構成が、オブザーバビリティバケットのデフォルト設定と一致していることを示しています。

このエラーを解決するには、プロジェクト、フォルダ、または組織のオブザーバビリティバケットのデフォルト設定を更新してから、オブザーバビリティバケットの再プロビジョニングを再試行します。

PERMISSION_DENIED

PERMISSION_DENIED エラーメッセージは、オブザーバビリティバケットを再プロビジョニングするために必要な IAM ロールがないことを示しています。

このエラーを解決するには、このドキュメントの始める前にセクションに記載されている IAM ロールを付与するよう管理者に依頼してください。

トラブルシューティング

このセクションでは、一般的な問題を解決する方法と、オブザーバビリティバケットの再プロビジョニング後に発生する可能性のある質問への回答について説明します。

バケットが再プロビジョニングされたかどうかを確認するにはどうすればよいですか？

監査ログをクエリし、ログ名、サービス、メソッドでログエントリをフィルタします。詳細については、このドキュメントの監査をご覧ください。

プロジェクトにトレースデータ用のバケットが 2 つ表示されるのはなぜですか？

_Trace オブザーバビリティバケットの再プロビジョニング中に、システムが新しいバケットを作成する必要がある場合があります。これが true の場合、再プロビジョニングオペレーション中に、プロジェクトに _Trace という名前の 2 つのオブザーバビリティバケットが含まれます。

プロジェクト内のオブザーバビリティバケットを一覧表示すると、両方のバケットが結果に表示されます。
オブザーバビリティ分析を使用してトレースデータをクエリすると、両方のバケットで _AllSpans ビューを使用できます。

お客様側でのご対応は必要ありません。

システムが再プロビジョニングオペレーションの一環としてオブザーバビリティバケットを作成した場合、そのオペレーションが正常に完了すると、オペレーションの対象となったバケットは削除されます。再プロビジョニングオペレーションが失敗すると、新しいバケットは削除されます。

再プロビジョニング後にクエリされたデータが異なるのはなぜですか？

再プロビジョニングオペレーションでは、オペレーションの開始前に保存されたすべてのデータが削除されます。このデータは復元できません。

再プロビジョニング後に Trace エクスプローラにデータが表示されないのはなぜですか？

Trace Explorer は、パフォーマンスを向上させるためにキャッシュを使用します。キャッシュは、クエリ対象のオブザーバビリティバケットに関連付けられます。重要なのは、クエリ時にそのバケットが使用できない場合、クエリが失敗することです。

再プロビジョニングオペレーション中に、 Google Cloud プロジェクトに _Trace という名前の 2 つのオブザーバビリティバケットが含まれる場合があります。さらに、そのオペレーションが完了すると、それらのバケットの 1 つが削除されます。このシナリオでは、Trace Explorer が使用するキャッシュが、存在しないバケットに関連付けられる可能性があります。

このエラーは、キャッシュがタイムアウトすると自動的に修正されます。これには約 10 分かかります。

オブザーバビリティバケットを再プロビジョニングできないのはなぜですか？

再プロビジョニングオペレーションが FAILED_PRECONDITION ステータスで失敗した場合、ターゲットのオブザーバビリティバケットは再プロビジョニングの対象外です。バケットが再プロビジョニングの対象外となる理由には、次のようなものがあります。

オブザーバビリティバケットの名前が _Trace ではない。
オブザーバビリティバケットが再プロビジョニングされた回数が 1 回を超えています。監査ログをクエリして、バケットが再プロビジョニングされたかどうかを確認できます。
オブザーバビリティバケットのデフォルト設定が見つかりません。このエラーを解決するには、オブザーバビリティバケットのデフォルト設定を構成してから、コマンドを再試行します。
オブザーバビリティバケットの構成は、デフォルトの設定と一致しています。つまり、再プロビジョニングオペレーションによって、オブザーバビリティバケットの構成が変更されることはありません。
デフォルト設定に準拠するには、システムで CMEK を Google 管理の暗号化に置き換える必要があります。この操作はサポートされていません。