Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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.s3nsapis.fr/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 Inventarberichtskonfiguration generiert täglich mehrere Berichtsdateien.

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

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 Cloud de Confiance 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 in 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 null zurück.

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

Wenn die Spalte ref Nullwerte zurückgibt, wenn Sie Storage Insights Datasets in BigQuery abfragen, prüfen Sie, ob Sie die erforderlichen Berechtigungen und Rollen für die Verbindung 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 Kleinbuchstaben oder Bindestrichen besteht ([a-z0-9]([-a-z0-9]*[a-z0-9])?) und der vollständige Ressourcenpfad 1.024 Byte nicht überschreitet. Weitere Informationen finden Sie unter Jobname.

400: Konfliktierende oder fehlende Transformationsparameter

Problem: Die Anfrage zur Job-Erstellung gibt eine 400 Bad Request (INVALID_ARGUMENT) Antwort mit dem Grund TRANSFORMATION_NOT_SPECIFIED, REWRITE_OBJECT_MISSING_PARAMETERS, PUT_OBJECT_HOLD_MISSING_PARAMETERS oder PUT_METADATA_MISSING_PARAMETERS zurück.

Lösung: Geben Sie genau einen Transformationstyp mit allen erforderlichen Parametern an. Wenn Sie die Objektaufbewahrung konfigurieren, prüfen Sie, ob die Objektsperre für den Bucket aktiviert ist und die 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 der Formatierung und dem 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 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 dem Grund BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD, TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME oder BUCKET_DISCOVERY_TOO_MANY_BUCKETS zurückgegeben.

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: Fehler bei der Transformation der Speicherklasse für Buckets mit aktivierter Autoclass

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 Transformationen der Speicherklasse für Buckets mit aktivierter Autoclass ausführen. Entweder Sie verwenden einen Bucket ohne Autoclass oder entfernen die Transformation der Speicherklasse. Weitere Informationen finden Sie unter Einschränkungen für Autoclass.

400: Fehler bei der Aktualisierung der Objekt-ACLs für Buckets mit einheitlichem Zugriff auf Bucket-Ebene

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 einheitlichen 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.s3ns-system.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 prüfen Sie Cloud Logging auf Fehlermeldungen 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 CEL-Filter-basierten Speicherbatchvorgangsjob erstellen, schlägt die Job-Erstellung fehl. In der Fehlermeldung wird angegeben, dass der Snapshot ä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 die Zwei-Tages-Grenze zu umgehen.
Dataset-Konfigurationen prüfen: Prüfen Sie, ob Ihre Dataset-Konfigurationen aktiv und nicht pausiert sind. 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-Zeit verwenden: Geben Sie das Flag --target-snapshot-time an, um den Fehler aufgrund des Alters des Snapshots 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.

CEL-Filter-basierter Speicherbatchvorgangsjob schlägt bei neu abonnierten Projekten fehl

Problem: Die Ausführung eines CEL-Filter-basierten Speicherbatchvorgangsjobs für ein neu abonniertes Projekt schlägt 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 CEL-Filter-basierte Speicherbatchvorgangsjobs ausführen können. Diese Verzögerung ermöglicht es dem System, den ersten Metadaten-Snapshot zu erstellen und die Startzeit für den Snapshot festzulegen.

CEL-Filter-basierter Speicherbatchvorgangsjob schlägt mit Berechtigungsfehlern fehl oder gibt Laufzeitfehler aus

Problem: Ein CEL-Filter-basierter 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.