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:
Rufen Sie in der Google Cloud Console die Seite Monitoring auf.
Wählen Sie den Namen Ihres Projekts aus, wenn er nicht bereits oben auf der Seite ausgewählt ist.
Klicken Sie im Navigationsmenü auf Dashboards.
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:
Rufen Sie in der Google Cloud Console die Seite Monitoring auf.
Wählen Sie im Navigationsbereich Metrics Explorer aus.
Klicken Sie im Bereich Konfiguration auf Messwert auswählen.
Geben Sie als Filter
Pub/Sub
ein.Wählen Sie unter Aktive Ressourcen die Option Pub/Sub-Abo oder Pub/Sub-Thema aus.
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
Informationen dazu, welche Messwerte Pub/Sub an Cloud Monitoring meldet, finden Sie in der Liste der Pub/Sub-Messwerte in der Cloud Monitoring-Dokumentation.
Die Details zu den überwachten Ressourcentypen
pubsub_topic
,pubsub_subscription
oderpubsub_snapshot
finden Sie in der Cloud Monitoring-Dokumentation unter Überwachte Ressourcentypen.
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:
Nicht bestätigte Nachrichten (
subscription/num_undelivered_messages
), um die Anzahl der nicht bestätigten Nachrichten zu sehen.Alter der ältesten nicht bestätigten Nachricht (
subscription/oldest_unacked_message_age
), um das Alter der ältesten nicht bestätigten Nachricht im Rückstand des Abos zu sehen.Integritätsbewertung der Bereitstellungslatenz (
subscription/delivery_latency_health_score
), um den gesamten Abozustand in Bezug auf die Übermittlungslatenz zu prüfen. Weitere Informationen zu diesem Messwert finden Sie im entsprechenden Abschnitt in diesem Dokument.
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 |
|
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 |
|
oldest_unacked_message_age überschreitet die
Aufbewahrungsdauer für Nachrichten des Abos. |
Permanenter Datenverlust |
|
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.
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:
Pull und StreamingPull:
subscription/expired_ack_deadlines_count
Push:
subscription/push_request_count
gefiltert nachresponse_code != "success"
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:
Pull:
subscription/pull_request_count
. Dieser Messwert kann auch Pull-Anfragen umfassen, die ohne Nachrichten zurückgegeben wurden.StreamingPull:
subscription/streaming_pull_response_count
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
undsubcription_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:
subscription/num_undelivered_messages
- Die Anzahl der weitergeleiteten Nachrichten, die sich im Abo angesammelt haben
subscription/oldest_unacked_message_age
- Das Alter der ältesten weitergeleiteten Nachricht im Abo
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.