Fehlerbehebung für Benachrichtigungsrichtlinien

Auf dieser Seite wird erläutert, warum sich einige Benachrichtigungsrichtlinien möglicherweise anders als beabsichtigt verhalten. Weiter werden mögliche Lösungen für diese Situationen aufgezeigt.

Informationen zu den Variablen, die sich nach der Wahl des Dauerfensters auf eine Benachrichtigungsrichtlinie auswirken können, finden Sie beispielsweise unter Verhalten von messwertbasierten Benachrichtigungsrichtlinien.

Variable für Messwertlabel ist null

Sie erstellen eine Benachrichtigungsrichtlinie und fügen im Dokumentationsabschnitt eine Variable für ein Messwertlabel hinzu. Sie erwarten, dass in den Benachrichtigungen der Wert der Variablen angezeigt wird. Der Wert ist jedoch auf null gesetzt.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Achten Sie darauf, dass in den Aggregationseinstellungen für die Benachrichtigungsrichtlinie das Label beibehalten wird, das Sie anzeigen möchten.

    Angenommen, Sie erstellen eine Benachrichtigungsrichtlinie, die die von VM-Instanzen geschriebenen Laufwerkbyte überwacht. Sie möchten, dass das Gerät, das die Benachrichtigung verursacht, in der Dokumentation aufgeführt ist. Dazu fügen Sie dem Dokumentationsfeld Folgendes hinzu: device: ${metric.label.device}.

    Außerdem muss in den Aggregationseinstellungen der Wert des Labels device beibehalten werden. Sie können dieses Label beibehalten, indem Sie die Aggregationsfunktion auf none setzen oder dafür sorgen, dass die Gruppierungsauswahl device enthält.

  • Überprüfen Sie die Syntax und Anwendbarkeit der Variable. Informationen zur Syntax finden Sie unter Benachrichtigungen mit benutzerdefinierter Dokumentation annotieren.

    Die Variable log.extracted_label.KEY wird beispielsweise nur für logbasierte Benachrichtigungen unterstützt. Diese Variable wird immer als null gerendert, wenn eine Benachrichtigungsrichtlinie einen Messwert überwacht. Dies gilt auch für einen logbasierten Messwert.

Richtlinie zur Laufwerksauslastung bedingt unerwartete Vorfälle

Sie haben eine Benachrichtigungsrichtlinie erstellt, um die „genutzte“ Kapazität der Laufwerke in Ihrem System zu überwachen. Diese Richtlinie überwacht den Messwert agent.googleapis.com/disk/percent_used. Sie erwarten, nur dann benachrichtigt zu werden, wenn die Auslastung eines physischen Laufwerks den in der Bedingung festgelegten Grenzwert überschreitet. Diese Richtlinie führt jedoch zu Vorfällen, wenn die Laufwerksauslastung jedes physischen Laufwerks unter dem Grenzwert liegt.

Eine bekannte Ursache für unerwartete Vorfälle bei solchen Richtlinien ist, dass die Bedingungen nicht auf das Monitoring physischer Laufwerke beschränkt sind. Stattdessen überwachen diese Richtlinien alle Laufwerke, einschließlich virtueller Laufwerke, darunter Loopback-Geräte. Wenn ein virtuelles Laufwerk so entworfen wurde, dass seine Auslastung bei 100 % liegt, würde dies die Richtlinie dazu motivieren, einen Vorfall auszulösen.

Betrachten Sie beispielsweise folgende Ausgabe des Linux-Befehls df, der den auf bereitgestellten Dateisystemen verfügbaren Speicherplatz für ein System zeigt:

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

Für dieses System sollte eine Benachrichtigungsrichtlinie zur Laufwerksauslastung konfiguriert werden, um die Zeitachsen für die Loopback-Geräte /dev/loop0 und /dev/loop1 herauszufiltern. Sie können beispielsweise den Filter device !=~ ^/dev/loop.* hinzufügen, der alle Zeitachsen ausschließt, deren device-Label nicht dem regulären Ausdruck ^/dev/loop.* entspricht.

Verfügbarkeitsrichtlinien erstellen keine erwarteten Benachrichtigungen

Sie möchten benachrichtigt werden, wenn eine virtuelle Maschine (VM) neu startet oder heruntergefahren wird. Daher erstellen Sie eine Benachrichtigungsrichtlinie, die den Messwert compute.googleapis.com/instance/uptime überwacht. Sie erstellen und konfigurieren die Bedingung so, dass ein Vorfall generiert wird, wenn keine Messwertdaten vorhanden sind. Sie definieren die Bedingung nicht mit Monitoring Query Language (MQL)1. Sie werden nicht benachrichtigt, wenn die virtuelle Maschine (VM) neu startet oder heruntergefahren wird.

Diese Benachrichtigungsrichtlinie überwacht nur Zeitachsen für Compute Engine-VM-Instanzen mit dem Status RUNNING. Zeitachsen für VMs mit einem anderen Status wie STOPPED oder DELETED werden herausgefiltert, bevor die Bedingung ausgewertet wird. Aufgrund dieses Verhaltens können Sie keine Benachrichtigungsrichtlinie mit einer Benachrichtigungsbedingung für fehlende Messwerte verwenden, um festzustellen, ob eine VM-Instanz ausgeführt wird. Informationen zu VM-Instanzstatus finden Sie unter Lebenszyklus von VM-Instanzen.

Um dieses Problem zu beheben, erstellen Sie eine Benachrichtigungsrichtlinie, um eine Verfügbarkeitsdiagnose zu überwachen. Verwenden Sie für private Endpunkte private Verfügbarkeitsdiagnosen.

Eine mögliche Alternative zu Benachrichtigungen zu Verfügbarkeitsdiagnosen ist die Verwendung von Benachrichtigungsrichtlinien, die das Fehlen von Daten überwachen. Wir empfehlen dringend, Benachrichtigungen zu Verfügbarkeitsdiagnosen anstelle von fehlenden Daten zu verwenden: Fehlalarme können zu falsch positiven Ergebnissen führen, wenn vorübergehende Probleme mit der Verfügbarkeit von Monitoring-Daten vorliegen.

Wenn die Verwendung von Verfügbarkeitsdiagnosen jedoch nicht möglich ist, können Sie eine Benachrichtigungsrichtlinie mit MQL erstellen, die Sie darüber informiert, dass die VM heruntergefahren wurde. Mit MQL-Bedingungen werden Zeitreihendaten nicht vorab anhand des Status der VM-Instanz gefiltert. Da MQL Daten nicht nach VM-Status filtert, können Sie es verwenden, um das Fehlen von Daten von VMs zu erkennen, die heruntergefahren wurden.

Betrachten Sie folgende MQL-Bedingung, die den Messwert compute.googleapis.com/instance/cpu/utilization überwacht:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

Wenn eine von dieser Bedingung überwachte VM heruntergefahren wird, wird drei Minuten später ein Vorfall generiert und es werden Benachrichtigungen gesendet. Der absent_for-Wert muss mindestens drei Minuten betragen.

Weitere Informationen zu MQL finden Sie unter Benachrichtigungsrichtlinien mit MQL.

1: MQL ist eine ausdrucksstarke textbasierte Sprache, die für Cloud Monitoring API-Aufrufe und in der Google Cloud Console verwendet werden kann. Wenn Sie bei der Verwendung der Google Cloud Console eine Bedingung mit MQL konfigurieren möchten, müssen Sie den Codeeditor verwenden.

Die Richtlinie für die Anfrageanzahl erstellt keine erwarteten Benachrichtigungen

Sie möchten die Anzahl der abgeschlossenen Anfragen beobachten. Sie haben eine Benachrichtigungsrichtlinie erstellt, die den Messwert serviceruntime.googleapis.com/api/request_count überwacht. Sie werden jedoch nicht benachrichtigt, wenn die Anzahl der Anfragen den von Ihnen konfigurierten Grenzwert überschreitet.

Der maximale Ausrichtungszeitraum für den Messwert für die Anzahl der Anfragen beträgt 7 Stunden und 30 Minuten.

Prüfen Sie den Wert des Ausrichtungszeitraums in der Benachrichtigungsrichtlinie, um dieses Problem zu beheben. Wenn der Wert länger als das Maximum für diesen Messwert ist, verkürzen Sie den Ausrichtungszeitraum so, dass er nicht mehr als 7 Stunden und 30 Minuten beträgt.

Häufige Ursachen für ungewöhnliche Vorfälle

Sie haben eine Benachrichtigungsrichtlinie erstellt und die Richtlinie scheint vorzeitig oder fälschlicherweise Vorfälle zu erstellen.

Es gibt verschiedene Gründe, warum Sie eine Benachrichtigung über Vorfälle erhalten, die nicht korrekt zu sein scheinen:

  • Wenn es eine Datenlücke gibt, insbesondere bei den Benachrichtigungsrichtlinien mit Bedingungen für das Fehlen von Messwerten oder „weniger als“-Schwellenwerten, kann ein Vorfall erstellt werden, der anomal zu sein scheint. Manchmal zeigt der Vorfall die Datenlücke nicht an und manchmal wird sie automatisch korrigiert:

    • In Diagrammen werden beispielsweise keine Lücken angezeigt, weil die Werte für fehlende Daten interpoliert werden. Auch wenn einige Minuten an Daten fehlen, verbindet das Diagramm fehlende Punkte für die visuelle Kontinuität. Eine solche Lücke in den zugrunde liegenden Daten kann ausreichen, damit eine Benachrichtigungsrichtlinie einen Vorfall erstellen kann.

    • Punkte in logbasierten Messwerten können zu spät eintreffen und für die letzten 10 Minuten aufgefüllt werden. Das Backfill-Verhalten korrigiert die Lücke effektiv. Die Lücke wird ausgefüllt, sobald die Daten eintreffen. Daher kann eine nicht mehr sichtbare Lücke in einem logbasierten Messwert dazu geführt haben, dass eine Benachrichtigungsrichtlinie einen Vorfall erstellt hat.

  • Bedingungen für fehlende Messwerte oder Messwertschwellen, die eine Untergrenze festlegen, werden mit einer kleinen Abfrageverzögerung in Echtzeit ausgewertet. Der Status der Bedingung kann sich zwischen der Zeit der Bewertung und der Zeit ändern, zu dem der entsprechende Vorfall in Monitoring sichtbar ist.

  • Bedingungen, die so konfiguriert sind, dass ein Vorfall auf Basis einer einzelnen Messung erstellt wird, können dazu führen, dass Vorfälle vorzeitig oder falsch erscheinen. Achten Sie zur Vermeidung dieser Situation darauf, dass mehrere Messungen erforderlich sind, bevor ein Vorfall erstellt wird. Dazu legen Sie das Feld Dauer einer Bedingung auf mehr als das Doppelte der Stichprobenrate des Messwerts fest.

    Beispiel: Wenn ein Messwert alle 60 Sekunden als Stichprobe verwendet wird, legen Sie die Dauer auf mindestens 3 Minuten fest. Wenn Sie das Feld für die Dauer auf den aktuellsten Wert oder auf gleich 0 Sekunden festlegen, kann eine einzelne Messung dazu führen, dass ein Vorfall erstellt wird.

  • Wenn die Bedingung einer Benachrichtigungsrichtlinie bearbeitet wird, kann es mehrere Minuten dauern, bis die Änderung in der Benachrichtigungsinfrastruktur wirksam wird. Während dieses Zeitraums erhalten Sie möglicherweise Benachrichtigungen über Vorfälle, die die ursprünglichen Bedingungen der Benachrichtigungsrichtlinie erfüllt haben.

  • Wenn Zeitreihendaten eingehen, kann es bis zu einer Minute dauern, bis die Daten in der gesamten Benachrichtigungsinfrastruktur weitergegeben werden. Wenn der Ausrichtungszeitraum auf eine Minute oder auf die letzte Stichprobe festgelegt ist, kann die Verteilungslatenz den Eindruck erwecken, dass die Benachrichtigungsrichtlinie nicht korrekt ausgelöst wird. Verwenden Sie einen Ausrichtungszeitraum von mindestens fünf Minuten, um die Wahrscheinlichkeit dieser Situation zu verringern.

Vorfall wird nicht geschlossen, wenn keine Daten mehr eingehen

Sie folgen der Anleitung unter Teilmesswertdaten und konfigurieren eine Benachrichtigungsrichtlinie, um Vorfälle zu schließen, wenn keine Daten mehr eingehen. In einigen Fällen gehen keine Daten ein, aber ein offener Vorfall wird nicht automatisch geschlossen.

Wenn die zugrunde liegende Ressource, die von einer Benachrichtigungsrichtlinie überwacht wird, das Label metadata.system_labels.state enthält und diese Richtlinie nicht mit der Monitoring Query Language geschrieben ist, kann Monitoring den Status der Ressource ermitteln. Wenn der Status einer Ressource bekanntermaßen deaktiviert ist, schließt Monitoring Vorfälle nicht automatisch, wenn keine Daten mehr eingehen. Sie können diese Vorfälle jedoch manuell schließen.

Mit Richtlinien mit mehreren Bedingungen werden mehrere Benachrichtigungen erstellt

Sie haben eine Benachrichtigungsrichtlinie erstellt, die mehrere Bedingungen enthält, und haben diese mit einem logischen AND verknüpft. Sie erwarten, nur eine Benachrichtigung zu erhalten und einen Vorfall zu erstellen, wenn alle Bedingungen erfüllt sind. Sie erhalten jedoch mehrere Benachrichtigungen und sehen, dass mehrere Vorfälle erstellt werden.

Monitoring sendet eine Benachrichtigung und erstellt einen Vorfall für jede Zeitachse, die zum Erfüllen einer Bedingung führt. Wenn Sie Benachrichtigungsrichtlinien mit mehreren Bedingungen haben, können Sie daher möglicherweise eine Benachrichtigung und einen Vorfall für jede Zeitachse erhalten, die dazu führt, dass die verknüpften Bedingungen erfüllt werden.

Angenommen, Sie haben eine Benachrichtigungsrichtlinie mit zwei Bedingungen, wobei jede Bedingung drei Zeitachsen überwacht. Die Richtlinie sendet nur dann eine Benachrichtigung, wenn beide Bedingungen erfüllt sind. Wenn die Bedingungen Ihrer Richtlinie erfüllt sind, können Sie 2 (eine Zeitachse ist in jeder Bedingung erfüllt) bis 6 (alle Zeitreihen in jeder Bedingung erfüllt) Benachrichtigungen und Vorfälle erhalten.

Sie können Monitoring nicht so konfigurieren, dass ein einzelner Vorfall erstellt und eine einzelne Benachrichtigung gesendet wird.

Weitere Informationen finden Sie unter Benachrichtigungen pro Vorfall.

Details zum Vorfall können aufgrund eines Berechtigungsfehlers nicht angezeigt werden

Sie rufen in der Google Cloud Console die Seite „Vorfälle“ auf und wählen einen Vorfall aus, den Sie ansehen möchten. Sie erwarten, dass die Detailseite geöffnet ist. Die Detailseite wird jedoch nicht geöffnet und die Meldung „Berechtigung verweigert“ wird angezeigt.

Zum Ansehen aller Details zu Vorfällen mit Ausnahme von Messwertdaten benötigen Sie die IAM-Rollen (Identity and Access Management) für die Rolle „Monitoring Cloud Console Incident Viewer“ (roles/monitoring.cloudConsoleIncidentViewer) und „Stackdriver Account Viewer“ (roles/stackdriver.accounts.viewer).

Damit Sie alle Vorfalldetails einschließlich der Messwertdaten ansehen und Vorfälle bestätigen oder schließen können, benötigen Sie die IAM-Rollen „Monitoring Viewer“ (roles/monitoring.viewer) und „Monitoring Cloud Console Incident Editor“ (roles/monitoring.cloudConsoleIncidentEditor).

Benutzerdefinierte Rollen können die zur Anzeige von Vorfalldetails erforderlichen Berechtigung nicht erteilen.

Vorfall wird nicht erstellt, wenn Bedingung erfüllt ist

Sie haben eine Benachrichtigungsrichtlinie mit einer Bedingung erstellt. Das Benachrichtigungsdiagramm zeigt, dass die überwachten Daten gegen die Bedingung verstoßen, Sie aber keine Benachrichtigung erhalten haben und es keinen Vorfall erstellt.

Wenn eines der folgenden Kriterien erfüllt ist, nachdem die Bedingung der Benachrichtigungsrichtlinie erfüllt ist, öffnet Monitoring den Vorfall nicht.

  • Die Benachrichtigungsrichtlinie ist snoozed.
  • Die Benachrichtigungsrichtlinie ist deaktiviert.
  • Die Benachrichtigungsrichtlinie hat die maximale Anzahl von Vorfällen erreicht, die gleichzeitig geöffnet werden können.

  • Der Status der Ressource, die von der Benachrichtigungsrichtlinie überwacht wird, ist bekanntermaßen deaktiviert. Monitoring kann den Status einer Ressource ermitteln, wenn sie das Label metadata.system_labels.state enthält und die Benachrichtigungsrichtlinie nicht in der Monitoring Query Language geschrieben ist.

Liste der Vorfalldetails falsches Projekt

Sie erhalten eine Benachrichtigung und in der Bedingungsübersicht ist das Google Cloud-Projekt aufgeführt, in dem der Vorfall erstellt wurde, d. h. das den Umfang festlegende Projekt. Sie erwarten jedoch, dass für den Vorfall der Name des Google Cloud-Projekts aufgeführt wird, in dem die Zeitachse gespeichert ist, die zum Erstellen des Vorfalls durch Monitoring geführt hat.

Die in der Bedingung einer Benachrichtigungsrichtlinie angegebenen Aggregationsoptionen bestimmen, auf welches Google Cloud-Projekt in einer Benachrichtigung verwiesen wird:

  • Wenn durch die Aggregationsoptionen das Label entfernt wird, in dem die Projekt-ID gespeichert ist, wird in den Vorfallinformationen das den Umfang festlegende Projekt aufgeführt. Wenn Sie beispielsweise die Daten nur nach Zone gruppieren, wird nach der Gruppierung das Label entfernt, in dem die Projekt-ID gespeichert ist.

  • Wenn in den Aggregationsoptionen das Label mit der Projekt-ID beibehalten wird, enthalten die Vorfallsbenachrichtigungen den Namen des Google Cloud-Projekts, in dem die Zeitreihe gespeichert ist, die zum Auftreten des Vorfalls geführt hat. Damit das Projekt-ID-Label erhalten bleibt, nehmen Sie das Label project_id in das Gruppierungsfeld auf oder gruppieren Sie nicht die Zeitachse.

Vorfall kann nicht manuell geschlossen werden

Sie haben eine Benachrichtigung über einen Vorfall in Ihrem System erhalten. Sie rufen die Seite mit den Details zum Vorfall auf und klicken auf Vorfall schließen. Sie erwarten, dass der Vorfall geschlossen wird, es wird jedoch die folgende Fehlermeldung angezeigt:

Unable to close incident with active conditions.

Sie können einen Vorfall nur schließen, wenn im letzten Benachrichtigungszeitraum keine Beobachtungen eingegangen sind. Der Benachrichtigungszeitraum, der in der Regel einen Standardwert von 5 Minuten hat, wird als Teil der Bedingung der Benachrichtigungsrichtlinie definiert und ist konfigurierbar. Die vorherige Fehlermeldung gibt an, dass die Daten innerhalb des Benachrichtigungszeitraums empfangen wurden.

Der folgende Fehler tritt auf, wenn ein Vorfall aufgrund eines internen Fehlers nicht geschlossen werden kann:

Unable to close incident. Please try again in a few minutes.

Wenn Sie die vorherige Fehlermeldung sehen, können Sie den Vorgang zum Schließen wiederholen oder den Vorfall automatisch von Monitoring schließen lassen.

Weitere Informationen finden Sie unter Vorfälle verwalten.

Ich erhalte keine Benachrichtigungen

Sie konfigurieren Benachrichtigungskanäle und erwarten, dass Sie bei Vorfällen benachrichtigt werden. Du erhältst keine Benachrichtigungen.

Informationen zum Beheben von Problemen mit Webhook- und Pub/Sub-Benachrichtigungen finden Sie in den folgenden Abschnitten dieses Dokuments:

So ermitteln Sie Informationen zur Ursache des Fehlers:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Logging und anschließend Log-Explorer aus:

    Zum Log-Explorer

  2. Wählen Sie das entsprechende Google Cloud-Projekt aus.

  3. Fragen Sie die Logs nach Ereignissen im Benachrichtigungskanal ab:

    1. Maximieren Sie das Menü Logname und wählen Sie notification_channel_events aus.
    2. Maximieren Sie das Menü Schweregrad und wählen Sie Fehler aus.
    3. Optional: Über die Zeitraumauswahl können Sie einen benutzerdefinierten Zeitraum festlegen.
    4. Klicken Sie auf Abfrage ausführen.

    In den vorherigen Schritten wird die folgende Abfrage erstellt:

    logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR

    Fehlerinformationen finden Sie normalerweise in der Zusammenfassungszeile und im Feld jsonPayload.

    Die Zusammenfassungszeile und das Feld jsonPayload enthalten normalerweise Fehlerinformationen. Wenn beispielsweise ein Gatewayfehler auftritt, enthält die Zusammenfassungszeile „failed with 502 Bad Gateway“.

Keine neuen Daten nach Änderungen an Messwertdefinitionen

Sie ändern die Definition eines benutzerdefinierten Messwerts, z. B. indem Sie den Filter ändern, den Sie in einem logbasierten Messwert verwendet haben, und die Benachrichtigungsrichtlinie gibt die von Ihnen an der Messwertdefinition vorgenommene Änderung nicht wieder.

Um dieses Problem zu beheben, erzwingen Sie eine Aktualisierung der Benachrichtigungsrichtlinie. Bearbeiten Sie dazu den Anzeigenamen der Richtlinie.

An Google Chat gesendete Webhook-Benachrichtigungen werden nicht empfangen

Sie konfigurieren einen Webhook-Benachrichtigungskanal in Monitoring und dann den Webhook, um ihn an Google Chat zu senden. Sie erhalten jedoch keine Benachrichtigungen oder es wird der Fehler 400 Bad Request angezeigt.

Zum Beheben dieses Problems konfigurieren Sie einen Pub/Sub-Benachrichtigungskanal in Monitoring und dann einen Cloud Run-Dienst, um die Pub/Sub-Nachrichten in das von Chat erwartete Format zu konvertieren und dann die Benachrichtigung an Google Chat zu senden. Ein Beispiel für diese Konfiguration finden Sie unter Benutzerdefinierte Benachrichtigungen mit Cloud Monitoring und Cloud Run erstellen.

Keine Webhook-Benachrichtigungen erhalten

Sie konfigurieren einen Webhook-Benachrichtigungskanal und erwarten, dass Sie bei Vorfällen benachrichtigt werden. Du erhältst keine Benachrichtigungen.

Privater Endpunkt

Sie können Webhooks nur dann für Benachrichtigungen verwenden, wenn der Endpunkt öffentlich ist.

Verwenden Sie zum Beheben dieses Problems Pub/Sub-Benachrichtigungen in Kombination mit einem Pull-Abo für dieses Benachrichtigungsthema.

Wenn Sie einen Pub/Sub-Benachrichtigungskanal konfigurieren, werden Vorfallbenachrichtigungen an eine Pub/Sub-Warteschlange mit Identitäts- und Zugriffsverwaltungssteuerelementen gesendet. Jeder Dienst, der ein Pub/Sub-Thema abfragen oder überwachen kann, kann diese Benachrichtigungen nutzen. Diese Benachrichtigungen können beispielsweise von Anwendungen genutzt werden, die auf virtuellen Maschinen der App Engine, Cloud Run oder Compute Engine ausgeführt werden.

Wenn Sie ein Pull-Abo verwenden, wird eine Anfrage an Google gesendet, die auf den Eingang einer Nachricht wartet. Diese Abos erfordern Zugriff auf Google, aber keine Regeln für Firewalls oder eingehenden Zugriff.

Öffentlicher Endpunkt

Prüfen Sie Ihre Cloud Logging-Logeinträge auf Informationen zum Fehler, um den Grund für die fehlgeschlagene Zustellung zu ermitteln.

Sie können beispielsweise mit dem Log-Explorer nach Logeinträgen für die Benachrichtigungskanalressource suchen. Dazu nutzen Sie einen Filter wie den folgenden:

resource.type="stackdriver_notification_channel"

Pub/Sub-Benachrichtigungen werden nicht empfangen

Sie konfigurieren einen Pub/Sub-Benachrichtigungskanal, erhalten aber keine Benachrichtigungen.

Versuchen Sie Folgendes, um diese Problem zu beheben:

  • Prüfen Sie, ob das Dienstkonto für Benachrichtigungen vorhanden ist. Wenn das Dienstkonto gelöscht wurde, werden keine Benachrichtigungen gesendet.

    So prüfen Sie, ob das Dienstkonto existiert:

    1. Wählen Sie im Navigationsbereich der Google Cloud Console IAM aus:

      Zu IAM

    2. Suchen Sie nach einem Dienstkonto mit folgender Namenskonvention:

      service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

      Wenn dieses Dienstkonto nicht aufgeführt ist, wählen Sie Von Google bereitgestellte Rollenzuweisungen einschließen aus.

    Wenn das Dienstkonto für Benachrichtigungen nicht vorhanden ist, müssen Sie mit dem Erstellen des Pub/Sub-Benachrichtigungskanals beginnen, damit Monitoring das Dienstkonto erstellen kann:

    1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Benachrichtigungen aus:

      Zu Benachrichtigungen

    2. Klicken Sie auf Edit notification channels (Benachrichtigungskanäle bearbeiten).

    3. Klicken Sie im Abschnitt Cloud Pub/Sub auf Add new (Neu hinzufügen).

      Monitoring erstellt das Dienstkonto für Benachrichtigungen, wenn keines vorhanden ist. Das Dialogfeld Pub/Sub-Kanal erstellen zeigt den Namen des Dienstkontos für Benachrichtigungen an.

    4. Wenn Sie keinen Benachrichtigungskanal hinzufügen möchten, klicken Sie auf Abbrechen. Andernfalls schließen Sie die Erstellung des Benachrichtigungskanals ab und klicken auf Kanal hinzufügen.

    5. Gewähren Sie dem Dienstkonto Berechtigungen zum Veröffentlichen Ihrer Pub/Sub-Themen:

      1. Öffnen Sie das Dokument Benachrichtigungskanal erstellen in einem neuen Browsertab.
      2. Wählen Sie den Tab Pub/Sub aus und folgen Sie der Anleitung im Abschnitt Dienstkonto autorisieren der Seite.

  • Prüfen Sie, ob das Dienstkonto für Benachrichtigungen berechtigt ist, Benachrichtigungen für die jeweiligen Pub/Sub-Themen zu senden.

    Zum Aufrufen der Berechtigungen für ein Dienstkonto können Sie die Google Cloud Console oder den Google Cloud CLI-Befehl verwenden:

    • Auf der Seite IAM in der Google Cloud Console sind die Rollen für jedes Dienstkonto aufgeführt.
    • Auf der Pub/Sub-Seite Themen in der Google Cloud Console werden alle Themen aufgelistet. Wenn Sie ein Thema auswählen, werden auf dem Tab Berechtigungen die Rollen aufgelistet, die Dienstkonten gewährt wurden.

    • Führen Sie den folgenden Google Cloud CLI-Befehl aus, um alle Dienstkonten und ihre Rollen aufzulisten:

      gcloud projects get-iam-policy PROJECT_ID

      Im Folgenden finden Sie eine Teilantwort auf diesen Befehl:

          serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/monitoring.notificationServiceAgent
     - members:
       [...]
       role: roles/owner
     - members:
       - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/pubsub.publisher

      Die Befehlsantwort enthält nur Rollen, keine Autorisierung pro Thema.

    • Führen Sie den folgenden Befehl aus, um die IAM-Bindungen für ein bestimmtes Thema aufzulisten:

      gcloud pubsub topics get-iam-policy TOPIC

      Im Folgenden finden Sie eine Beispielantwort für diesen Befehl:

          bindings:
    - members:
      - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
      role: roles/pubsub.publisher
    etag: BwXPRb5WDPI=
    version: 1

    Informationen zum Autorisieren des Dienstkontos für Benachrichtigungen finden Sie unter Dienstkonto autorisieren.