Pub/Sub in Cloud Monitoring überwachen

Sie können Pub/Sub mit der Google Cloud Console oder der Cloud Monitoring API überwachen.

In diesem Dokument erfahren Sie, wie Sie die Pub/Sub-Nutzung in der Google Cloud Console mithilfe von Monitoring überwachen.

  • Verwenden Sie Monitoring, wenn Sie zusätzlich zu Pub/Sub-Messwerten Messwerte von anderen Google Cloud-Ressourcen aufrufen möchten.

  • Andernfalls können Sie die in Pub/Sub bereitgestellten Monitoring-Dashboards verwenden. Weitere Informationen finden Sie unter Themen überwachen und Abos überwachen.

Best Practices zur Verwendung von Messwerten beim Autoscaling finden Sie unter Best Practices für die Verwendung von Pub/Sub-Messwerten als Skalierungssignal.

Hinweise

Bevor Sie Monitoring verwenden können, müssen folgende Bedingungen erfüllt sein:

  • Ein Cloud-Rechnungskonto

  • Ein Pub/Sub-Projekt mit aktivierter Abrechnung

Mit der Kurzanleitung zur Verwendung der Cloud Console können Sie beispielsweise prüfen, ob Sie beides erhalten haben.

Vorhandenes Dashboard ansehen

Mit einem Dashboard können Sie Daten aus verschiedenen Quellen im selben Kontext ansehen und analysieren. Google Cloud bietet sowohl vordefinierte als auch benutzerdefinierte Dashboards. Sie können beispielsweise ein vordefiniertes Pub/Sub-Dashboard aufrufen oder ein benutzerdefiniertes Dashboard erstellen, das Messwertdaten, Benachrichtigungsrichtlinien und Logeinträge zu Pub/Sub anzeigt.

Führen Sie die folgenden Schritte aus, um Ihr Pub/Sub-Projekt mit Cloud Monitoring zu überwachen:

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie den Namen Ihres Projekts aus, wenn er nicht bereits oben auf der Seite ausgewählt ist.

  3. Klicken Sie im Navigationsmenü auf Dashboards.

  4. Erstellen Sie auf der Seite Dashboard-Übersicht ein neues Dashboard oder wählen Sie das vorhandene Pub/Sub-Dashboard aus.

    Wählen Sie im Filter Alle Dashboards das Attribut Name aus und geben Sie Pub/Sub ein, um nach dem vorhandenen Pub/Sub-Dashboard zu suchen.

Weitere Informationen zum Erstellen, Bearbeiten und Verwalten eines benutzerdefinierten Dashboards finden Sie unter Benutzerdefinierte Dashboards verwalten.

Einzelnen Pub/Sub-Messwert ansehen

Führen Sie die folgenden Schritte aus, um mit der Google Cloud Console einen einzelnen Pub/Sub-Messwert aufzurufen:

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie im Navigationsbereich Metrics Explorer aus.

  3. Klicken Sie im Bereich Konfiguration auf Messwert auswählen.

  4. Geben Sie im Filter Pub/Sub ein.

  5. Wählen Sie unter Aktive Ressourcen die Option Pub/Sub-Abo oder Pub/Sub-Thema aus.

  6. Rufen Sie einen bestimmten Messwert auf und klicken Sie auf Übernehmen.

    Die Seite für einen bestimmten Messwert wird geöffnet.

Weitere Informationen zum Monitoring-Dashboard finden Sie in der Cloud Monitoring-Dokumentation.

Pub/Sub-Messwerte und -Ressourcentypen ansehen

Kontingentnutzung überwachen

Die aktuellen Kontingente eines Projekts und deren Nutzung können Sie im Dashboard „IAM & Verwaltung“ für Kontingente einsehen.

Sie können Ihre bisherige Kontingentnutzung anhand der folgenden Messwerte ansehen:

Bei diesen Messwerten wird der überwachte Ressourcentyp consumer_quota verwendet. Weitere kontingentbezogene Messwerte finden Sie in der Messwertliste.

Die folgende Abfrage Monitoring Query Language erstellt beispielsweise ein Diagramm mit dem Anteil des Publisher-Kontingents, das in jeder Region verwendet wird:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

Wenn Sie davon ausgehen, dass Ihre Nutzung die Standardkontingentlimits überschreitet, erstellen Sie Benachrichtigungsrichtlinien für alle relevanten Kontingente. Diese Benachrichtigungen werden ausgelöst, wenn Ihre Nutzung einen Bruchteil des Limits erreicht. Die folgende Abfrage in der Monitoring Query Language löst beispielsweise eine Benachrichtigungsrichtlinie aus, wenn ein Pub/Sub-Kontingent mehr als 80% genutzt wird:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

Unter Kontingentmesswerte verwenden finden Sie Informationen zur benutzerdefinierten Überwachung und Benachrichtigung zu Kontingentmesswerten.

Weitere Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

Ein funktionierendes Abo beibehalten

Sie können mithilfe von Pub/Sub-Messwerten mehrere Aboattribute überwachen, um ein fehlerfreies Abo aufrechtzuerhalten. Sie können beispielsweise die Menge der nicht bestätigten Nachrichten, den Ablauf von Bestätigungsfristen für Nachrichten usw. überwachen. Sie können auch prüfen, ob Ihr Abo fehlerfrei genug ist, um eine niedrige Latenz der Nachrichtenzustellung zu erreichen.

In den nächsten Abschnitten finden Sie weitere Informationen zu den jeweiligen Messwerten.

Nachrichtenrückstand überwachen

Erstellen Sie ein Dashboard, damit Ihre Abonnenten über den Nachrichtenfluss auf dem Laufenden bleiben. Das Dashboard kann die folgenden Backlog-Messwerte, zusammengefasst nach Ressource, für alle Ihre Abos anzeigen:

Erstellen Sie Benachrichtigungsrichtlinien, die ausgelöst werden, wenn diese Werte im Kontext Ihres Systems außerhalb des zulässigen Bereichs liegen. Beispielsweise ist die absolute Anzahl der nicht bestätigten Nachrichten nicht unbedingt aussagekräftig. Ein Rückstand von einer Million Nachrichten kann für ein Abo mit einer Million Nachrichten pro Sekunde akzeptabel sein, für ein Abo mit einer Nachricht pro Sekunde jedoch inakzeptabel.

Häufige Backlog-Probleme

Symptome Problem Lösungen
Sowohl oldest_unacked_message_age als auch num_undelivered_messages steigen gemeinsam an. Abonnenten werden mit dem Nachrichtenvolumen nicht Schritt halten
  • Fügen Sie weitere Abonnententhreads oder -prozesse hinzu.
  • Fügen Sie weitere Abonnentenmaschinen oder Container hinzu.
  • Suchen Sie nach Anzeichen von Fehlern in Ihrem Code, die verhindern, dass Nachrichten erfolgreich bestätigt oder zeitnah verarbeitet werden. Siehe Ablauf der Bestätigungsfrist überwachen.
Wenn es einen konstanten, kleinen Rückstand in Kombination mit einem stetig wachsenden oldest_unacked_message_age gibt, gibt es möglicherweise einige Nachrichten, die nicht verarbeitet werden können. Festgefahrene Nachrichten
  • Prüfen Sie die Anwendungslogs, um festzustellen, ob einige Nachrichten den Code zum Absturz bringen. Es ist unwahrscheinlich – aber möglich –, dass die anstößigen Nachrichten in Pub/Sub und nicht in Ihrem Client hängen bleiben. Stellen Sie eine Supportanfrage, wenn Sie sicher sind, dass Ihr Code jede Nachricht erfolgreich verarbeitet.
  • Wenn einige Nachrichten zum Absturz Ihres Codes führen, sollten Sie diese Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten.
Die oldest_unacked_message_age überschreitet die Aufbewahrungsdauer für Nachrichten des Abos. Permanenter Datenverlust
  • Richten Sie eine Benachrichtigung ein, die vor Ablauf der Nachrichtenaufbewahrungsdauer ausgelöst wird.

Zustand der Bereitstellungslatenz überwachen

In Pub/Sub ist die Zustellungslatenz die Zeit, die benötigt wird, bis eine veröffentlichte Nachricht an einen Abonnenten zugestellt wird. Wenn der Nachrichtenrückstand ansteigt, können Sie anhand des Systemdiagnosewerts für die Bereitstellungslatenz (subscription/delivery_latency_health_score) ermitteln, welche Faktoren zu einer erhöhten Latenz beitragen.

Dieser Messwert misst den Status eines einzelnen Abos über einen zusammenhängenden Zeitraum von 10 Minuten. Der Messwert gibt Aufschluss über die folgenden Kriterien, die für ein Abo erforderlich sind, um eine konstant niedrige Latenz zu erreichen:

  • Vernachlässigbare Suchanfragen.

  • Vernachlässigbare, negativ bestätigte Nachrichten (Nackt).

  • Vernachlässigbare abgelaufene Fristen für die Nachrichtenbestätigung.

  • Die Latenz für die kontinuierliche Bestätigung beträgt weniger als 30 Sekunden.

  • Eine konstant niedrige Auslastung, d. h., das Abo hat immer ausreichend Kapazität, um neue Nachrichten zu verarbeiten.

Der Messwert Integritätsbewertung der Bereitstellungslatenz meldet für jedes der angegebenen Kriterien eine Punktzahl von 0 oder 1. Ein Wert von 1 bedeutet einen fehlerfreien Zustand, ein Wert von 0 einen fehlerhaften Zustand.

  • Suchanfragen: Wenn für das Abo in den letzten 10 Minuten Suchanfragen aufgetreten sind, wird der Wert auf 0 gesetzt. Die Suche nach einem Abo kann dazu führen, dass alte Nachrichten lange nach ihrer ersten Veröffentlichung noch einmal wiedergegeben werden. Dies erhöht die Zustellungslatenz.

  • Negativ bestätigte Nachrichten (ohne Bestätigung): Wenn das Abo in den letzten 10 Minuten negative Bestätigungsanfragen (Nack) erhalten hat, wird der Wert auf 0 gesetzt. Eine negative Bestätigung führt dazu, dass eine Nachricht mit einer erhöhten Zustellungslatenz noch einmal gesendet wird.

  • Abgelaufene Bestätigungsfristen: Wenn für das Abo in den letzten 10 Minuten Bestätigungsfristen abgelaufen sind, wird die Punktzahl auf 0 gesetzt. Nachrichten, deren Bestätigungsfrist abgelaufen ist, werden mit einer höheren Zustellungslatenz noch einmal gesendet.

  • Bestätigungslatenzen: Wenn das 99,9.Perzentil aller Bestätigungslatenzen in den letzten 10 Minuten jemals größer als 30 Sekunden war, wird der Wert auf 0 gesetzt. Eine hohe Bestätigungslatenz ist ein Zeichen dafür, dass ein Abonnentenclient ungewöhnlich lange für die Verarbeitung einer Nachricht benötigt. Diese Punktzahl könnte auf einen Fehler oder Ressourceneinschränkungen auf der Abonnentenclientseite hindeuten.

  • Niedrige Auslastung: Die Auslastung wird für jeden Abotyp unterschiedlich berechnet.

    • StreamingPull: Wenn nicht genügend Streams geöffnet sind, wird der Wert auf 0 gesetzt. Öffnen Sie weitere Streams, damit Sie genügend Kapazität für neue Nachrichten haben.

    • Push: Wenn zu viele Nachrichten an Ihren Push-Endpunkt gesendet werden, wird der Wert auf 0 gesetzt. Erhöhen Sie die Kapazität Ihres Push-Endpunkts, damit Sie Kapazitäten für neue Nachrichten haben.

    • Pull: Wenn nicht genügend ausstehende Pull-Anfragen vorhanden sind, wird der Wert auf 0 gesetzt. Öffnen Sie mehrere gleichzeitige Pull-Anfragen, um sicherzustellen, dass Sie für den Empfang neuer Nachrichten bereit sind.

Wählen Sie zum Aufrufen des Messwerts im Metrics Explorer den Messwert Leistungsbewertung der Bereitstellungslatenz für den Ressourcentyp des Pub/Sub-Abos aus. Fügen Sie einen Filter hinzu, um jeweils nur ein Abo auszuwählen. Wählen Sie das gestapelte Flächendiagramm aus und bewegen Sie den Mauszeiger auf einen bestimmten Zeitpunkt, um die Kriterien für das Abo für diesen Zeitpunkt zu prüfen.

Im Folgenden sehen Sie einen Screenshot des Messwerts, der mit einem gestapelten Flächendiagramm für einen Zeitraum von einer Stunde dargestellt wird. Die kombinierte Integritätsbewertung liegt um 04:15 Uhr bei 5, wobei für jedes Kriterium ein Wert von 1 gilt. Später sinkt der kombinierte Wert um 4:20 Uhr auf 4, wenn der Auslastungswert auf 0 fällt.

Screenshot des Messwerts für die Bereitstellungslatenz

Monitoring Query Language bietet eine wirkungsvolle, textbasierte Schnittstelle für Cloud Monitoring-Zeitreihendaten. Mit der folgenden MQL-Abfrage wird ein Diagramm erstellt, um die Integritätsbewertung der Bereitstellungslatenz für ein Abo zu messen.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

Ablauf der Bestätigungsfrist überwachen

Pub/Sub ermöglicht Abonnentenclients eine begrenzte Zeit, um eine bestimmte Nachricht zu bestätigen, um die Latenz bei der Nachrichtenzustellung zu reduzieren. Dieser Zeitraum wird als Bestätigungsfrist bezeichnet. Wenn Ihre Abonnenten zu lange brauchen, um Nachrichten zu bestätigen, werden die Nachrichten noch einmal zugestellt, wodurch den Abonnenten doppelte Nachrichten angezeigt werden. Dafür kann es verschiedene Gründe geben:

  • Die Abonnenten sind unzureichend versorgt, Sie benötigen mehr Threads oder Rechner..

  • Die Verarbeitung jeder Nachricht dauert länger als das Zeitlimit für die Nachrichtenbestätigung. Cloud-Clientbibliotheken verlängern in der Regel die Frist für einzelne Nachrichten bis zu einem konfigurierbaren Maximum. Für die Bibliotheken gilt jedoch auch eine Fristverlängerung.

  • Einige Nachrichten führen regelmäßig zu einem Absturz des Clients.

Sie können messen, wie oft Abonnenten die Bestätigungsfrist verpassen. Der genaue Messwert hängt vom Abotyp ab:

Eine zu hohe Ablauffrist für Bestätigungszeiträume kann zu teuren Ineffizienzen in Ihrem System führen. Sie zahlen für jede erneute Zustellung und für den Versuch, jede Nachricht wiederholt zu verarbeiten. Umgekehrt kann eine kleine Ablaufrate (z. B. 0,1–1%) fehlerfrei sein.

Nachrichtendurchsatz überwachen

Pull- und StreamingPull-Abonnenten können in jeder Pull-Antwort Batches von Nachrichten erhalten. Push-Abos erhalten in jeder Push-Anfrage eine einzelne Nachricht. Mit den folgenden Messwerten können Sie den Batch-Nachrichtendurchsatz, der von Ihren Abonnenten verarbeitet wird, überwachen:

Mit dem nach dem Label delivery_type gefilterten Messwert subscription/sent_message_count können Sie den Durchsatz von einzelnen oder nicht zusammengefassten Nachrichten überwachen, der von Ihren Abonnenten verarbeitet wird.

Push-Abos im Blick behalten

Überwachen Sie bei Push-Abos die folgenden Messwerte:

  • subscription/push_request_count

    Gruppieren Sie den Messwert nach response_code und subcription_id. Da Pub/Sub-Push-Abos Antwortcodes als implizite Nachrichtenbestätigungen verwenden, ist es wichtig, die Antwortcodes von Push-Anfragen zu überwachen. Da Push-Abos exponentiell zurückgehen, wenn Zeitüberschreitungen oder Fehler auftreten, kann Ihr Rückstand schnell wachsen, je nachdem, wie Ihr Endpunkt reagiert.

    Erwägen Sie, eine Warnung für hohe Fehlerraten einzurichten, da diese zu einer langsamen Bereitstellung und einem wachsenden Rückstand führen. Sie können einen nach Antwortklasse gefilterten Messwert erstellen. Die Anzahl der Push-Anfragen ist jedoch wahrscheinlich nützlicher, um die wachsende Größe und das Alter des Rückstands zu untersuchen.

  • subscription/num_outstanding_messages

    Pub/Sub begrenzt im Allgemeinen die Anzahl der ausstehenden Nachrichten. In den meisten Fällen sollten Sie weniger als 1.000 ausstehende Nachrichten anstreben. Nachdem der Durchsatz eine Rate von 10.000 Nachrichten pro Sekunde erreicht hat, passt der Dienst das Limit für die Anzahl der ausstehenden Nachrichten an. Diese Einschränkung erfolgt in Schritten von 1.000. Es werden keine spezifischen Garantien über den Maximalwert hinaus gegeben, daher sind 1.000 ausstehende Nachrichten ein guter Anhaltspunkt.

  • subscription/push_request_latencies

    Dieser Messwert hilft Ihnen, die Verteilung der Antwortlatenz des Push-Endpunkts zu verstehen. Da die Anzahl der ausstehenden Nachrichten begrenzt ist, wirkt sich die Endpunktlatenz auf den Abodurchsatz aus. Wenn die Verarbeitung jeder Nachricht 100 Millisekunden dauert, liegt Ihr Durchsatzlimit bei zehn Nachrichten pro Sekunde.

Push-Abonnenten müssen mehr als 99% der empfangenen Nachrichten bestätigen, um auf höhere Limits für ausstehende Nachrichten zugreifen zu können.

Sie können den Anteil der Nachrichten, die Abonnenten bestätigen, mithilfe der Monitoring Query Language berechnen. Die folgende MQL-Abfrage erstellt ein Diagramm mit dem Anteil der Nachrichten, die Abonnenten für ein Abo bestätigen:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

Abos mit Filtern im Blick behalten

Wenn Sie einen Filter für ein Abo konfigurieren, bestätigt Pub/Sub Nachrichten, die nicht mit dem Filter übereinstimmen, automatisch. Sie können diese automatische Bestätigung überwachen.

Die Rückstandsmesswerte enthalten nur Nachrichten, die dem Filter entsprechen.

Wenn Sie die Rate automatisch bestätigter Nachrichten überwachen möchten, die nicht dem Filter entsprechen, verwenden Sie den Messwert subscription/ack_message_count und setzen Sie das Label delivery_type auf filter.

Verwenden Sie den Messwert subscription/byte_cost und setzen Sie das Label operation_type auf filter_drop, um den Durchsatz und die Kosten von automatisch bestätigten Nachrichten zu überwachen, die nicht mit dem Filter übereinstimmen. Weitere Informationen zu den Gebühren für diese Nachrichten finden Sie auf der Seite Pub/Sub – Preise.

Weitergeleitete nicht zustellbare Nachrichten überwachen

Verwenden Sie den Messwert subscription/dead_letter_message_count, um nicht zustellbare Nachrichten zu überwachen, die Pub/Sub an ein Thema für unzustellbare Nachrichten weiterleitet. Dieser Messwert zeigt die Anzahl der nicht zustellbaren Nachrichten, die Pub/Sub von einem Abo weiterleitet.

Wenn Sie prüfen möchten, ob Pub/Sub nicht zustellbare Nachrichten weiterleitet, können Sie den Messwert subscription/dead_letter_message_count mit dem Messwert topic/send_request_count vergleichen. Führen Sie den Vergleich für das Thema für unzustellbare Nachrichten durch, an das Pub/Sub diese Nachrichten weiterleitet.

Sie können auch ein Abo an das Thema für unzustellbare Nachrichten anhängen und dann die weitergeleiteten, nicht zustellbaren Nachrichten für dieses Abo mithilfe der folgenden Messwerte überwachen:

Einen fehlerfreien Publisher aufrechterhalten

Das primäre Ziel eines Publishers besteht darin, Nachrichtendaten schnell zu speichern. Beobachten Sie diese Leistung mit topic/send_request_count, gruppiert nach response_code. Dieser Messwert gibt an, ob Pub/Sub fehlerfrei ist und Anfragen akzeptiert.

Eine Hintergrundrate wiederholbarer Fehler (unter 1%) ist kein Grund zur Besorgnis, da die meisten Cloud-Clientbibliotheken Nachrichtenfehler wiederholen. Untersuchen Sie Fehlerraten über 1%. Da nicht wiederholbare Codes von Ihrer Anwendung (und nicht von der Clientbibliothek) verarbeitet werden, sollten Sie Antwortcodes untersuchen. Wenn Ihre Publisher-Anwendung keine gute Möglichkeit hat, einen fehlerhaften Status zu melden, sollten Sie eine Warnung für den Messwert topic/send_request_count festlegen.

Ebenso wichtig ist es, fehlgeschlagene Veröffentlichungsanfragen im Publish-Client zu verfolgen. Obwohl Clientbibliotheken fehlgeschlagene Anfragen in der Regel wiederholen, garantieren sie keine Veröffentlichung. Unter Nachrichten veröffentlichen erfahren Sie, wie Sie bei der Verwendung von Cloud-Clientbibliotheken dauerhafte Veröffentlichungsfehler erkennen können. Ihre Publisher-App muss zumindest dauerhafte Veröffentlichungsfehler protokollieren. Wenn Sie diese Fehler in Cloud Logging protokollieren, können Sie einen logbasierten Messwert mit einer Benachrichtigungsrichtlinie einrichten.

Nachrichtendurchsatz überwachen

Publisher können Nachrichten in Batches senden. Mit diesen Messwerten können Sie den von Ihren Publishern gesendeten Nachrichtendurchsatz überwachen:

  • topic/send_request_count: die Menge der Batchnachrichten, die von Publishern gesendet werden.

  • Anzahl von topic/message_sizes: die Menge einzelner (nicht in Batches) Nachrichten, die von Publishern gesendet werden.

    Sie können die Anzahl der gesendeten Nachrichten berechnen, indem Sie einen Zähler-Aggregator auf diesen Messwert anwenden oder die Monitoring Query Language verwenden. Mit der folgenden MQL-Abfrage wird ein Diagramm mit dem Anteil der einzelnen Nachrichten erstellt, die zu einem Thema gesendet wurden:

    fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter
    (resource.topic_id == '$TOPIC')
| align delta(1m)
| every 1m
| group_by [], [row_count: row_count()]

Nächste Schritte

  • Informationen zum Erstellen einer Benachrichtigung für einen bestimmten Messwert finden Sie unter Messwertbasierte Benachrichtigungsrichtlinien verwalten.

  • Weitere Informationen zur Verwendung von MQL zum Erstellen von Monitoring-Diagrammen finden Sie unter Abfrageeditor verwenden.

  • Weitere Informationen zu API-Ressourcen für die Monitoring API, z. B. Messwerte, überwachte Ressourcen, Gruppen von überwachten Ressourcen und Benachrichtigungsrichtlinien, finden Sie unter API-Ressourcen.