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 Ihre Pub/Sub-Nutzung in mit Monitoring in der Google Cloud Console.

  • Wenn Sie Messwerte aus anderen Google Cloud-Ressourcen zusätzlich zu Pub/Sub-Messwerte verwenden Sie Monitoring.

  • Andernfalls können Sie die Monitoring-Dashboards verwenden, die im Pub/Sub Siehe Themen überwachen und Abos im Blick behalten.

Best Practices zur Verwendung von Messwerten in 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

Eine Möglichkeit, um sicherzustellen, dass Sie beides erhalten haben, besteht darin, Kurzanleitung: Cloud Console verwenden

Vorhandenes Dashboard ansehen

Mit einem Dashboard können Sie Daten aus verschiedenen Quellen im selben Kontext. Google Cloud bietet sowohl vordefinierte als auch benutzerdefinierte Dashboards. Für können Sie z. B. ein vordefiniertes Pub/Sub-Dashboard aufrufen oder ein benutzerdefiniertes Dashboard mit Messwertdaten, Benachrichtigungsrichtlinien und Logeinträgen im Zusammenhang mit zu Pub/Sub senden.

So überwachen Sie Ihr Pub/Sub-Projekt mithilfe von Cloud Monitoring: führen Sie die folgenden Schritte aus:

  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.

    Um nach dem vorhandenen Pub/Sub-Dashboard zu suchen, geben Sie im Filter für Wählen Sie unter Alle Dashboards die Eigenschaft Name aus und geben Sie Pub/Sub ein.

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

Einzelnen Pub/Sub-Messwert ansehen

So rufen Sie einen einzelnen Pub/Sub-Messwert mit der Methode in der Google Cloud Console führen Sie die folgenden Schritte aus:

  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 aus. oder Pub/Sub-Thema.

  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

Für ein bestimmtes Projekt können Sie den IAM und Dashboard für Administratorkontingente um aktuelle Kontingente und Nutzungsdaten zu sehen.

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

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

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 die Nutzung einen Bruchteil des Limits erreicht. Für Beispiel: Die folgende Monitoring Query Language-Abfrage löst eine Benachrichtigungsrichtlinie aus, wenn eines beliebigen Pub/Sub-Kontingents eine Auslastung 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')

Benutzerdefiniertes Monitoring und Benachrichtigungen zu Kontingentmesswerten finden Sie unter Kontingentmesswerte verwenden

Weitere Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

Ein funktionierendes Abo beibehalten

Sie können mehrere Abos überwachen, um ein fehlerfreies Abo aufrechtzuerhalten Properties mit von Pub/Sub bereitgestellten Messwerten. So können Sie zum Beispiel Umfang unbestätigter Nachrichten, Ablauf von Nachrichten überwachen Bestätigungsfristen usw. Sie können auch prüfen, ob Ihr Abo gut genug ist, um eine niedrige Latenz der Nachrichtenzustellung.

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

Nachrichtenrückstau beobachten

Um sicherzustellen, dass deine Abonnenten über den Nachrichtenfluss auf dem Laufenden bleiben, erstelle ein einem Dashboard. Das Dashboard kann die folgenden Backlog-Messwerte anzeigen, aggregiert nach Ressource für alle Ihre Abos:

Erstellen Sie Benachrichtigungsrichtlinien, die ausgelöst werden, wenn diese Werte außerhalb des akzeptablen Bereich im Kontext Ihres Systems. Zum Beispiel die absolute Anzahl der nicht bestätigten Nachrichten ist 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 Backlog-Probleme

Symptome Problem Lösungen
Sowohl oldest_unacked_message_age als auch num_undelivered_messages steigen gemeinsam an. Abonnenten halten sich nicht an die Nachrichtenmenge
  • 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 eine erfolgreiche Ausführung verhindern. Nachrichten bestätigen oder zeitnah verarbeiten. Siehe Ablauf der Bestätigungsfrist überwachen.
Wenn es einen konstanten, kleinen Rückstand in Kombination mit dass oldest_unacked_message_age ansteigt, gibt es möglicherweise einige Nachrichten, die nicht verarbeitet werden können. Festgefahrene Nachrichten
  • Prüfen Sie die Anwendungslogs, um festzustellen, ob einige Nachrichten die Ihren Code zum Absturz bringen. Es ist unwahrscheinlich – aber möglich – dass die anstößigen Nachrichten in Pub/Sub und nicht im Client. Stell einen Supportanfrage senden, wenn Sie sich sicher sind, dass Sie verarbeitet Ihr Code jede Nachricht erfolgreich.
  • Wenn einige Nachrichten zum Absturz Ihres Codes führen, sollten Sie erwägen, sie weiterzuleiten. diese Nachrichten an eine Thema für unzustellbare Nachrichten.
oldest_unacked_message_age überschreitet Abo Aufbewahrungsdauer für Nachrichten. Permanenter Datenverlust
  • Benachrichtigung einrichten, die vor Ende der Nachricht ausgelöst wird Aufbewahrungsdauer.

Zustand der Bereitstellungslatenz überwachen

In Pub/Sub ist die Bereitstellungslatenz die Zeit, die für eine veröffentlichte an einen Abonnenten zu senden. Wenn der Nachrichtenrückstand ansteigt, können Sie mithilfe der Funktion Zustelllatenz (subscription/delivery_latency_health_score), um zu prüfen, welche Faktoren zu einer erhöhten Latenz beitragen.

Mit diesem Messwert wird der Status eines einzelnen Abos 10-Minuten-Fenster. Der Messwert bietet einen Einblick in die folgenden Kriterien: Diese sind erforderlich, damit ein Abo eine konstant niedrige Latenz erreicht:

  • Vernachlässigbare Suchanfragen.

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

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

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

  • Eine konstant niedrige Auslastung, d. h., das Abo hat kontinuierlich um neue Nachrichten zu verarbeiten.

Für den Messwert Integritätsbewertung der Bereitstellungslatenz ist entweder 0 oder 1 angegeben. für jedes der angegebenen Kriterien. Ein Wert von 1 bedeutet einen fehlerfreien Zustand und 0 bedeutet einen fehlerhaften Zustand.

  • Suchanfragen: Wenn für das Abo in den letzten 10 Minuten liegt, ist der Punktestand 0. Suche kann ein Abo dazu führen, dass alte Nachrichten lange nach der ersten wodurch die Auslieferungslatenz erhöht wird.

  • Negativ bestätigte Nachrichten: Falls das Abo negativen Bestätigungs- oder Nack-Anfragen in den letzten 10 Minuten erhalten hat, auf 0 gesetzt ist. Eine negative Bestätigung führt dazu, dass eine Nachricht mit einer erhöhten Latenz noch einmal ausgeliefert werden.

  • Abgelaufene Bestätigungsfristen: Wenn das Abo abgelaufen ist Bestätigungsfristen in den letzten 10 Minuten festgelegt haben, wird die Punktzahl auf 0 gesetzt. Nachrichten Bestätigungsfrist abgelaufen ist, werden mit einem höheren Lieferverzögerung.

  • Bestätigungslatenzen: wenn das 99,9.Perzentil aller Bestätigungen in den letzten 10 Minuten länger als 30 Sekunden lag, auf 0 festgelegt ist. Eine hohe Bestätigungslatenz ist ein Zeichen dafür, dass ein Abonnentenclient die Verarbeitung einer Nachricht ungewöhnlich lange dauert. Diese Punktzahl könnte auf einen Fehler hinweisen. oder Ressourceneinschränkungen auf der Abonnentenclientseite.

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

    • StreamingPull: Wenn nicht genügend Streams offen sind, wird die Punktzahl festgelegt. 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ät für neue Nachrichten.

    • Pull: Wenn nicht genügend ausstehende Pull-Anfragen vorhanden sind, lautet der Wert auf 0 gesetzt ist. Öffnen Sie mehr gleichzeitige Pull-Anfragen, um sicherzustellen, dass Sie bereit sind, neue Nachrichten.

So rufen Sie den Messwert auf: Metrics Explorer wählen Sie unter Zustellungslatenz Punktzahl für den Ressourcentyp des Pub/Sub-Abos. Fügen Sie ein 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 sehen Sie einen Screenshot des Messwerts für einen Zeitraum von einer Stunde mit ein gestapeltes Flächendiagramm. Die kombinierte Integritätsbewertung steigt um 04:15 Uhr auf 5, wobei Faktor von 1 für jedes Kriterium. Später sinkt der kombinierte Wert auf 4, 04:20 Uhr, wenn der Auslastungswert auf 0 fällt.

Screenshot des Messwerts für die Bereitstellungslatenz

Monitoring Query Language bietet eine informative, textbasierte Schnittstelle für Cloud Monitoring-Zeitachsendaten. Die folgende MQL-Abfrage erstellt ein Diagramm, 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, ermöglicht Pub/Sub einem bestimmten Kunden eine bestimmte Zeit zur Bestätigung (Bestätigung) . Dieser Zeitraum wird als Bestätigungsfrist bezeichnet. Wenn deine Abonnenten zu lange zum Bestätigen von Nachrichten ist, werden die Nachrichten noch einmal zugestellt, was zur Folge hat, Abonnenten sehen doppelte Nachrichten. 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 die Nachrichtenbestätigung Frist. Cloud-Clientbibliotheken erweitern in der Regel 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 ist eine geringe Ablaufrate (z. B. 0,1–1%) gesund 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. Sie können Überwachen Sie den Batch-Nachrichtendurchsatz, der von Ihren Abonnenten verarbeitet wird. mit diesen Messwerten:

Sie können den einzelnen oder nicht zusammengefassten Nachrichtendurchsatz überwachen, Abonnenten mit dem Messwert subscription/sent_message_count nach dem Label delivery_type gefiltert.

Push-Abos beobachten

Ü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 als implizite Nachrichtenbestätigungen verwenden, ist es wichtig, Überwachen Sie Antwortcodes für Push-Anfragen. Da Push-Abos exponentiell zurückgehen, wenn Zeitüberschreitungen oder Fehler auftreten, kann Ihr Rückstand schnell wachsen, je nachdem, wie Ihr Endpunkt reagiert.

    Richten Sie eine Warnung für hohe Fehlerraten ein, da diese zu langsame Lieferung und ein wachsender Rückstand. Sie können einen Messwert erstellen, Antwortklasse. Die Anzahl der Push-Anfragen ist jedoch wahrscheinlich nützlicher, ein Tool zur Untersuchung der wachsenden Größe und des Alters des Rückstands.

  • subscription/num_outstanding_messages

    Pub/Sub begrenzt im Allgemeinen die Anzahl der ausstehenden Nachrichten. Weniger als 1.000 ausstehende Nachrichten in in den meisten Situationen. 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.

So greifen Sie auf höhere Limits für ausstehende Nachrichten zu: Push-Abonnenten müssen 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 einen Filter für ein Abo konfigurieren, erkennt automatisch Nachrichten, die nicht mit filter Sie können diese automatische Bestätigung überwachen.

Die Backlog-Messwerte enthalten nur Nachrichten die dem Filter entsprechen.

Um die Rate automatisch bestätigter Nachrichten zu überwachen, die nicht dem Filter entsprechen, verwenden Sie den subscription/ack_message_count Messwert mit dem Label delivery_type auf filter gesetzt.

Um den Durchsatz und die Kosten von automatisch bestätigten Nachrichten zu überwachen, die nicht mit dem verwenden Sie den subscription/byte_cost Messwert mit dem Label operation_type auf filter_drop Weitere Informationen zu den Gebühren für diese Nachrichten finden Sie unter Auf der Seite mit den Pub/Sub-Preisen

Weitergeleitete nicht zustellbare Nachrichten überwachen

Zum Überwachen nicht zustellbarer Nachrichten, die Pub/Sub zu einem Thema für unzustellbare Nachrichten weiterleitet, verwenden Sie den subscription/dead_letter_message_count Messwert. Dieser Messwert zeigt die Anzahl der nicht zustellbaren Nachrichten, die Pub/Sub von einem Abo weiterleitet.

Um zu prüfen, ob Pub/Sub nicht zustellbare Nachrichten weiterleitet, kann den Messwert subscription/dead_letter_message_count mit dem topic/send_request_count Messwert. Führen Sie den Vergleich für das Thema der unzustellbaren Nachrichten durch, mit dem Pub/Sub leitet diese Nachrichten weiter.

Sie können auch ein Abo an das Thema für unzustellbare Nachrichten anhängen und dann nicht zustellbare Nachrichten für dieses Abo mithilfe der folgenden Messwerte weitergeleitet haben:

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 Sorge, da die meisten Cloud-Clientbibliotheken Nachrichtenfehler. 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 im Publish-Client zu verfolgen. Obwohl Clientbibliotheken fehlgeschlagene Anfragen in der Regel wiederholen, garantieren sie keine Veröffentlichung. Weitere Informationen finden Sie unter Nachrichten veröffentlichen für Möglichkeiten zum Erkennen dauerhafter Veröffentlichungsfehler bei der Verwendung des Cloud-Clients Bibliotheken. 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. Ich den von Ihren Publishern gesendeten Nachrichtendurchsatz mit diesen Metriken:

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

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

    Sie können die Anzahl der gesendeten Nachrichten berechnen, indem Sie eine Anzahl zu diesem Messwert oder mithilfe von Monitoring Query Language. Mit der folgenden MQL-Abfrage wird ein Diagramm mit dem Preis Nachrichten, 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