Probleme mit Storage Intelligence beheben

In diesem Dokument wird beschrieben, wie Sie häufige Probleme mit Storage Intelligence, Storage Insights-Inventarberichten, Storage Insights-Datasets und Speicherbatchvorgängen beheben.

Konfigurationsfehler bei Storage Intelligence

In den folgenden Abschnitten werden Fehler beschrieben, die bei der Konfiguration oder Verwaltung von Storage Intelligence für eine Ressource auftreten können.

400: Ungültiger Bucket-Name

Problem: Die Anfrage gibt 400 Bad Request mit der Meldung The specified bucket is not valid. zurück.

Lösung: Die Anfrage ist ungültig. Achten Sie darauf, dass die Anfrage die folgenden Anforderungen erfüllt:

  • Verwenden Sie locations/global. Storage Intelligence unterstützt keine anderen Standorte.
  • Achten Sie darauf, dass Bucket-Namen oder reguläre Ausdrücke in bucket_id_regexes gültig sind.

Im Folgenden sehen Sie ein Beispiel für eine gültige Anfrage:

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: Ungültiges Argument – leere Aktualisierungsmaske

Problem: Wenn Sie eine Konfigurations- oder Aktualisierungsanfrage senden, gibt die Anfrage 400 Bad Request mit der Meldung Empty UPDATE_MASK in the request. zurück.

Lösung: Geben Sie in Ihrer Anfrage eine nicht leere UPDATE_MASK an. UPDATE_MASK gibt eine durch Kommas getrennte Liste von FieldMask Feldern in der IntelligenceConfig Ressource an, die aktualisiert werden sollen (z. B. updateMask=edition_config oder updateMask=edition_config,filter).

400: Ungültiger Pfad für Aktualisierungsmaske

Problem: Beim Aktualisieren einer Konfiguration gibt die Anfrage 400 Bad Request mit der Meldung Invalid UPDATE_MASK paths. zurück.

Lösung: Prüfen Sie, ob jeder Feldname in UPDATE_MASK mit einem gültigen Feld in der IntelligenceConfig Ressource übereinstimmt.

400: Feld kann nicht bearbeitet werden

Problem: Beim Aktualisieren einer Konfiguration gibt die Anfrage 400 Bad Request mit der Meldung Invalid UPDATE_MASK: UPDATE_TIME field is not editable. zurück.

Lösung: Entfernen Sie nicht bearbeitbare Systemfelder (z. B. UPDATE_TIME) aus UPDATE_MASK. Geben Sie nur veränderliche Felder an, die in IntelligenceConfig definiert sind.

400: Ungültiger Wert

Problem: Die Anfrage gibt 400 Bad Request mit der Meldung Invalid value at storage_intelligence.edition_config. zurück.

Lösung: Legen Sie für edition_config einen unterstützten Wert fest: INHERIT, STANDARD, oder DISABLED.

400: Nicht leerer Filter

Problem: Die Anfrage gibt 400 Bad Request mit der Meldung Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration. zurück.

Lösung: Entfernen Sie Bucket-Filter aus der Anfrage. Bucket-Filter werden nicht unterstützt, wenn edition_config auf INHERIT oder DISABLED gesetzt ist.

400: Leere Standort- oder Bucket-Werte im Filter

Problem: Die Anfrage gibt 400 Bad Request mit der Meldung Empty location or bucket values in filter. zurück.

Lösung: Achten Sie darauf, dass weder location noch bucket im Bucket-Filter eine leere String ist.

Häufige Probleme mit Storage Insights

In diesem Abschnitt wird beschrieben, wie Sie häufige Probleme mit Inventarberichten und Datasets beheben.

Täglich werden mehrere Inventarberichte generiert

Problem: Eine Konfiguration für Inventarberichte generiert täglich mehrere Berichtsdateien.

Lösung: Cloud Storage teilt Inventarberichte für Buckets mit mehr als 1.000.000 Objekten in Shards auf und generiert einen Shard pro 1.000.000 Objekte. Beispiel: Für einen Bucket mit 3.500.000 Objekten werden vier Bericht-Shards und eine Manifestdatei generiert, in der jeder Shard aufgeführt ist.

Im Ziel-Bucket nicht angezeigte Inventarberichte

Problem: Inventarberichte werden im Ziel-Bucket nicht angezeigt.

Lösung: Wenn Berichte nicht an den Ziel-Bucket gesendet werden, prüfen Sie Folgendes:

  • Achten Sie darauf, dass das konfigurierte Startdatum überschritten wurde. Weitere Informationen finden Sie unter Inventarberichtskonfiguration erstellen.

  • Prüfen Sie den Verlauf der Inventarberichte, um nach Fehlern und deren Ursachen zu suchen. Führen Sie die folgenden Schritte aus, um den Verlauf Ihrer Inventarberichte aufzurufen:

    1. Wechseln Sie in der Google Cloud Console unter „Cloud Storage“ zur Seite Buckets.

      Buckets aufrufen

    2. Klicken Sie in der Liste der Buckets auf den Namen des Quell-Buckets, der die Inventarberichtskonfiguration enthält.

    3. Klicken Sie auf der Seite Bucket-Details auf den Tab Inventarberichte.

    4. Klicken Sie in der Liste der Inventarberichtskonfigurationen auf die UUID der Inventarberichtskonfiguration, über die die Berichte generiert wurden, die Sie prüfen möchten.

    5. Sehen Sie im Bereich Verlauf der Inventarberichte nach, ob Fehler vorliegen. Sie können den Mauszeiger über Hilfe () halten, um Details darüber zu erhalten, warum ein Fehler aufgetreten ist.

  • Prüfen Sie, ob dem Dienst-Agent auf Projektebene die IAM-Rollen zugewiesen sind, die zum Lesen und Schreiben von Inventarberichten erforderlich sind. Weitere Informationen finden Sie unter Erforderliche Rollen für den Dienst-Agent zuweisen.

Verzögerungen bei Inventarberichten

Problem: Die Generierung von Inventarberichten ist verzögert.

Lösung: Die Generierungszeiten für Berichte variieren. Verzögerungen von bis zu 24 Stunden sind normal.

Datasets werden nicht gefüllt

Problem: Die Tabellen von Storage Insights-Datasets bleiben leer.

Lösung: Suchen Sie in Ihrem verknüpften BigQuery-Dataset in error_attributes_view nach Fehlercodes. Weitere Informationen finden Sie unter Fehler bei Datasets beheben.

Nullwerte in der Spalte „ref“ beim Abfragen von Datasets

Problem: Beim Abfragen von Storage Insights-Datasets in BigQuery gibt die ref Spalte den Wert null zurück.

Lösung: Für Objekte, die mit / enden, ist die Spalte ref in Datasets null.

Wenn die Spalte ref beim Abfragen von Storage Insights Datasets in BigQuery Nullwerte zurückgibt, prüfen Sie, ob Sie die erforderlichen Verbindungsberechtigungen und -rollen gewährt haben, einschließlich des Zugriffs auf Cloud Storage Ressourcen, wie unter Objektdaten und -metadaten mit BigQuery analysieren beschrieben.

Validierungsfehler bei Speicherbatchvorgängen

In diesem Abschnitt werden Validierungsfehler beschrieben, die beim Senden einer Batch vorgangsjob-Anfrage an storagebatchoperations.googleapis.com auftreten.

400: Ungültige Job-ID oder ungültiger Ressourcenname

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit dem Grund JOB_ID_INVALID oder RESOURCE_NAME_TOO_LONG zurück.

Lösung: Prüfen Sie, ob die Job-ID aus 1 bis 63 alphanumerischen Zeichen in Kleinbuchstaben oder Bindestrichen besteht ([a-z0-9]([-a-z0-9]*[a-z0-9])?) und ob der vollständige Ressourcenpfad des Jobs (projects/PROJECT_ID/locations/LOCATION/jobs/JOB_ID) 200 Byte nicht überschreitet. Wenn der Pfad 200 Byte überschreitet, kürzen Sie die Job-ID. Weitere Informationen finden Sie unter Jobname.

400: Jobbeschreibung überschreitet das Limit

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit dem Grund DESCRIPTION_TOO_LONG zurück.

Lösung: Die Jobbeschreibung darf maximal 1.024 Byte lang sein. Wenn sie dieses Limit überschreitet, kürzen Sie den Text. Weitere Informationen finden Sie unter Jobbeschreibung.

400: Fehlende oder ungültige Job-Quellkonfigurationen

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit einem der folgenden Gründe zurück:

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

Lösung: Achten Sie darauf, dass für Ihren Job eine gültige Quellkonfiguration (bucket_list oder project_source) angegeben ist und dass für jeden Bucket eine Methode zur Objektauswahl definiert ist. Weitere Informationen finden Sie unter Jobs für Batchvorgänge erstellen und verwalten.

400: Ungültiger Bucket- oder Objektname

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit dem Grund BUCKET_NAME_INVALID oder OBJECT_NAME_INVALID zurück.

Lösung: Achten Sie darauf, dass alle Bucket- und Objektnamen den Benennungsanforderungen von Cloud Storage entsprechen. Weitere Informationen finden Sie in den Benennungs richtlinien für Buckets und den Benennungsrichtlinien für Objekte.

400: Fehler bei der Konfiguration der Projektquelle

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit einem der folgenden Gründe zurück:

  • PROJECT_SOURCE_PROJECT_INVALID
  • PROJECT_SOURCE_DRY_RUN_FIELDS_EXCLUSIVE
  • PROJECT_SOURCE_DRY_RUN_ID_INVALID

Lösung: Prüfen Sie, ob Ihre Konfiguration der Projektquelle die Formatierungs- und Feldexklusivitätsanforderungen erfüllt. Wenn Sie eine Job-ID für einen Testlauf angeben, lassen Sie alle anderen project_source-Parameter weg. Weitere Informationen finden Sie unter Job mit erweiterten Filtern erstellen.

400: Konfliktierende oder fehlende Transformationsparameter

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit einem der folgenden Gründe zurück:

  • TRANSFORMATION_NOT_SPECIFIED
  • REWRITE_OBJECT_MISSING_PARAMETERS
  • PUT_OBJECT_HOLD_MISSING_PARAMETERS
  • PUT_METADATA_MISSING_PARAMETERS

Lösung: Geben Sie genau einen Transformationstyp mit allen erforderlichen Parametern an. Wenn Sie die Objektaufbewahrung konfigurieren, prüfen Sie, ob Object Lock für den Bucket aktiviert ist und ob Zeitstempel das RFC 3339-UTC-Format verwenden. Weitere Informationen zu den Parameteranforderungen nach Transformation finden Sie unter Jobtyp.

400: Überlappende oder doppelte Objektpräfixe

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit dem Grund OBJECT_PREFIX_OVERLAP oder DUPLICATE_OBJECT_PREFIX zurück.

Lösung: Entfernen Sie doppelte Präfixe und achten Sie darauf, dass kein Präfix in included_object_prefixes ein Präfix eines anderen Eintrags in der Liste ist. Weitere Informationen finden Sie unter Objektpräfixe.

400: Probleme mit Formatierung und Zugriff auf Manifestdateien

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT)-Antwort mit dem Grund MANIFEST_LOCATION_REQUIRED oder MANIFEST_LOCATION_INVALID zurück oder der Job kann das Manifest nicht lesen.

Lösung: Prüfen Sie, ob der Manifest-URI ein gültiger CSV-Pfad ist (gs://<bucket_name>/<path>/<object_name>.csv) und ob der Dienst-Agent für Speicherbatchvorgänge die roles/storage.objectViewer Rolle für den Manifest-Bucket hat. Weitere Informationen zu CSV-Formatierungs- und Schemaanforderungen finden Sie unter Manifest.

400: Fehler bei der Ermittlung von Storage Insights-Datasets

Problem: Wenn Sie ein Storage Insights-Dataset für die Objektermittlung verwenden, wird eine 400 Bad Request (INVALID_ARGUMENT oder FAILED_PRECONDITION)-Antwort mit einem der folgenden Gründe zurückgegeben:

  • BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD
  • TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME
  • BUCKET_DISCOVERY_TOO_MANY_BUCKETS

Lösung: Prüfen Sie, ob snapshot_time innerhalb der letzten 48 Stunden liegt, geben Sie target_locations für die Buckets an und achten Sie darauf,dass die Ermittlungsabfrage nicht mehr als 1.000 Buckets entspricht. Weitere Informationen finden Sie unter Manifest mit Storage Insights-Datasets erstellen.

400: Speicherklassenumstellung schlägt bei Buckets mit aktivierter Autoclass fehl

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (FAILED_PRECONDITION)-Antwort mit dem Grund AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED zurück.

Lösung: Sie können keine Speicherklassenumstellungen für Buckets mit aktivierter Autoclass ausführen. Entweder Sie verwenden einen Bucket ohne Autoclass oder entfernen die Speicherklassenumstellung. Weitere Informationen finden Sie unter Einschränkungen für Autoclass.

400: Objekt-ACL-Aktualisierungen schlagen bei Buckets mit einheitlichem Zugriff auf Bucket-Ebene fehl

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (FAILED_PRECONDITION)-Antwort mit dem Grund UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED zurück.

Lösung: Sie können Objekt-ACLs für Buckets mit aktiviertem einheitlichem Zugriff auf Bucket-Ebene nicht aktualisieren. Verwalten Sie den Zugriff stattdessen mit IAM-Rollen auf Bucket- oder Projektebene. Weitere Informationen finden Sie unter Einheitlicher Zugriff auf Bucket-Ebene.

Laufzeit- und Ausführungsprobleme bei Speicherbatchvorgängen

In diesem Abschnitt werden Probleme beschrieben, die bei der asynchronen Ausführung eines Batchvorgangsjobs auftreten.

403: Berechtigungsfehler während der Ausführung

Problem: Ein Batchjob schlägt während der Ausführung mit 403 Forbidden (PERMISSION_DENIED) fehl.

Lösung: Weisen Sie dem Dienst-Agent für Speicherbatchvorgänge (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.iam.gserviceaccount.com) die erforderlichen IAM-Rollen für Ihren Transformationstyp zu. Weitere Informationen finden Sie unter Berechtigungen für den Dienst-Agent gewähren.

CMEK-Verschlüsselungsfehler beim Umschreiben von Objekten

Problem: Das Umschreiben von Objekten schlägt mit 400 Bad Request oder 403 Forbidden aufgrund des Cloud KMS-Schlüsselstatus oder von Berechtigungsfehlern fehl.

Lösung: Prüfen Sie, ob der Cloud KMS-Schlüssel Enabled ist und sich in derselben Region wie der Ziel-Bucket befindet und ob der Dienst-Agent die roles/cloudkms.cryptoKeyEncrypterDecrypter Rolle hat. Weitere Informationen finden Sie unter Art der Dienstleistung: Objekt umschreiben.

Hohe Anzahl von Fehlern in „error_summaries“

Problem: Ein Batchjob wird mit einem Wert ungleich null für counters.failed_object_count und Fehlercodes in error_summaries abgeschlossen (z. B. 404 NOT_FOUND, 412 FAILED_PRECONDITION, oder 403 PERMISSION_DENIED).

Lösung: Führen Sie gcloud storage batch-operations jobs describe mit dem --location Flag aus (z. B. gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION), um die aggregierte Fehleraufschlüsselung aufzurufen, und suchen Sie in Cloud Logging nach Fehlerlogs pro Objekt. Weitere Informationen finden Sie unter Jobdetails abrufen.

Speicherbatchvorgangsjob schlägt aufgrund eines mehr als zwei Tage alten Snapshots fehl

Problem: Wenn Sie einen auf CEL-Filtern basierenden Speicherbatchvorgangsjob erstellen, schlägt die Job-Erstellung fehl. In der Fehlermeldung wird angegeben, dass der Snapshot-Zeitpunkt älter als zwei Tage ist.

Lösung: Um Aktionen für veraltete Objektzustände zu verhindern, schlägt die Job-Erstellung für Speicherbatchvorgänge automatisch fehl. Dieser Fehler tritt auf, wenn der ausgewählte Snapshot älter als zwei Tage ist. Wählen Sie eine der folgenden Methoden, um dieses Problem zu beheben:

  • Manifestdatei verwenden: Fragen Sie Ihr Dataset manuell in BigQuery ab. Exportieren Sie die Ergebnisse in eine CSV-Manifestdatei und laden Sie die Datei in einen Cloud Storage-Bucket hoch. Anschließend können Sie den Batchvorgangsjob mit der Manifestmethode erstellen, um das Limit von zwei Tagen zu umgehen.
  • Dataset-Konfigurationen prüfen: Prüfen Sie, ob Ihre Dataset-Konfigurationen aktiv sind und nicht pausiert wurden. Prüfen Sie, ob Dataset-Snapshots erfolgreich ausgeführt werden. Informationen zum Prüfen Ihrer Konfigurationen finden Sie unter Dataset-Konfiguration ansehen.
  • Überschreibungen für Zielstandort und Snapshot-Zeitpunkt verwenden: Geben Sie das --target-snapshot-time Flag an, um den Fehler aufgrund des Alters von mehr als zwei Tagen zu umgehen, indem Sie explizit einen Snapshot im RFC 3339-Format auswählen. Geben Sie das Flag --target-locations an, um den Vorgang auf die Standorte zu beschränken, an denen der Snapshot vorhanden ist. Mit diesen Überschreibungen können Sie Synchronisierungsverzögerungen beheben, die verhindern, dass der automatische globale Snapshot aktualisiert wird. So können Sie manuell einen neueren regionalen Snapshot auswählen. Informationen zur Befehlssyntax finden Sie unter Job mit erweiterten Filtern erstellen.

Auf CEL-Filtern basierender Speicherbatchvorgangsjob schlägt bei neu abonnierten Projekten fehl

Problem: Wenn Sie einen auf CEL-Filtern basierenden Speicherbatchvorgangsjob für ein neu abonniertes Projekt ausführen, schlägt der Job fehl, weil das System keinen gültigen Snapshot finden kann.

Lösung: Nachdem Sie das Storage Intelligence-Abo aktiviert haben, müssen Sie 24 Stunden warten, bevor Sie auf CEL-Filtern basierende Speicherbatchvorgangsjobs ausführen können. Diese Verzögerung ermöglicht es dem System, den ersten Metadaten-Snapshot zu erstellen und den Startzeitpunkt für den Snapshot festzulegen.

Auf CEL-Filtern basierender Speicherbatchvorgangsjob schlägt mit Berechtigungsfehlern fehl oder gibt Laufzeitfehler aus

Problem: Ein auf CEL-Filtern basierender Speicherbatchvorgangsjob schlägt während der Ausführung fehl oder gibt Berechtigungsfehler zur Laufzeit zurück.

Lösung: Bei Speicherbatchvorgängen werden Ihre Nutzeranmeldedaten verwendet, um Objekte zu verarbeiten. Der Job schlägt fehl, wenn Sie nicht die erforderlichen IAM-Leser- oder Schreibberechtigungen für die Ziel-Buckets und -Objekte haben. Dieses Problem tritt auf, wenn Ihre CEL-Filter Ressourcen auswählen, auf die Sie keinen Zugriff haben. Prüfen Sie, ob Ihr Konto die Rolle „Storage-Administrator“ (roles/storage.admin), „Storage-Objekt-Administrator“ (roles/storage.objectAdmin) oder eine entsprechende Rolle für alle Buckets und Objekte im Umfang des Jobs hat. Eine Anleitung zum Zuweisen von Rollen finden Sie unter IAM-Berechtigungen verwenden.

Monitoring und Loganalyse

Weitere Informationen zum Untersuchen von Ausführungsfehlern und Fehler Nutzlasten pro Objekt in Cloud Logging finden Sie unter Logs für Speicherbatchvorgänge ansehen.

Nächste Schritte