Storage Intelligence の問題のトラブルシューティング

このドキュメントでは、Storage IntelligenceStorage Insights インベントリ レポートStorage Insights データセットストレージ バッチ オペレーションに関する一般的な問題のトラブルシューティング方法について説明します。

Storage Intelligence の構成エラー

以降のセクションでは、リソースの Storage Intelligence の構成または管理時に発生する可能性のあるエラーについて説明します。

400: バケット名が無効です

問題: リクエストが 400 Bad Request とメッセージ The specified bucket is not valid. を返す

解決策: リクエストが無効です。リクエストが次の要件を満たしていることを確認します。

  • locations/global を使用してください。Storage Intelligence は他のロケーションをサポートしていません。
  • bucket_id_regexes のバケット名または正規表現が有効であることを確認します。

有効なリクエストの例を次に示します。

curl -X PATCH \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -d '{
      "edition_config": "STANDARD",
      "filter": {
        "included_cloud_storage_buckets": {
          "bucket_id_regexes": [
            "my-bucket-name",
            "prod-data-.*"
          ]
        }
      }
    }' \
    "https://storage.googleapis.com/v2/projects/PROJECT_ID/locations/global/intelligenceConfig?updateMask=edition_config,filter"

400: Invalid argument - empty update mask

問題: 構成リクエストまたは更新リクエストを送信すると、リクエストから 400 Bad Request とメッセージ Empty UPDATE_MASK in the request. が返される

ソリューション: リクエストで空でない UPDATE_MASK を指定します。UPDATE_MASK には、更新する IntelligenceConfig リソース内の FieldMask フィールドのカンマ区切りのリストを指定します(updateMask=edition_configupdateMask=edition_config,filter など)。

400: Invalid update mask path

問題: 構成を更新すると、リクエストはメッセージ Invalid UPDATE_MASK paths. とともに 400 Bad Request を返します。

解決策: UPDATE_MASK の各フィールド名が IntelligenceConfig リソースの有効なフィールドと一致していることを確認します。

400: Field is not editable

問題: 構成を更新すると、リクエストはメッセージ Invalid UPDATE_MASK: UPDATE_TIME field is not editable. とともに 400 Bad Request を返します。

解決策: 編集不可のシステム フィールド(UPDATE_TIME など)を UPDATE_MASK から削除します。IntelligenceConfig で定義された変更可能なフィールドのみを指定します。

400: 無効な値

問題: リクエストが 400 Bad Request とメッセージ Invalid value at storage_intelligence.edition_config. を返す

解決策: edition_config をサポートされている値(INHERITSTANDARDDISABLED)に設定します。

400: Non-empty filter

問題: リクエストが 400 Bad Request とメッセージ Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration. を返す

解決策: リクエストからバケット フィルタを削除します。edition_configINHERIT または DISABLED に設定されている場合、バケット フィルタはサポートされません。

400: Empty location or bucket values in filter

問題: リクエストが 400 Bad Request とメッセージ Empty location or bucket values in filter. を返す

解決策: バケット フィルタlocationbucket のどちらも空の文字列でないことを確認します。

Storage Insights の一般的な問題

このセクションでは、インベントリ レポートデータセットに関する一般的な問題を解決する方法について説明します。

毎日複数のインベントリ レポートが生成される

問題: インベントリ レポートの構成で、毎日複数のレポート ファイルが生成されます。

ソリューション: Cloud Storage は、1,000,000 個を超えるオブジェクトを含むバケットのインベントリ レポートをシャード化し、1,000,000 個のオブジェクトごとに 1 つのシャードを生成します。たとえば、3,500,000 個のオブジェクトを含むバケットでは、4 つのレポート シャードと、各シャードを一覧表示するマニフェスト ファイルが生成されます。

インベントリ レポートが宛先バケットに表示されない

問題: インベントリ レポートが宛先バケットに表示されません。

解決策: レポートが宛先バケットに配信されない場合は、次のことを確認します。

  • 設定した開始日を過ぎていることを確認します。詳細については、インベントリ レポート構成を作成するをご覧ください。

  • インベントリ レポートの履歴を表示して、不具合とその根本原因を確認します。インベントリ レポートの履歴を表示する手順は次のとおりです。

    1. Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。

      [バケット] に移動

    2. バケットのリストで、インベントリ レポートの構成を含むソースバケットの名前をクリックします。

    3. [バケットの詳細] ページで、[インベントリ レポート] タブをクリックします。

    4. インベントリ レポートの構成のリストで、確認するレポートを生成したインベントリ レポート構成の UUID をクリックします。

    5. [インベントリ レポートの履歴] セクションで不具合を確認します。[ヘルプ]()にカーソルを合わせると、不具合が発生した理由の詳細が表示されます。

  • プロジェクト レベルのサービス エージェントに、インベントリ レポートの読み取りと書き込みに必要な IAM ロールが付与されていることを確認します。詳細については、サービス エージェントに必要なロールを付与するをご覧ください。

インベントリ レポートの遅延が発生する

問題: インベントリ レポートの生成が遅延します。

解決策: レポートの生成時間はさまざまです。最大 24 時間の遅延は正常です。

データセットにデータが入力されない

問題: Storage Insights データセット テーブルが空のままになる。

解決策: リンクされた BigQuery データセットで、error_attributes_view のエラーコードを確認します。詳細については、データセット エラーのトラブルシューティングをご覧ください。

データセットのクエリ時に「ref」列に null 値が含まれる

問題: BigQuery で Storage Insights データセットをクエリすると、ref 列から null が返される。

解決策: / で終わるオブジェクトの場合、データセットの ref 列は null です。

BigQuery で Storage Insights データセットをクエリするときに ref 列が null 値を返す場合は、BigQuery を使用してオブジェクト データとメタデータを分析するで説明されているように、Cloud Storage リソースへのアクセスなど、必要な接続権限とロールが付与されていることを確認します。

ストレージ バッチ オペレーション ジョブの検証エラー

このセクションでは、storagebatchoperations.googleapis.comバッチ オペレーション ジョブ リクエストを送信するときに発生する検証エラーについて説明します。

400: 無効なジョブ ID またはリソース名

問題: ジョブ作成リクエストが、理由 JOB_ID_INVALID または RESOURCE_NAME_TOO_LONG400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

解決策: ジョブ ID が 1 ~ 63 個の小文字の英数字またはハイフン([a-z0-9]([-a-z0-9]*[a-z0-9])?)で構成され、ジョブ リソースの完全なパス(projects/PROJECT_ID/locations/LOCATION/jobs/JOB_ID)が 200 バイトを超えていないことを確認します。パスが 200 バイトを超える場合は、ジョブ ID を短縮します。詳細については、ジョブ名をご覧ください。

400: Job description exceeds limit(400: ジョブの説明が上限を超えています)

問題: ジョブ作成リクエストが、理由 DESCRIPTION_TOO_LONG400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

解決策: ジョブの説明が 1,024 バイト以下であることを確認します。この上限を超える場合は、テキストを短くします。詳細については、ジョブの説明をご覧ください。

400: 求人情報のソース構成がないか無効です

問題: ジョブ作成リクエストが、次のいずれかの理由で 400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

  • SOURCE_NOT_SPECIFIED
  • BUCKET_LIST_EMPTY
  • TOO_MANY_BUCKETS
  • MULTI_BUCKET_NOT_SUPPORTED
  • BUCKET_NAME_REQUIRED
  • OBJECT_CONFIGURATION_REQUIRED

解決策: ジョブで有効なソース構成(bucket_list または project_source)が指定され、各バケットでオブジェクト選択メソッドが定義されていることを確認します。詳細については、バッチ オペレーション ジョブの作成と管理をご覧ください。

400: バケット名またはオブジェクト名が無効です

問題: ジョブ作成リクエストが、理由 BUCKET_NAME_INVALID または OBJECT_NAME_INVALID400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

解決策: すべてのバケット名とオブジェクト名が Cloud Storage の命名要件に準拠していることを確認します。詳細については、バケットの命名ガイドラインオブジェクトの命名ガイドラインをご覧ください。

400: プロジェクト ソース構成エラー

問題: ジョブ作成リクエストが、次のいずれかの理由で 400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

  • PROJECT_SOURCE_PROJECT_INVALID
  • PROJECT_SOURCE_DRY_RUN_FIELDS_EXCLUSIVE
  • PROJECT_SOURCE_DRY_RUN_ID_INVALID

解決策: プロジェクト ソース構成が形式とフィールドの排他性の要件を満たしていることを確認します。ドライラン ジョブ ID を指定する場合は、他のすべての project_source パラメータを省略します。詳細については、高度なフィルタを使用してジョブを作成するをご覧ください。

400: 変換パラメータが競合しているか、欠落している

問題: ジョブ作成リクエストが、次のいずれかの理由で 400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

  • TRANSFORMATION_NOT_SPECIFIED
  • REWRITE_OBJECT_MISSING_PARAMETERS
  • PUT_OBJECT_HOLD_MISSING_PARAMETERS
  • PUT_METADATA_MISSING_PARAMETERS

解決策: 必要なすべてのパラメータを使用して、変換タイプを 1 つだけ指定します。オブジェクトの保持を構成する場合は、バケットで Object Lock が有効になっており、タイムスタンプが RFC 3339 UTC 形式を使用していることを確認します。変換ごとのパラメータ要件の詳細については、サービスの種類をご覧ください。

400: オブジェクトの接頭辞が重複している

問題: ジョブ作成リクエストが、理由 OBJECT_PREFIX_OVERLAP または DUPLICATE_OBJECT_PREFIX400 Bad RequestINVALID_ARGUMENT)レスポンスを返します。

解決策: 重複する接頭辞を削除し、included_object_prefixes の接頭辞がリスト内の別のエントリの接頭辞になっていないことを確認します。詳細については、オブジェクト プレフィックスをご覧ください。

400: マニフェスト ファイルの形式とアクセスに関する問題

問題: ジョブ作成リクエストが、理由 MANIFEST_LOCATION_REQUIRED または MANIFEST_LOCATION_INVALID を含む 400 Bad RequestINVALID_ARGUMENT)レスポンスを返すか、ジョブがマニフェストを読み取ることができません。

解決策: マニフェスト URI が有効な CSV パス(gs://<bucket_name>/<path>/<object_name>.csv)であり、ストレージ バッチ オペレーション サービス エージェントにマニフェスト バケットに対する roles/storage.objectViewer ロールが付与されていることを確認します。CSV の形式とスキーマの要件について詳しくは、マニフェストをご覧ください。

400: Storage Insights データセットの検出エラー

問題: オブジェクト検出に Storage Insights データセットを使用すると、次のいずれかの理由で 400 Bad RequestINVALID_ARGUMENT または FAILED_PRECONDITION)レスポンスが返されます。

  • BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD
  • TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME
  • BUCKET_DISCOVERY_TOO_MANY_BUCKETS

解決策: snapshot_time が過去 48 時間以内であることを確認し、バケットに target_locations を指定して、検出クエリが 1,000 個以下のバケットと一致するようにします。詳細については、Storage Insights データセットを使用してマニフェストを作成するをご覧ください。

400: Autoclass が有効なバケットでストレージ クラスの変換が失敗する

問題: ジョブ作成リクエストが、理由 AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED400 Bad RequestFAILED_PRECONDITION)レスポンスを返します。

解決策: Autoclass が有効になっているバケットでストレージ クラスの変換を実行することはできません。Autoclass を使用しないバケットをターゲットにするか、ストレージ クラスの変換を削除します。詳細については、Autoclass の制限事項をご覧ください。

400: 均一なバケットレベルのアクセス バケットでオブジェクト ACL の更新が失敗する

問題: ジョブ作成リクエストが、理由 UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED400 Bad RequestFAILED_PRECONDITION)レスポンスを返します。

解決策: 均一なバケットレベルのアクセスが有効になっているバケットのオブジェクト ACL を更新することはできません。代わりに、バケットまたはプロジェクト レベルで IAM ロールを使用してアクセスを管理します。詳細については、均一なバケットレベルのアクセスをご覧ください。

ストレージ バッチ オペレーションのランタイムと実行に関する問題

このセクションでは、バッチ オペレーション ジョブの非同期実行中に発生する問題について説明します。

403: 実行中の権限エラー

問題: バッチジョブが実行中に 403 ForbiddenPERMISSION_DENIED)で失敗する。

解決策: ストレージ バッチ オペレーション サービス エージェント(service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.iam.gserviceaccount.com)に、変換タイプに必要な IAM ロールを付与します。詳細については、サービス エージェントに権限を付与するをご覧ください。

オブジェクトの書き換え中の CMEK 暗号化エラー

問題: Cloud KMS 鍵のステータスまたは権限エラーにより、オブジェクトの書き換えが 400 Bad Request または 403 Forbidden で失敗します。

解決策: Cloud KMS 鍵が Enabled であり、ターゲット バケットと同じリージョンに存在し、サービス エージェントに roles/cloudkms.cryptoKeyEncrypterDecrypter ロールがあることを確認します。詳細については、サービスの種類: オブジェクトの書き換えをご覧ください。

error_summaries の失敗数が多い

問題: バッチジョブがゼロ以外の counters.failed_object_counterror_summaries のエラーコード(404 NOT_FOUND412 FAILED_PRECONDITION403 PERMISSION_DENIED など)で完了します。

解決策: --location フラグ(gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION など)を指定して gcloud storage batch-operations jobs describe を実行し、集計されたエラーの内訳を表示します。また、Cloud Logging でオブジェクトごとのエラーログを確認します。詳細については、ジョブの詳細を取得するをご覧ください。

2 日以上前のスナップショットが原因でストレージ バッチ オペレーション ジョブが失敗する

問題: CEL フィルタベースのストレージ バッチ オペレーション ジョブを作成すると、ジョブの作成が失敗します。エラー メッセージには、スナップショットの時刻が 2 日以上前であると表示されます。

解決策: 古いオブジェクトの状態に対するアクションを防ぐため、ストレージ バッチ オペレーションではジョブの作成が自動的に失敗します。このエラーは、選択したスナップショットが 2 日以上前のものの場合に発生します。この問題を解決するには、次のいずれかの方法を選択します。

  • マニフェスト ファイルを使用する: BigQuery でデータセットを手動でクエリします。結果を CSV マニフェスト ファイルにエクスポートし、そのファイルを Cloud Storage バケットにアップロードします。その後、マニフェスト メソッドを使用してバッチ オペレーション ジョブを作成すると、2 日間の上限を回避できます。
  • データセットの構成を確認する: データセットの構成が有効で、一時停止されていないことを確認します。データセット スナップショットが正常に実行されていることを確認します。構成を確認する方法については、データセットの構成を表示するをご覧ください。
  • ターゲットのロケーションとスナップショット時刻のオーバーライドを使用する: --target-snapshot-time フラグを指定して、RFC 3339 形式でスナップショットを明示的に選択することで、2 日間の古いデータによる障害を回避します。--target-locations フラグを指定して、オペレーションをスナップショットが存在するロケーションに制限します。これらのオーバーライドを使用して、自動グローバル スナップショットの更新を妨げる同期の遅延を解決できます。そのため、より新しいリージョン スナップショットを手動でターゲットに設定できます。コマンド構文については、詳細フィルタを使用してジョブを作成するをご覧ください。

新しく登録されたプロジェクトで CEL フィルタベースのストレージ バッチ オペレーション ジョブが失敗する

問題: 新しく登録したプロジェクトで CEL フィルタベースのストレージ バッチ オペレーション ジョブを実行すると、システムが有効なスナップショットを見つけられないため、失敗します。

解決策: Storage Intelligence サブスクリプションを有効にした後、CEL フィルタベースのストレージ バッチ オペレーション ジョブを実行するまでに 24 時間待つ必要があります。この遅延により、システムは最初のメタデータ スナップショットを実行し、開始スナップショット時刻を確立できます。

CEL フィルタベースのストレージ バッチ オペレーション ジョブが権限エラーで失敗するか、ランタイム エラーをスローする

問題: CEL フィルタベースのストレージ バッチ オペレーション ジョブが実行中に失敗するか、ランタイム権限エラーを返します。

解決策: ストレージ バッチ オペレーションでは、ユーザー認証情報を使用してオブジェクトを処理します。ターゲットのバケットとオブジェクトに対する必要な IAM 読み取り権限または書き込み権限がない場合、ジョブは失敗します。この問題は、CEL フィルタでアクセス権のないリソースが選択された場合に発生します。アカウントに、ジョブのスコープ内のすべてのバケットとオブジェクトに対するストレージ管理者(roles/storage.admin)、ストレージ オブジェクト管理者(roles/storage.objectAdmin)、または同等のロールがあることを確認します。ロールを付与する手順については、IAM 権限を使用するをご覧ください。

モニタリングとログ分析

Cloud Logging でオブジェクトごとの実行エラーとエラー ペイロードを検査する方法については、ストレージ バッチ オペレーションのログを表示するをご覧ください。

次のステップ