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.

• Wenn Sie neben Pub/Sub-Messwerten auch Messwerte anderer Google Cloud-Ressourcen aufrufen möchten, verwenden Sie Monitoring.

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

Best Practices für die Verwendung von Messwerten bei der automatischen Skalierung finden Sie unter Best Practices für die Verwendung von Pub/Sub-Messwerten als Skalierungssignal.

Hinweise

Für die Verwendung von Monitoring müssen Sie Folgendes vorbereiten:

• Ein Cloud-Rechnungskonto

• Ein Pub/Sub-Projekt mit aktivierter Abrechnung

Wenn Sie die Kurzanleitung zur Verwendung der Cloud Console abschließen, haben Sie beides.

Vorhandenes Dashboard aufrufen

Auf 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 sich beispielsweise ein vordefiniertes Pub/Sub-Dashboard ansehen oder ein benutzerdefiniertes Dashboard erstellen, das Messdaten, Benachrichtigungsrichtlinien und Logeinträge zu Pub/Sub enthält.

So überwachen Sie Ihr Pub/Sub-Projekt mit Cloud Monitoring:

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.

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

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

Einzelnen Pub/Sub-Messwert aufrufen

So rufen Sie einen einzelnen Pub/Sub-Messwert in der Google Cloud Console auf:

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 aufrufen

• Welche Messwerte Pub/Sub an Cloud Monitoring meldet, sehen Sie in der Pub/Sub-Messwertliste in der Cloud Monitoring-Dokumentation.

• Wenn Sie sich die Details der überwachten Ressourcentypen pubsub_topic, pubsub_subscription oder pubsub_snapshot ansehen möchten, rufen Sie Überwachte Ressourcentypen in der Cloud Monitoring-Dokumentation auf.

Auf den MQL-Editor zugreifen

Der Metrics Explorer ist eine Oberfläche in Cloud Monitoring, mit der Sie Messwertdaten untersuchen und visualisieren können. Im Metrics Explorer können Sie mit der Monitoring Query Language(MQL) Ihre Pub/Sub-Messwerte abfragen und analysieren.

Informationen zum Zugriff auf den MQL-Editor bei Verwendung des Metrics Explorers finden Sie unter Auf den Codeeditor zugreifen.

MQL-Abfrage erstellen

Im Folgenden finden Sie einige grundlegende Regeln für die Erstellung einer MQL-Abfrage für Pub/Sub-Messwerte.

1. Er beginnt mit fetch pubsub_topic oder fetch pubsub_subscription. Diese Codezeile gibt dem Editor an, welche Art von Pub/Sub-Ressource abgefragt werden soll, z. B. Themen oder Abos.

2. Wählen Sie den Messwert aus. Verwenden Sie | metric 'metric_name', um den Messwert anzugeben, den Sie analysieren möchten. Ein Beispiel für einen Pub/Sub-Messwert ist pubsub.googleapis.com/subscription/ack_message_count (für bestätigte Nachrichten).

3. Mit | filter können Sie die Daten eingrenzen. Zu den gängigen Filtern gehören:

   • resource.project_id == 'your-project-id'
   • resource.topic_id == 'your-topic-id'
   • resource.subscription_id == 'your-subscription-id'

4. Mit | align und | group_by können Sie Ihre Daten in aussagekräftige Intervalle und Gruppierungen aggregieren.

5. Daten mit anderen Klauseln verfeinern MQL bietet unter anderem die Klauseln | every (zum Festlegen der Häufigkeit der Abfrageausführung) und | within (zum Angeben eines Zeitraums).

Hier ist eine Beispielabfrage, mit der die stündliche Anzahl der an ein bestimmtes Abo gesendeten Nachrichten überwacht wird:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Kontingentnutzung überwachen

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

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

• serviceruntime.googleapis.com/quota/rate/net_usage
• serviceruntime.googleapis.com/quota/limit

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

Die folgende MQL-Abfrage 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 bestimmten Teil des Limits erreicht. Die folgende Abfrage in Monitoring Query Language löst beispielsweise eine Benachrichtigungsrichtlinie aus, wenn ein Pub/Sub-Kontingent die Nutzung von 80% ü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 Benachrichtigungen zu Kontingentmesswerten finden Sie unter Kontingentmesswerte verwenden.

Weitere Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

Ein gesundes Abo

Um ein fehlerfreies Abo zu gewährleisten, können Sie mehrere Aboeigenschaften mithilfe von Pub/Sub-Messwerten überwachen. Sie können beispielsweise das Volumen nicht bestätigter Nachrichten oder den Ablauf von Bestätigungsfristen für Nachrichten überwachen. Sie können auch prüfen, ob Ihr Abo fehlerfrei ist, um eine niedrige Latenz der Nachrichtenzustellung zu erreichen.

Weitere Informationen zu den einzelnen Messwerten finden Sie in den folgenden Abschnitten.

Nachrichtenrückstau beobachten

Um sicherzustellen, dass Ihre Abonnenten mit dem Nachrichtenfluss Schritt halten, erstellen Sie ein Dashboard. Das Dashboard kann die folgenden Rückstands-Messwerte, nach Ressource zusammengefasst, für alle Ihre Abos enthalten:

• „Unbestätigte Nachrichten“ (subscription/num_undelivered_messages), um die Anzahl der unbestä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 anzuzeigen.

• Integritätbewertung für Zustellungslatenz (subscription/delivery_latency_health_score): Hiermit wird die allgemeine Zuverlässigkeit des Abos im Hinblick auf die Zustellungslatenz geprüft. Weitere Informationen zu diesem Messwert finden Sie 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 der nicht bestätigten Nachrichten nicht unbedingt aussagekräftig. Ein Rückstau von einer Million Nachrichten ist für ein Abo mit einer Nachrichtenanzahl von einer Million pro Sekunde akzeptabel, für ein Abo mit einer Nachrichten pro Sekunde jedoch inakzeptabel.

Häufige Probleme mit dem Backlog

Integrität der Zustellungslatenz überwachen

In Pub/Sub ist die Übermittlungslatenz die Zeit, die vergeht, bis eine veröffentlichte Nachricht an einen Abonnenten zugestellt wird. Wenn sich der Nachrichtenrückstau erhöht, können Sie mit dem Bewertungsmesswert für die Bereitstellungslatenz (subscription/delivery_latency_health_score) prüfen, welche Faktoren zu einer erhöhten Latenz beitragen.

Dieser Messwert gibt Aufschluss über den Zustand eines einzelnen Abos in einem rollierenden 10-Minuten-Zeitraum. Der Messwert gibt Aufschluss über die folgenden Kriterien, die für ein Abo erforderlich sind, um eine konstant niedrige Latenz zu erreichen:

• Geringfügige Suchanfragen.

• Negligible negatively acknowledged messages (nacked) messages.

• Unzureichende Fristen für die Bestätigung abgelaufener Nachrichten

• Die Bestätigungslatenz muss konstant unter 30 Sekunden liegen.

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

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

• Suchanfragen: Wenn für das Abo in den letzten 10 Minuten Suchanfragen gesendet wurden, wird die Bewertung auf 0 gesetzt. Wenn Sie nach einem Abo suchen, werden möglicherweise alte Nachrichten noch lange nach ihrer Veröffentlichung noch einmal abgespielt. Dadurch erhöht sich die Zustellungslatenz.

• Negativ bestätigte Nachrichten: Wenn für das Abo in den letzten 10 Minuten negative Bestätigungsanfragen (NACK) gesendet wurden, wird die Bewertung 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 abgelaufene Bestätigungsfristen aufgetreten sind, wird die Bewertung auf 0 gesetzt. Nachrichten, deren Bestätigungsfrist abgelaufen ist, werden mit einer erhöhten Zustellungslatenz noch einmal zugestellt.

• Bestätigungslatenzen: Wenn der 99,9-Perzentilwert aller Bestätigungslatenzen der letzten 10 Minuten jemals mehr als 30 Sekunden betrug, wird die Bewertung 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 kann auf einen Fehler oder Ressourceneinschränkungen auf der Abonnentenseite 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, um für ausreichend Kapazität für neue Nachrichten zu sorgen.

  • Push: Wenn zu viele Nachrichten an Ihren Push-Endpunkt ausstehen, wird die Bewertung auf 0 gesetzt. Erhöhen Sie die Kapazität Ihres Push-Endpunkts, damit Sie genügend Kapazität für neue Nachrichten haben.

  • Pull: Wenn Sie nicht genügend ausstehende Pull-Anfragen haben, wird die Punktzahl auf 0 gesetzt. Öffnen Sie mehrere gleichzeitige Pull-Anfragen, damit Sie neue Nachrichten erhalten können.

Wenn Sie sich den Messwert ansehen möchten, wählen Sie im Metrics Explorer den Messwert Gesundheitsbewertung der Übermittlungslatenz für den Pub/Sub-Abo-Ressourcentyp aus. Fügen Sie einen Filter hinzu, um jeweils nur ein Abo auszuwählen. Wählen Sie das Stapeldiagramm aus und bewegen Sie den Mauszeiger auf einen bestimmten Zeitpunkt, um die Kriterienbewertungen für das Abo zu diesem Zeitpunkt zu sehen.

Im folgenden Screenshot ist der Messwert für einen Zeitraum von einer Stunde in einem gestapelten Flächendiagramm dargestellt. Der kombinierte Wert für den Zustand steigt um 4:15 Uhr auf 5, wobei jedes Kriterium mit 1 bewertet wird. Später, um 4:20 Uhr, sinkt der kombinierte Wert auf 4, da der Auslastungswert auf 0 fällt.

Die Monitoring Query Language bietet eine ausdrucksstarke, textbasierte Schnittstelle zu Cloud Monitoring-Zeitachsendaten. Mit der folgenden MQL-Abfrage wird ein Diagramm erstellt, mit dem die Integritätbewertung für die Zustellungslatenz für ein Abo gemessen wird.

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 der Nachrichtenübermittlung zu reduzieren, erlaubt Pub/Sub Abonnenten-Clients eine begrenzte Zeit, um eine bestimmte Nachricht zu bestätigen. Dieser Zeitraum wird als ACK-Frist bezeichnet. Wenn es zu lange dauert, bis Ihre Abonnenten Nachrichten bestätigen, werden die Nachrichten noch einmal zugestellt, sodass die Abonnenten Nachrichten doppelt sehen. Das kann verschiedene Gründe haben:

• 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 im Allgemeinen die Frist für einzelne Nachrichten auf ein konfigurierbares 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 die Rate messen, bei der Abonnenten die Bestätigungsfrist verpassen. Der genaue Messwert hängt vom Abotyp ab:

• Pull und StreamingPull: subscription/expired_ack_deadlines_count

• Push:subscription/push_request_count gefiltert nach response_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 können in jeder Pull-Antwort Batches von Nachrichten erhalten. Bei Push-Abos wird in jeder Push-Anfrage eine einzelne Nachricht empfangen. Mit diesen Messwerten können Sie den Batch-Nachrichtendurchsatz überwachen, der von Ihren Abonnenten verarbeitet wird:

• Pull: subscription/pull_request_count (Hinweis: Dieser Messwert kann auch Pull-Anfragen enthalten, die ohne Nachrichten zurückgegeben wurden.)

• StreamingPull: subscription/streaming_pull_response_count

Sie können den einzelnen oder nicht gruppierten Nachrichtendurchsatz, der von Ihren Abonnenten verarbeitet wird, mit dem Messwert subscription/sent_message_count überwachen, der nach dem Label delivery_type gefiltert wird.

Die folgende MQL-Abfrage liefert ein Zeitreihendiagramm mit der Gesamtzahl der Nachrichten, die alle 10 Minuten an ein bestimmtes Pub/Sub-Abo gesendet wurden. Ersetzen Sie die Platzhalterwerte für $PROJECT_NAME und $SUBSCRIPTION_NAME durch die tatsächlichen Projekt- und Themen-IDs.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Push-Abos beobachten

Bei Push-Abos sollten Sie diese Messwerte beobachten:

• 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, Antwortcodes für Push-Anfragen zu beobachten. Da Push-Abos exponentiell zurückgehen, wenn Zeitüberschreitungen oder Fehler auftreten, kann Ihr Rückstand schnell wachsen, je nachdem, wie Ihr Endpunkt reagiert.

  Sie sollten eine Warnung für hohe Fehlerraten einrichten, da diese Raten zu einer langsameren Zustellung 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 ein nützlicheres Tool, um die wachsenden Rückstände und das Alter 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. Sobald der Durchsatz eine Rate von etwa 10.000 Nachrichten pro Sekunde erreicht, passt der Dienst das Limit für die Anzahl der ausstehenden Nachrichten an. Diese Einschränkung erfolgt in Schritten von 1.000. Es gibt keine spezifischen Garantien, die über den Maximalwert hinausgehen. Daher ist 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.

Um auf höhere ausstehende Nachrichtenbeschränkungen zuzugreifen, 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 beobachten

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

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

Verwenden Sie den Messwert subscription/ack_message_count mit dem Label delivery_type = filter, um die Rate der automatisch bestätigten Nachrichten zu beobachten, die nicht mit dem Filter übereinstimmen.

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

Weitergeleitete unzustellbare Nachrichten beobachten

Verwenden Sie den Messwert subscription/dead_letter_message_count, um nicht zustellbare Nachrichten zu beobachten, 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 ein Abo auch an das Thema für unzustellbare Nachrichten anhängen und dann die weitergeleiteten nicht zustellbaren Nachrichten mithilfe der folgenden Messwerte überwachen:

• subscription/num_undelivered_messages

  die Anzahl der weitergeleiteten Nachrichten, die im Abo angesammelt wurden

• subscription/oldest_unacked_message_age

  das Alter der ältesten weitergeleiteten Nachricht im Abo

Publisher fehlerfrei halten

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 fehlerhafte Nachrichten wiederholen. Prüfen Sie Fehlerraten, die über 1 % liegen. 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 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 dauerhafte Veröffentlichungsfehler bei der Verwendung von Cloud-Clientbibliotheken erkennen. Ihre Publisher-Anwendung muss zumindest die permanenten 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. Sie können den von Ihren Publishern gesendeten Nachrichtendurchsatz mit den folgenden Messwerten überwachen:

• topic/send_request_count: die Anzahl der Batch-Nachrichten, die von Publishern gesendet werden.

• Ein Wert von topic/message_sizes: das Volumen der einzelnen (nicht in Batches zusammengefassten) Nachrichten, die von Publishern gesendet werden.

Mit der folgenden MQL-Abfrage können Sie die genaue Anzahl der veröffentlichten Nachrichten abrufen. Mit dieser MQL-Abfrage wird die Anzahl der einzelnen Nachrichten abgerufen, die innerhalb bestimmter Zeitintervalle in einem bestimmten Pub/Sub-Thema veröffentlicht wurden. Ersetzen Sie die Platzhalterwerte für $PROJECT_NAME und $TOPIC_ID durch die tatsächlichen Projekt- und Themen-IDs.

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

Für eine bessere Visualisierung, insbesondere bei täglichen Messwerten, sollten Sie Folgendes beachten:

• Sehen Sie sich Ihre Daten über einen längeren Zeitraum an, um mehr Kontext für tägliche Trends zu erhalten.

• Verwenden Sie Balkendiagramme, um die tägliche Nachrichtenanzahl darzustellen.

Nächste Schritte

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

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

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