Fehlerbehebung bei Beobachtbarkeits-Buckets

In diesem Dokument wird beschrieben, wie Sie Fehler beheben, die möglicherweise mit Observability-Buckets zusammenhängen. Auf dieser Seite wird beispielsweise beschrieben, wie Sie Probleme bei der Konfiguration von Standardeinstellungen für Observability-Buckets beheben. Sie konfigurieren diese Standardeinstellungen für eine Ressource, die eine Organisation, ein Ordner oder ein Projekt sein kann. Damit haben Sie folgende Möglichkeiten:

  • Konfigurieren Sie einen Standardspeicherort für Ihre Observability-Buckets.
  • Für jeden Standort, an dem Sie Daten speichern möchten, können Sie die Verwendung von kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEKs) konfigurieren.

Untergeordnete Elemente in der Ressourcenhierarchie verwenden diese Einstellungen automatisch, sofern Sie keine Standardeinstellungen für sie konfiguriert haben.

Sie sehen keine Trace-Daten

Sie erwarten Daten auf der Seite Trace-Explorer, aber es sind keine Daten vorhanden.

Trace-Daten werden in einem Beobachtungs-Bucket namens _Trace gespeichert. Es gibt mehrere Gründe, warum Sie möglicherweise keine Trace-Daten sehen. Informationen zur Behebung dieses Fehlers finden Sie unter Keine Daten auf der Seite Trace Explorer.

In diesem Abschnitt werden häufige Probleme beim Festlegen oder Löschen des Standardspeicherorts aufgeführt. Dies ist ein Feld in den Standardeinstellungen für Observability-Buckets.

Festlegen des Standardspeicherorts für eine Ressource schlägt fehl

Sie versuchen, den Standardspeicherort für eine Ressource festzulegen, aber der Befehl schlägt fehl:

  • Wenn Sie versuchen, einen Standort festzulegen, der von Observability-Buckets nicht unterstützt wird, schlägt der Vorgang mit dem Fehlercode 400 (Bad Request) fehl. Die Fehlermeldung sieht etwa so aus:

    Unsupported default storage location: my-region
    
  • Ein Versuch, den Standort auf einen Wert festzulegen, der durch eine Organisationsrichtlinie nicht zulässig ist, schlägt mit dem Fehlercode 400 (Bad Request) fehl. Die Fehlermeldung sieht etwa so aus:

    Constraint `constraints/gcp.resourceLocations` violated for `folders/12345` attempting to change `folders/12345/locations/global/settings` with location `invalid`. The location must be in the allowed location list configured by the organization policy administrator.
    

So beheben Sie diese Fehler:

Ein Befehl zum Löschen des Standardspeicherorts schlägt fehl

Sie senden einen updateSettings-Befehl an eine Ressource, bei der der Wert des Standardspeicherorts auf einen leeren String festgelegt ist. Der Befehl schlägt mit dem Fehlercode 400 (Bad Request) fehl. Die Fehlermeldung sieht etwa so aus:

Before you can clear the default storage location for this resource, you must set a default storage location for an ancestor in the resource hierarchy.

oder

The default storage location may not be removed from an organization's Settings.

Das ist ganz normal.

Nachdem ein Standardspeicherort für eine Ressource festgelegt wurde, können Sie den Wert ändern, aber nicht löschen oder aufheben, es sei denn, der Standardspeicherort ist für ein übergeordnetes Element in der Ressourcenhierarchie angegeben. Sie können den Standardspeicherort für eine Organisation nicht löschen oder aufheben, da sie keine übergeordneten Organisationen hat.

Der Speicherort eines Observability-Buckets steht im Konflikt mit einer Organisationsrichtlinie

Sie stellen fest, dass die Standorte einiger Observability-Buckets mit den zulässigen Standorten einer Organisationsrichtlinie in Konflikt stehen.

Dies ist kein Fehler.

Organisationsrichtlinien, die den Standort einschränken, werden von Observability-Buckets nicht berücksichtigt.

Es gibt mehrere Gründe, warum sich der Standort eines Observability-Buckets an einem Ort befinden kann, der durch eine Organisationsrichtlinie nicht zulässig ist:

  • Der Observability-Bucket wurde vor dem 1. Juni 2026 erstellt. An diesem Datum begann die Durchsetzung der Organisationsrichtlinie, die den Standort einschränkt.

  • Die Organisationsrichtlinie wurde nach der Erstellung des Observability-Buckets geändert.

In diesem Abschnitt werden häufige Probleme bei der Verwendung von CMEKs aufgeführt.

Ein Befehl zum Löschen des Cloud KMS-Standardschlüssels schlägt fehl

Sie geben den Befehl updateSettings für eine Ressource und einen Standort aus, wobei der Wert des Cloud KMS-Standardschlüssels auf einen leeren String festgelegt ist. Der Befehl schlägt mit dem Fehlercode 400 (Bad Request) fehl. Die Fehlermeldung sieht etwa so aus:

The default KMS key cannot be empty because you have an organization policy that requires CMEK and because no ancestor defines a default KMS key.

oder

The default KMS key cannot be empty because you have an organization policy that requires CMEK.

Das ist ganz normal.

Wenn Sie eine Organisationsrichtlinie haben, die die Verwendung von CMEKs erfordert, und einen Cloud KMS-Standardschlüssel für eine Ressource und einen Standort festgelegt haben, können Sie diesen Schlüssel nur entfernen, wenn ein übergeordnetes Element der Ressource einen entsprechenden Standardschlüssel hat. Da Organisationen keine übergeordneten Elemente haben, können Sie den Standard-Cloud KMS-Schlüssel nicht aus den Standardeinstellungen der Organisation entfernen.

Wie finde ich den Schlüssel, der von einem Observability-Bucket verwendet wird?

Wenn Sie Informationen zum Verschlüsselungsschlüssel für einen Observability-Bucket abrufen möchten, listen Sie Ihre Observability-Buckets auf.

Die Antwortdaten enthalten Informationen zum Cloud KMS-Schlüssel, seiner Version und dem Dienstkonto, das für den Zugriff auf den Schlüssel verwendet wurde.

Fehler bei der Schlüsselkonfiguration beheben

Nachdem Sie einen standardmäßigen Cloud KMS-Schlüssel für eine Ressource und einen Standort konfiguriert haben, erhalten Sie entweder eine E-Mail-Benachrichtigung von Google Cloud Observability zu Zugriffsproblemen oder Sie bemerken Lese- oder Schreibfehler in Observability-Buckets mit aktiviertem CMEK. Die E-Mail, die an wichtige Kontakte gesendet wird, enthält Informationen wie die folgenden:

  • Cloud KMS-Schlüsselname.
  • Cloud KMS-Schlüsselversion.
  • Name des Dienstkontos, das für die Verschlüsselung und Entschlüsselung verwendet wird.
  • Der Fehlercode, der von Google Cloud Observability beim Verschlüsseln oder Entschlüsseln von Daten angezeigt wird.
  • Fehlermeldung beim Verschlüsseln oder Entschlüsseln von Daten

Die Benachrichtigung enthält Informationen zum Fehler und Maßnahmen, die Sie ergreifen können, um das Problem zu beheben:

Fehler Empfehlung
Berechtigung für kryptografischen Schlüssel verweigert

Das Dienstkonto der Ressource hat nicht die erforderlichen IAM-Berechtigungen für den angegebenen Cloud KMS-Schlüssel. Folgen Sie der Anleitung in der Fehlermeldung, um diesen Fehler zu beheben. Die folgenden Informationen könnten hilfreich sein:

Kryptografischer Schlüssel ist deaktiviert

Der angegebene Cloud KMS-Schlüssel war deaktiviert. Folgen Sie der Anleitung in der Fehlermeldung, um den Schlüssel wieder zu aktivieren. Die folgenden Informationen könnten hilfreich sein:

Kryptografischer Schlüssel wurde gelöscht Der angegebene Cloud KMS-Schlüssel war gelöscht. Folgen Sie der Anleitung oder lesen Sie den Abschnitt Cloud KMS-Schlüssel für eine Ressource verwalten.

Bereitstellung eines Beobachtbarkeits-Buckets schlägt fehl

Sie sind ein wichtiger Kontakt oder Inhaber einer Ressource und erhalten eine E-Mail-Benachrichtigung von Google Cloud Observability über einen Bereitstellungsfehler.

Die Bereitstellung eines Observability-Buckets kann aufgrund eines Konfigurationsfehlers oder eines internen Fehlers fehlschlagen:

Im Rest dieses Abschnitts wird beschrieben, wie Sie häufige Konfigurationsprobleme untersuchen.

Organisationsrichtlinie mit Einschränkungen für Standorte prüfen

Sehen Sie sich die zulässigen Standorte an, die in einer Organisationsrichtlinie mit der Einschränkungs-ID constraints/gcp.resourceLocations angegeben sind. Mit dieser Richtlinie wird die Gruppe von Standorten definiert, an denen neue Ressourcen erstellt werden können.

Die Liste der zulässigen Standorte muss mindestens einen unterstützten Bucket-Standort für die Beobachtbarkeit enthalten. Die Bereitstellung schlägt fehl, wenn der Standardspeicherort kein zulässiger Speicherort ist.

Weitere Informationen finden Sie unter Organisationsrichtlinien aufrufen.

Standardmäßige Speicherorte für Ihre Ressourcen prüfen

Überprüfen Sie die Standardeinstellungen für Observability-Buckets für Organisationen, Ordner oder Projekte mit einem Standardspeicherort und aktualisieren Sie sie bei Bedarf.

Weitere Informationen finden Sie unter Standardeinstellungen für Observability-Buckets ansehen.

Organisationsrichtlinien überprüfen, die CMEKs erfordern

Für CMEKs gelten zwei Einschränkungen. Eine Einschränkung schränkt die Cloud KMS-Schlüssel ein, die für die Verschlüsselung verwendet werden können. Für die andere Einschränkung ist die Verwendung von Cloud KMS-Schlüsseln erforderlich.

Richtlinie für eingeschränkt zulässige Inhalte

Prüfen Sie, ob Sie eine Richtlinie mit der Einschränkungs-ID constraints/gcp.restrictCmekCryptoKeyProjects konfiguriert haben.

Wenn Sie das getan haben, achten Sie darauf, dass Ihre standardmäßigen Cloud KMS-Schlüssel durch die Organisationsrichtlinie zugelassen werden.

Richtlinie erforderlich

Prüfen Sie, ob Sie eine Deny-Richtlinie mit der Constraint-ID constraints/gcp.restrictNonCmekServices konfiguriert haben.

Wenn ja, muss ein Standard-Cloud KMS-Schlüssel für den Standardspeicherort definiert sein. Wenn Sie auch eine Richtlinie konfiguriert haben, um einzuschränken, welche Schlüssel verwendet werden können, muss Ihr standardmäßiger Cloud KMS-Schlüssel zulässig sein.

Wenn Ihre Richtlinien beispielsweise auf Organisationsebene gelten, müssen Sie die Standardeinstellungen für Observability-Buckets für Ihre Organisation mit einem Standardspeicherort und einem standardmäßigen Cloud KMS-Schlüssel für diesen Speicherort konfigurieren.

Google Cloud Observability kann keine Observability-Buckets bereitstellen, wenn CMEKs erforderlich sind, aber kein Schlüssel zum Verschlüsseln oder Entschlüsseln dieser Daten verfügbar ist.

Cloud KMS-Schlüssel auf Nutzbarkeit prüfen

So prüfen Sie, ob ein Cloud KMS-Schlüssel verwendet werden kann:gcloud kms keys list

gcloud kms keys list \
--location=LOCATION_ID \
--keyring=KMS_KEY_RING

Ersetzen Sie vor dem Ausführen des vorherigen Befehls Folgendes:

  • LOCATION_ID: Der Speicherort Ihres Cloud KMS-Schlüssels.
  • KMS_KEY_RING: Der Name des Cloud KMS-Schlüsselbunds.

Der vorherige Befehl gibt Informationen zu jedem Schlüssel am angegebenen Speicherort zurück. Achten Sie darauf, dass für Ihren Cloud KMS-Schlüssel Folgendes gilt:

  • Der Cloud KMS-Schlüssel ist in der Tabelle aufgeführt.
  • In der Spalte STATUS werden ENABLED aufgeführt.
  • In der Spalte PURPOSE werden ENCRYPT_DECRYPT aufgeführt. Diese Einstellung gibt an, dass der Zweck des Schlüssels die symmetrische Verschlüsselung ist:

Erstellen Sie bei Bedarf einen neuen Cloud KMS-Schlüssel und aktualisieren Sie die Standardeinstellungen für Observability-Buckets für die zugehörige Ressource und den zugehörigen Standort.

Prüfen, ob das Dienstkonto die erforderliche Rolle hat

Prüfen Sie, ob dem Dienstkonto der Ressource die Rolle Cloud KMS CryptoKey Encrypter/Decrypter für den Cloud KMS-Schlüssel zugewiesen wurde, der in den Standardeinstellungen für Beobachtbarkeit-Buckets für die Ressource aufgeführt ist.

Führen Sie den folgenden Befehl aus, um die Bindungen für einen Cloud KMS-Schlüssel zu ermitteln:

gcloud kms keys get-iam-policy KMS_KEY_NAME

Weisen Sie dem Dienstkonto der Ressource bei Bedarf die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ für den Schlüssel zu. Weitere Informationen finden Sie unter Dienstkonto Zugriff auf einen Schlüssel gewähren.