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 Storage-Batchvorgängen beheben.

Konfigurationsfehler bei Storage Intelligence

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. 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.

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./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 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 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 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 Storage-Batchvorgangsjobs

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 ob der vollständige Job Ressourcenpfad (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: Achten Sie darauf,dass die Jobbeschreibung maximal 1.024 Byte lang ist. 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 in Ihrem Job eine gültige Quellkonfiguration (bucket_list oder project_source) angegeben ist und dass für jeden Bucket eine Methode zur Objekt auswahl 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 im RFC 3339-UTC-Format verwendet werden. 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 Storage-Batchvorgangs-Dienst-Agent 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 Storage Insights-Datasetermittlung

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: 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. Verwenden Sie entweder einen Bucket ohne Autoclass oder entfernen Sie 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 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 Storage-Batchvorgä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 Storage-Batchvorgangs-Dienst-Agent (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.) 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.

Storage-Batchvorgangsjob schlägt aufgrund eines mehr als zwei Tage alten Snapshots fehl

Problem: Wenn Sie einen CEL-Filter-basierten Storage-Batchvorgangsjob 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 Storage-Batchvorgä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.
  • Datasetkonfigurationen prüfen: Prüfen Sie, ob Ihre Datasetkonfigurationen aktiv sind und nicht pausiert wurden. Bestätigen Sie, dass Dataset-Snapshots erfolgreich ausgeführt werden. Informationen zum Prüfen Ihrer Konfigurationen finden Sie unter Datasetkonfiguration ansehen.
  • Überschreibungen für Zielstandort und Snapshot-Zeitpunkt 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 aktuelleren regionalen Snapshot auswählen. Die Befehlssyntax finden Sie unter Job mit erweiterten Filtern erstellen.

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

Problem: Wenn Sie einen CEL-Filter-basierten Storage-Batchvorgangsjob 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 CEL-Filter-basierte Storage-Batchvorgangsjobs 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.

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

Problem: Ein CEL-Filter-basierter Storage-Batchvorgangsjob schlägt während der Ausführung fehl oder gibt Berechtigungsfehler zur Laufzeit zurück.

Lösung: Storage-Batchvorgänge verwenden Ihre Nutzeranmeldedaten, 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 Storage-Batchvorgänge ansehen.

Probleme mit dem Storage Intelligence-Berater

In diesem Abschnitt finden Sie eine Anleitung zur Behebung häufig auftretender Probleme bei der Verwendung des Storage Intelligence-Beraters.

Fehler „Permission denied“ (Berechtigung verweigert) beim Storage Intelligence-Berater

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

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 Aufrufen eines betroffenen Projekts

Problem: Wenn Sie Ergebnisse auf Organisationsebene oder Ordnerebene aufrufen, 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-Beraters auf Organisationsebene oder Ordnerebene haben, aber nicht die erforderlichen IAM-Berechtigungen für dieses bestimmte Projekt. Bitten Sie den Projektadministrator, Ihnen die Rolle „Storage-Administrator“ (roles/storage.admin) für das betroffene Projekt zuzuweisen.

Der Storage Intelligence-Berater ist leer oder Daten fehlen

Problem: Die Seite des Storage Intelligence-Beraters wird geladen und die Diagramme, Messwerte im Bereich Auf einen Blick (je nach ausgewählter Ressource mit der Bezeichnung Projekt auf einen Blick, Ordner auf einen Blick oder Organisation auf einen Blick) oder der Bereich Top-Ergebnisse sind leer oder die Daten sind veraltet.

Lösung: Dieses 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 aktuelle Aktivitätsdaten sehen möchten, warten Sie 48 Stunden und prüfen Sie dann noch einmal.
  • Keine Speicherressourcen: Wenn das ausgewählte Projekt, der ausgewählte Ordner oder die ausgewählte Organisation im 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 aus, die Speicherressourcen enthält.
  • Falscher Zeitfilter: Der Zeitfilter ist auf einen Zeitraum festgelegt, in dem keine Speicheraktivität stattgefunden hat. Passen Sie den Zeitfilter an einen Zeitraum an, der Speicheraktivität enthält.

Ergebnisse werden im Storage Intelligence-Berater nicht angezeigt

Problem: Sie erwarten, dass im Bereich Top-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-Berater 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: 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 wegen verweigertem Zugriff oder Berechtigungsfehler, wenn Sie versuchen, über ein Projekt in einem VPC Service Controls-Dienstperimeter auf den Storage Intelligence-Berater 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 zu ermöglichen. 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 (storageinsights.googleapis.com) API einschränkt. Weitere Informationen finden Sie unter Dienstparameter auflisten und beschreiben.
  • Perimeterkonfiguration: Prüfen Sie, ob sich das Projekt, mit dem Sie den Storage Intelligence-Berater aufrufen, im selben Dienstperimeter wie die von Ihnen überwachten Projekte befindet. Wenn sie sich in verschiedenen Perimetern befinden, müssen Sie Regeln für eingehenden und ausgehenden Traffic konfigurieren oder Perimeter-Bridges verwenden.
  • Zugriff von außerhalb des Perimeters: Wenn Sie über ein 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 öffentlichen IP-Adressbereich enthält, den Sie verwenden.
  • 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 die Verstoßanalyse, um in Ihren Audit-Logs nach VPC Service Controls-Verstößen zu suchen. Die Verstoßanalyse hilft, den Verstoß zu diagnostizieren und Ursachen wie den Fehler RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER zu identifizieren.

Nächste Schritte