Probleme mit Storage Intelligence beheben

In diesem Dokument wird beschrieben, wie Sie häufige Probleme mit Storage Intelligence, Storage Insights-Inventarberichten, Storage Insights-Datasets, Objektkontext-Anreicherungen (Vorschau) und Storage-Batchvorgängen beheben.

Storage Intelligence-Konfigurationsfehler

In den folgenden Abschnitten werden Fehler beschrieben, die beim Konfigurieren oder Verwalten 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. Die Anfrage muss die folgenden Anforderungen erfüllen:

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

Hier 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 einen nicht leeren 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 Ressource IntelligenceConfig ü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 änderbare 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: Setzen Sie edition_config auf einen unterstützten Wert: 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 festgelegt 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 ein leerer String in Ihrem Bucket-Filter ist.

Häufige Probleme mit Storage Insights

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

Täglich 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 und generiert einen Shard pro 1.000.000 Objekte. Beispiel: Ein Bucket mit 3.500.000 Objekten generiert vier Berichts-Shards und eine Manifestdatei, 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:

  • Das konfigurierte Startdatum muss in der Vergangenheit liegen. Weitere Informationen finden Sie unter Konfiguration für Inventarberichte 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 Erstellung des Inventarberichts verzögert sich.

Lösung: Die Zeiten für die Berichterstellung variieren. Verzögerungen von bis zu 24 Stunden sind normal.

Datasets werden nicht gefüllt

Problem: Storage Insights-Dataset-Tabellen bleiben leer.

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

Nullwerte in der Spalte „ref“ beim Abfragen von Datasets

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

Lösung: Bei Objekten, die auf / 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 Verbindungsberechtigungen und Rollen gewährt haben, einschließlich des Zugriffs auf Cloud Storage-Ressourcen, wie unter Objektdaten und Metadaten mit BigQuery analysieren beschrieben.

Fehler bei der Objektkontext-Anreicherung

In diesem Abschnitt wird beschrieben, wie Sie häufige Probleme beim Konfigurieren, Generieren oder Abfragen von Objektkontext-Anreicherungen beheben.

Für Objekte fehlen Anreicherungen

Problem: Objektkontext-Anreicherungen werden nach der Konfiguration nicht für Objekte angezeigt.

Lösung: Prüfen Sie Folgendes:

  • Dienst-Agent-Berechtigungen: Weisen Sie dem Dienst-Agenten für Objektkontext-Anreicherung die Rolle roles/storage.annotationGeneratorService für den Ziel-Bucket (oder das Zielprojekt) und die Rolle roles/storage.bucketViewer für das Projekt zu. Eine Anleitung finden Sie unter Berechtigungen für den Dienst-Agent gewähren.
  • Filter- und Bereichskonfiguration: Achten Sie darauf, dass die Ressource FeatureConfig den Namen des Ziel-Buckets explizit enthält. Cloud Storage schließt Buckets, die nach dem Erstellen der FeatureConfig-Ressource erstellt wurden, nicht automatisch ein. Wenn Sie einen Bucket löschen und neu erstellen oder verschieben, müssen Sie die FeatureConfig-Ressource aktualisieren, um ihn wieder einzuschließen.
  • Modellvoraussetzungen und Content-Type-Metadaten: Prüfen Sie, ob die Objekte die Limits für Inhaltstyp und Größe für Ihre aktivierten Modelle erfüllen. Cloud Storage verwendet das Metadatenfeld Content-Type des Objekts, um die Eignung zu bestimmen (BMP, GIF, ICO, JPEG, PNG, TIFF oder WEBP für Bilder; application/pdf für die PDF-Klassifizierung). Wenn die Content-Type-Metadaten fehlen oder falsch sind, verarbeitet Cloud Storage das Objekt erst, wenn Sie die Metadaten aktualisieren. Außerdem werden Objekte, die größer als 20 MiB sind, vom Dienst für Objektkontext-Anreicherung übersprungen. Weitere Informationen finden Sie unter Unterstützte Modelle und Schemas.
  • Verarbeitungslatenz: Planen Sie ausreichend Zeit für die asynchrone Verarbeitung ein. Der Dienst für Objektkontext-Anreicherung verarbeitet Objekte asynchron. Anreicherungen für neu hochgeladene Objekte werden in der Regel innerhalb weniger Stunden angezeigt. Das Backfilling vorhandener Objekte in großen Buckets kann dagegen Stunden oder Tage dauern.

Objektkontext-Anreicherungen sind in BigQuery nicht sichtbar

Problem: Objektkontext-Anreicherungen werden in der API, aber nicht in BigQuery angezeigt.

Lösung: Prüfen Sie Folgendes:

  • Konfiguration von Storage Insights-Datasets: Prüfen Sie, ob Sie Storage Insights-Datasets für den Bucket konfiguriert haben.
  • Täglicher Berichtszeitplan: Warten Sie auf die tägliche Aktualisierung des Datasets. Storage Insights-Datasets werden alle 24 Stunden aktualisiert. Daher kann es bis zu 24 Stunden dauern, bis neu generierte Anreicherungen in der Ansicht object_contexts_catalog_view in BigQuery angezeigt werden.
  • IAM-Berechtigungen: Sie benötigen Berechtigungen zum Ausführen von Jobs und zum Lesen von Daten in BigQuery (z. B. roles/bigquery.jobUser und roles/bigquery.dataViewer). Eine Anleitung zum Abfragen finden Sie unter Objektkontext-Anreicherungen in BigQuery analysieren.

Berechtigung beim Abrufen erweiterter Daten zur Objektkontext-Anreicherung verweigert

Problem: Beim Abrufen von Daten zur erweiterten Objektkontext-Anreicherung tritt ein Berechtigungsfehler auf.

Lösung: Sie benötigen die Berechtigung storage.objects.viewFullContext für das Objekt oder den Bucket, um erweiterte Daten wie Begrenzungsrahmenkoordinaten oder Konfidenzwerte für Kategorien abzurufen. Rollen wie Storage-Objekt-Nutzer (roles/storage.objectUser) und Storage-Administrator (roles/storage.admin) enthalten diese Berechtigung. Weitere Informationen finden Sie unter Objektkontext-Anreicherungen verwalten.

Berechtigung beim Verwalten von Featurekonfigurationen verweigert

Problem: Beim Erstellen, Aktualisieren oder Löschen einer FeatureConfig tritt ein Berechtigungsfehler auf.

Lösung: Prüfen Sie, ob Ihr Konto die Rolle „Storage-Administrator“ (roles/storage.admin) oder eine benutzerdefinierte Rolle mit den erforderlichen Berechtigungen für das Zielprojekt hat. Zu diesen erforderlichen Berechtigungen gehören storage.featureConfigs.create, storage.featureConfigs.update oder storage.featureConfigs.delete. Informationen zu methodenspezifischen Berechtigungen finden Sie unter Objektkontext-Anreicherung konfigurieren und in der featureConfigs-API-Ressource.

Validierungsfehler bei Jobs für Storage-Batchvorgänge

In diesem Abschnitt werden Validierungsfehler beschrieben, die auftreten, wenn eine Anfrage für einen Batchvorgangsjob an storagebatchoperations.googleapis.com gesendet wird.

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

Problem: Die Anfrage zum Erstellen eines Jobs gibt die Antwort 400 Bad Request (INVALID_ARGUMENT) mit dem Grund JOB_ID_INVALID oder RESOURCE_NAME_TOO_LONG zurück.

Lösung: Prüfen Sie, ob die Job-ID aus 1–63 kleingeschriebenen alphanumerischen Zeichen oder Bindestrichen ([a-z0-9]([-a-z0-9]*[a-z0-9])?) besteht und ob der vollständige Jobressourcenpfad (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 Limit

Problem: Die Anfrage zur Joberstellung gibt die Antwort 400 Bad Request (INVALID_ARGUMENT) mit dem Grund DESCRIPTION_TOO_LONG zurück.

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

400: Fehlende oder ungültige Jobquellenkonfigurationen

Problem: Die Anfrage zum Erstellen des Jobs gibt eine 400 Bad Request-Antwort (INVALID_ARGUMENT) 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 in Ihrem 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 Batchvorgangsjobs erstellen und verwalten.

400: Ungültiger Bucket- oder Objektname

Problem: Die Anfrage zum Erstellen eines Jobs gibt die Antwort 400 Bad Request (INVALID_ARGUMENT) 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 Benennungsrichtlinien für Buckets und den Benennungsrichtlinien für Objekte.

400: Fehler bei der Konfiguration der Projektquelle

Problem: Die Anfrage zum Erstellen des Jobs gibt eine 400 Bad Request-Antwort (INVALID_ARGUMENT) 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 die Quellkonfiguration Ihres Projekts die Anforderungen an die Formatierung und die Feldexklusivität erfüllt. Wenn Sie eine Probelauf-Job-ID angeben, lassen Sie alle anderen project_source-Parameter weg. Weitere Informationen finden Sie unter Job mit erweiterten Filtern erstellen.

400: Konflikt oder fehlende Transformationsparameter

Problem: Die Anfrage zum Erstellen des Jobs gibt eine 400 Bad Request-Antwort (INVALID_ARGUMENT) 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 die Objektsperre 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: Overlapping or duplicate object prefixes

Problem: Die Anfrage zum Erstellen eines Jobs gibt die Antwort 400 Bad Request (INVALID_ARGUMENT) 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 der Manifestdatei und dem Zugriff

Problem: Die Anfrage zum Erstellen des Jobs gibt eine 400 Bad Request-Antwort (INVALID_ARGUMENT) 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 (gs://<bucket_name>/<path>/<object_name>.csv) ist und ob der Dienst-Agent für Storage-Batchvorgänge die Rolle roles/storage.objectViewer für den Manifest-Bucket hat. Weitere Informationen zu den Anforderungen an die CSV-Formatierung und das Schema finden Sie unter Manifest.

400: Fehler bei der Erkennung von Storage Insights-Datasets

Problem: Wenn Sie ein Storage Insights-Dataset für die Objekterkennung verwenden, wird eine 400 Bad Request-Antwort (INVALID_ARGUMENT oder FAILED_PRECONDITION) 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 Erkennungsabfrage nicht mehr als 1.000 Buckets entspricht. Weitere Informationen finden Sie unter Manifest mit Storage Insights-Datasets erstellen.

400: Speicherklassentransformation schlägt bei Buckets mit aktivierter Autoclass-Funktion fehl

Problem: Die Anfrage zum Erstellen des Jobs gibt die Antwort 400 Bad Request (FAILED_PRECONDITION) mit dem Grund AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED zurück.

Lösung: Sie können keine Speicherklassentransformationen für Buckets mit aktivierter Autoclass-Funktion ausführen. Wählen Sie entweder einen Bucket ohne Autoclass aus oder entfernen Sie die Speicherklassentransformation. Weitere Informationen finden Sie unter Autoclass-Einschränkungen.

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

Problem: Die Anfrage zum Erstellen des Jobs gibt die Antwort 400 Bad Request (FAILED_PRECONDITION) 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 Storage-Batchvorgängen

In diesem Abschnitt werden Probleme beschrieben, die während 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: Gewähren Sie dem Dienst-Agenten für Storage-Batchvorgänge (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.iam.gserviceaccount.com) die erforderlichen IAM-Rollen für Ihren Transformationstyp. Weitere Informationen finden Sie unter Berechtigungen für den Dienst-Agent gewähren.

CMEK-Verschlüsselungsfehler beim Neuschreiben von Objekten

Problem: Das Umschreiben von Objekten schlägt aufgrund von Cloud KMS-Schlüsselstatus- oder Berechtigungsfehlern mit 400 Bad Request oder 403 Forbidden 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 Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter hat. Weitere Informationen finden Sie unter Art der Dienstleistung: Objekt umschreiben.

Hohe Anzahl von Fehlern in error_summaries

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

Lösung: Führen Sie gcloud storage batch-operations jobs describe mit dem Flag --location 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 Fehlerlogs pro Objekt. Weitere Informationen finden Sie unter Jobdetails abrufen.

Job für Storage-Batchvorgänge schlägt aufgrund eines Snapshots fehl, der älter als zwei Tage ist

Problem: Wenn Sie einen Job für Storage-Batchvorgänge mit einem CEL-Filter erstellen, schlägt die Erstellung des Jobs fehl. In der Fehlermeldung wird angegeben, dass der Snapshot-Zeitpunkt mehr als zwei Tage zurückliegt.

Lösung: Um Aktionen für veraltete Objektstatus zu verhindern, schlägt die Joberstellung bei Storage-Batchvorgängen automatisch fehl. Dieser Fehler tritt auf, wenn der ausgewählte Snapshot älter als zwei Tage ist. Wählen Sie eine der folgenden Methoden aus, 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 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 Zielspeicherort und Snapshot-Zeit verwenden: Geben Sie das Flag --target-snapshot-time an, um den Fehler aufgrund von zwei Tagen Veraltung 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 die Aktualisierung des automatischen globalen Snapshots verhindern. Daher können Sie manuell einen aktuelleren regionalen Snapshot als Ziel festlegen. Informationen zur Befehlssyntax finden Sie unter Job mit erweiterten Filtern erstellen.

CEL-filterbasierter Job für Storage-Batchvorgänge schlägt bei neu abonnierten Projekten fehl

Problem: Das Ausführen eines CEL-filterbasierten Storage-Batchvorgangsjobs in einem neu abonnierten 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-filterbasierte Storage-Batchvorgangsjobs ausführen können. Durch diese Verzögerung kann das System den ersten Metadaten-Snapshot erstellen und die Startzeit des Snapshots festlegen.

CEL-filterbasierter Job für Storage-Batchvorgänge schlägt mit Berechtigungsfehlern fehl oder löst Laufzeitfehler aus

Problem: Ein CEL-filterbasierter Storage-Batchvorgang schlägt während der Ausführung fehl oder gibt Laufzeitberechtigungsfehler zurück.

Lösung: Bei Storage-Batchvorgängen werden Ihre Nutzeranmeldedaten verwendet, um Objekte zu verarbeiten. Der Job schlägt fehl, wenn Sie nicht die erforderlichen IAM-Lese- 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 Protokollanalyse

Weitere Informationen zum Prüfen von Ausführungsfehlern und Fehlernutzlasten pro Objekt in Cloud Logging finden Sie unter Logs für Storage-Batchvorgänge ansehen.

Probleme mit dem Storage Intelligence-Berater

In diesem Abschnitt finden Sie Anleitungen zur Behebung häufiger Probleme bei der Verwendung des Storage Intelligence Advisor.

Fehler „Berechtigung verweigert“ für Storage Intelligence-Berater

Problem: Sie erhalten einen Permission denied-Fehler, wenn Sie auf den Storage Intelligence Advisor zugreifen, und Diagramme und Messwerte sind leer oder zeigen Berechtigungsfehler an.

Lösung: Dieses Problem tritt auf, wenn Sie keine IAM-Rolle mit den erforderlichen Berechtigungen zum Aufrufen des Storage Intelligence-Beraters haben. Bitten Sie Ihren Administrator, Ihnen die Rolle „Storage-Administrator“ (roles/storage.admin) für das Projekt, den Ordner oder die Organisation zuzuweisen, die Sie aufrufen möchten. Eine Liste der erforderlichen Berechtigungen finden Sie unter Erforderliche Rollen.

Unzureichende Berechtigungen zum Ansehen eines betroffenen Projekts

Problem: Wenn Sie sich Ergebnisse auf Organisations- oder Ordnerebene ansehen, wird im Bereich Projekte mit erkannten Ergebnissen neben einem Projekt ein Warnsymbol mit der Meldung You've insufficient permission to access this project angezeigt.

Lösung: Dieses Problem tritt auf, wenn Sie Berechtigungen zum Aufrufen des Storage Intelligence Advisor auf Organisations- oder Ordnerebene haben, aber nicht die erforderlichen IAM-Berechtigungen für das jeweilige Projekt. Bitten Sie den Projektadministrator, Ihnen die Rolle „Storage-Administrator“ (roles/storage.admin) für das betroffene Projekt zuzuweisen.

Storage Intelligence-Berater ist leer oder Daten fehlen

Problem: Die Seite „Storage Intelligence Advisor“ wird geladen, aber die Diagramme, die Messwerte im Abschnitt Auf einen Blick (je nach ausgewählter Ressource mit Projekt auf einen Blick, Ordner auf einen Blick oder Organisation auf einen Blick bezeichnet) oder der Abschnitt Wichtigste Ergebnisse sind leer oder die Daten sind veraltet.

Lösung: Das Problem kann folgende Ursachen haben:

  • Latenz bei der Datenverarbeitung: Storage Intelligence-Messwerte und -Ergebnisse basieren auf täglichen Snapshots und Analysen der Speichernutzung. Es kann 24 bis 48 Stunden dauern, bis Daten im Storage Intelligence-Berater angezeigt werden. Solche Verzögerungen treten in der Regel auf, nachdem Sie neue Buckets erstellt haben oder wenn Sie den Storage Intelligence-Berater zum ersten Mal aufrufen. Wenn Sie Daten zu den letzten Aktivitäten erwarten, warten Sie 48 Stunden und sehen Sie dann noch einmal nach.
  • Keine Speicherressourcen: Wenn das ausgewählte Projekt, der ausgewählte Ordner oder die ausgewählte Organisation für den ausgewählten Zeitraum keine Buckets oder Objekte enthält, ist der Storage Intelligence-Berater leer. Wählen Sie ein anderes Projekt, einen anderen Ordner oder eine andere Organisation mit Speicherressourcen aus.
  • Falscher Zeitfilter: Der Zeitfilter ist auf einen Bereich festgelegt, in dem keine Speicheraktivität stattgefunden hat. Passen Sie den Zeitfilter auf einen Bereich an, der Speicheraktivitäten enthält.

Ergebnisse werden im Storage Intelligence-Berater nicht angezeigt

Problem: Sie erwarten, dass im Bereich Wichtigste Ergebnisse Ergebnisse basierend auf der letzten Speicheraktivität angezeigt werden, aber der Bereich ist leer.

Lösung: Dieses Problem tritt auf, wenn der Storage Intelligence Advisor für den ausgewählten Zeitraum keine Ergebnisse generiert. Ein Mangel an Ergebnissen kann folgende Ursachen haben:

  • Keine übereinstimmenden Muster: Im letzten Analysezyklus wurde kein Speicherverhalten erkannt, das mit einem Ergebnismuster übereinstimmt.
  • Verzögerungen bei der Datenverarbeitung: Die Ergebnisse basieren auf Speichermesswerten, deren Verarbeitung 24 bis 48 Stunden dauert. Ergebnisse für Ereignisse, die in den letzten 24 Stunden aufgetreten sind, werden nach Abschluss des nächsten Verarbeitungszyklus angezeigt.

Probleme bei der Verwendung von VPC Service Controls

Problem: Sie erhalten Fehler vom Typ „Zugriff verweigert“ oder „Berechtigungsfehler“, wenn Sie versuchen, von einem Projekt innerhalb eines VPC Service Controls-Dienstperimeters auf den Storage Intelligence Advisor zuzugreifen.

Lösung: Dieses Problem tritt auf, wenn VPC Service Controls nicht richtig konfiguriert ist, um die Kommunikation zwischen Ihrem Projekt, der Google Cloud Console und Storage Intelligence-Ressourcen zuzulassen. Prüfen Sie die folgenden Anforderungen, um dieses Problem zu beheben:

  • Eingeschränkte Dienste: Prüfen Sie, ob der Dienstperimeter die Cloud Storage API (storage.googleapis.com) und die Storage Insights API (storageinsights.googleapis.com) einschränkt. Weitere Informationen finden Sie unter Dienstparameter auflisten und beschreiben.
  • Perimeterkonfiguration: Prüfen Sie, ob sich das Projekt, das Sie zum Aufrufen des Storage Intelligence Advisor verwenden, im selben Dienstperimeter befindet wie die Projekte, die Sie überwachen. Wenn sie sich in verschiedenen Perimetern befinden, müssen Sie Regeln für ein- und ausgehenden Traffic konfigurieren oder Perimeter-Bridges verwenden.
  • Zugriff von außerhalb des Perimeters: Wenn Sie von einem Netzwerk außerhalb des Perimeters auf die Google Cloud Console zugreifen, müssen Sie eine Regel für eingehenden Traffic oder eine Zugriffsebene erstellen, die Ihr Nutzerkonto und den von Ihnen verwendeten öffentlichen IP-Adressbereich enthält.
  • Gemeinsam genutzte VPC: Wenn Sie eine freigegebene VPC verwenden, prüfen Sie, ob sich das Projekt im selben Dienstperimeter wie Ihre Dienstprojekte befindet. Weitere Informationen finden Sie unter Gemeinsam genutzte VPC.
  • Audit-Logs: Verwenden Sie das Analysetool für Verstöße, um in Ihren Audit-Logs nach Verstößen gegen VPC Service Controls zu suchen. Mit der Verstoßanalyse können Sie den Verstoß diagnostizieren und Ursachen wie einen RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER-Fehler identifizieren.

Nächste Schritte