Pub/Sub in Cloud Monitoring überwachen

Sie können die Google Cloud Console oder die Cloud Monitoring API verwenden, um Pub/Sub zu überwachen.

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

  • Wenn Sie zusätzlich zu Pub/Sub-Messwerten auch Messwerte aus anderen Google Cloud-Ressourcen ansehen möchten, verwenden Sie Monitoring.

  • 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, sollten Sie Folgendes vorbereitet haben:

  • Ein Cloud-Rechnungskonto

  • Ein Pub/Sub-Projekt mit aktivierter Abrechnung

Mithilfe der Kurzanleitung zur Verwendung der Cloud Console können Sie prüfen, ob Sie beide erworben 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 in Bezug auf 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 in der Dashboard-Übersicht ein neues Dashboard oder wählen Sie das vorhandene Pub/Sub-Dashboard aus.

    Wenn Sie nach dem vorhandenen Pub/Sub-Dashboard suchen möchten, wählen Sie im Filter für Alle Dashboards das Attribut Name aus und geben Sie Pub/Sub ein.

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 einen einzelnen Pub/Sub-Messwert mithilfe der Google Cloud Console anzusehen:

  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 als 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 Dokumentation zu Cloud Monitoring.

Pub/Sub-Messwerte und -Ressourcentypen ansehen

Kontingentnutzung überwachen

Im Dashboard „IAM & Verwaltung“ für Kontingente für ein bestimmtes Projekt können Sie sich die aktuellen Kontingente und deren Nutzung ansehen.

Mithilfe der folgenden Messwerte können Sie sich Ihre bisherige Kontingentnutzung 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 Monitoring Query Language-Abfrage löst beispielsweise eine Benachrichtigungsrichtlinie aus, wenn ein Pub/Sub-Kontingent 80% Nutzung überschreitet:

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')

Weitere Informationen zum benutzerdefinierten Monitoring und zu Benachrichtigungen zu Kontingentmesswerten finden Sie unter Kontingentmesswerte verwenden.

Weitere Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

Ein gesundes Abo beibehalten

Um ein fehlerfreies Abo beizubehalten, kannst du mithilfe der von Pub/Sub bereitgestellten Messwerte mehrere Aboattribute im Blick behalten. Sie können beispielsweise die Menge der nicht bestätigten Nachrichten, den Ablauf von Fristen für die Nachrichtenbestätigung usw. überwachen. Sie können auch prüfen, ob Ihr Abo fehlerfrei genug ist, um eine niedrige Latenz bei der Nachrichtenzustellung zu erreichen.

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

Nachrichtenrückstand überwachen

Erstellen Sie ein Dashboard, um sicherzustellen, dass Ihre Abonnenten mit dem Nachrichtenfluss Schritt halten. Das Dashboard kann die folgenden Rückstandsmesswerte, 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 nicht bestätigter 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 nicht akzeptabel.

Häufige Rückstände

Symptome Problem Lösungen
Sowohl oldest_unacked_message_age als auch num_undelivered_messages steigen gemeinsam an. Abonnenten, die mit der Menge an Nachrichten 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 im Code, die verhindern, dass Nachrichten erfolgreich bestätigt oder zeitnah verarbeitet werden können. Siehe Ablauf des Monitoring-Bestätigungstermins.
Wenn es einen konstanten, kleinen Rückstand in Kombination mit einem stetig wachsenden oldest_unacked_message_age gibt, können einige Nachrichten möglicherweise nicht verarbeitet werden. Festgefahrene Nachrichten
  • Prüfen Sie die Anwendungslogs, um festzustellen, ob einige Nachrichten zum Absturz des Codes führen. Es ist unwahrscheinlich – aber möglich –, dass die anstößigen Nachrichten in Pub/Sub statt in Ihrem Client hängen bleiben. Stellen Sie eine Supportanfrage, wenn Sie sicher sind, dass jede Nachricht von Ihrem Code erfolgreich verarbeitet wurde.
  • Wenn einige Nachrichten zum Absturz des Codes führen, sollten Sie diese Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten.
oldest_unacked_message_age überschreitet die Aufbewahrungsdauer für Nachrichten des Abos. Permanenter Datenverlust
  • Richten Sie eine Benachrichtigung ein, die ausgelöst wird, bevor die Nachrichtenaufbewahrungsdauer abgelaufen ist.

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 sich der Nachrichtenrückstand erhöht, können Sie mithilfe des Systemdiagnose-Gebots (subscription/delivery_latency_health_score) prüfen, welche Faktoren zu einer erhöhten Latenz beitragen.

Dieser Messwert misst den Zustand eines einzelnen Abos über ein rollierendes 10-Minuten-Zeitfenster. Der Messwert bietet Einblick in die folgenden Kriterien, die für ein Abo erforderlich sind, um eine konsistente niedrige Latenz zu erreichen:

  • Vernachlässigbare Suchanfragen.

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

  • Vernachlässigbare Fristen für die Bestätigung von Nachrichten sind abgelaufen.

  • Konsistente Bestätigungslatenz von weniger als 30 Sekunden.

  • Konstante geringe Auslastung, was bedeutet, dass das Abo durchgehend genügend Kapazität zum Verarbeiten neuer Nachrichten hat.

Der Messwert Systemdiagnose der Zustellungslatenz gibt einen Wert von 0 oder 1 für jedes der angegebenen Kriterien an. Ein Wert von 1 bedeutet einen fehlerfreien Zustand und ein Wert von 0 einen fehlerhaften Zustand.

  • Suchanfragen: Wenn das Abo in den letzten 10 Minuten Suchanfragen hatte, ist 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 abgespielt werden, wodurch sich die Übermittlungslatenz erhöht.

  • Negativ bestätigte (nackte) Nachrichten: Wenn für das Abo in den letzten 10 Minuten negative Bestätigungsanfragen (Nack-Anfragen) eingegangen sind, wird der Wert auf 0 gesetzt. Eine negative Bestätigung führt dazu, dass eine Nachricht mit einer höheren Bereitstellungslatenz noch einmal zugestellt wird.

  • Abgelaufene Bestätigungsfristen: Wenn für das Abo in den letzten 10 Minuten abgelaufene Bestätigungsfristen aufgetreten sind, wird der Wert auf 0 gesetzt. Nachrichten, deren Bestätigungsfrist abgelaufen ist, werden mit einer erhöhten Zustellungslatenz noch einmal zugestellt.

  • Bestätigungslatenzen: Wenn das 99,9.Perzentil aller Bestätigungslatenzen in den letzten 10 Minuten länger 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. Dieser Wert könnte auf einen Programmfehler oder Ressourceneinschränkungen aufseiten des Abonnentenclients hinweisen.

  • Geringe 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 mehr Streams, damit genügend Kapazität für neue Nachrichten vorhanden ist.

    • Push: Wenn zu viele Nachrichten an Ihren Push-Endpunkt ausstehen, wird der Wert auf 0 gesetzt. Fügen Sie Ihrem Push-Endpunkt mehr Kapazität hinzu, damit Sie Kapazität für neue Nachrichten haben.

    • Pull: Wenn nicht genügend ausstehende Pull-Anfragen vorhanden sind, wird der Wert auf 0 gesetzt. Öffnen Sie weitere gleichzeitige Pull-Anfragen, um sicherzustellen, dass Sie neue Nachrichten empfangen können.

Wenn Sie sich den Messwert ansehen möchten, wählen Sie im Metrics Explorer für den Ressourcentyp des Pub/Sub-Abos den Messwert Status der Lieferlatenz aus. Fügen Sie einen Filter hinzu, um jeweils nur ein Abo auszuwählen. Wählen Sie das gestapelte Flächendiagramm aus und zeigen Sie auf einen bestimmten Zeitpunkt, um die Kriterienbewertungen für das Abo für diesen Zeitpunkt zu prüfen.

Im Folgenden sehen Sie einen Screenshot des Messwerts, der für einen einstündigen Zeitraum in einem gestapelten Flächendiagramm dargestellt wird. Die kombinierte Integritätsbewertung steigt um 4:15 Uhr auf 5 und hat für jedes Kriterium eine Punktzahl von 1. Später sinkt der kombinierte Wert um 4:20 Uhr auf 4, wenn der Auslastungswert auf 0 sinkt.

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

Um die Latenz bei der Nachrichtenzustellung zu reduzieren, erlaubt Pub/Sub Abonnentenclients eine begrenzte Zeit zum Bestätigen (Bestätigen) einer bestimmten Nachricht. Dieser Zeitraum wird als Bestätigungsfrist bezeichnet. Wenn Ihre Abonnenten zu lange brauchen, um Nachrichten zu bestätigen, werden die Nachrichten noch einmal zugestellt, was dazu führt, dass die Abonnenten die Nachrichten doppelt sehen. Diese erneute Übermittlung kann aus verschiedenen Gründen erfolgen:

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

  • Jede Nachricht dauert länger als die Bestätigungsfrist. Cloud-Clientbibliotheken verlängern die Frist für einzelne Nachrichten in der Regel 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 viele Abonnenten die Bestätigungsfrist nicht einhalten. 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 geringe Ablaufrate (z. B. 0,1–1%) fehlerfrei sein.

Nachrichtendurchsatz überwachen

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

Sie können den von Ihren Abonnenten verarbeiteten einzelnen oder nicht Batch-basierten Nachrichtendurchsatz überwachen, indem Sie den Messwert subscription/sent_message_count nach dem Label delivery_type filtern.

Push-Abos überwachen

Überwachen Sie für 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ätigung 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.

    Legen Sie gegebenenfalls eine Benachrichtigung für hohe Fehlerraten fest, da diese Raten zu einer langsamen Bereitstellung und einem wachsenden Rückstand führen. Sie können einen Messwert erstellen, der nach Antwortklasse gefiltert ist. Die Anzahl der Push-Anfragen ist jedoch wahrscheinlich nützlicher, um den wachsenden Umfang und Alter des Rückstands zu untersuchen.

  • subscription/num_outstanding_messages

    Pub/Sub begrenzt im Allgemeinen die Anzahl der ausstehenden Nachrichten. Versuchen Sie in den meisten Situationen,weniger als 1.000 ausstehende Nachrichten zu erhalten. Nachdem der Durchsatz eine Rate in der Größenordnung von 10.000 Nachrichten pro Sekunde erreicht hat, passt der Dienst das Limit für die Anzahl der ausstehenden Nachrichten an. Diese Beschränkung erfolgt in Schritten von 1.000. Es werden keine spezifischen Garantien über den Maximalwert hinaus gegeben. 1.000 ausstehende Nachrichten sind daher ein guter Richtwert.

  • subscription/push_request_latencies

    Dieser Messwert hilft Ihnen, die Antwortlatenzverteilung 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.

Für den Zugriff auf höhere Limits für ausstehende Nachrichten müssen Push-Abonnenten mehr als 99% der empfangenen Nachrichten bestätigen.

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 für ein Abo einen Filter konfigurieren, bestätigt Pub/Sub automatisch Nachrichten, die nicht dem Filter entsprechen. Sie können diese automatische Bestätigung überwachen.

Die Rückstandsmesswerte können Nachrichten enthalten, die nicht dem Filter entsprechen.

Verwenden Sie den Messwert subscription/ack_message_count und setzen Sie das Label delivery_type auf filter, um die Rate der automatisch bestätigten Nachrichten zu beobachten, die nicht dem Filter entsprechen.

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 dem Filter entsprechen. 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 Nachrichten zu unzustellbaren Nachrichten für dieses Abo mithilfe der folgenden Messwerte überwachen:

Einen funktionierenden 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 von wiederholbaren Fehlern (unter 1%) ist kein Grund zur Sorge, da die meisten Cloud-Clientbibliotheken Nachrichtenfehler wiederholen. Untersuchen Sie Fehlerraten, die größer als 1 % sind. 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 in Ihrem Veröffentlichungsclient zu erfassen. Obwohl Clientbibliotheken fehlgeschlagene Anfragen in der Regel wiederholen, garantieren sie keine Veröffentlichung. Unter Nachrichten veröffentlichen wird beschrieben, wie Sie bei Verwendung von Cloud-Clientbibliotheken dauerhafte Veröffentlichungsfehler erkennen können. In Ihrer Publisher-App müssen mindestens dauerhafte Veröffentlichungsfehler protokolliert werden. 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 den folgenden Messwerten können Sie den Nachrichtendurchsatz überwachen, der von Ihren Publishern gesendet wird:

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

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

    Sie können die Anzahl der gesendeten Nachrichten berechnen, indem Sie einen Anzahl-Aggregator auf diesen Messwert anwenden oder die Monitoring Query Language (Monitoring Query Language) verwenden. Mit der folgenden MQL-Abfrage wird ein Diagramm mit der Rate einzelner 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.