Pub/Sub in Cloud Monitoring überwachen

Sie können die Cloud de Confiance 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 Cloud de Confiance Console mit Monitoring im Blick behalten.

  • Wenn Sie neben Pub/Sub-Messwerten auch Messwerte aus anderen Cloud de Confiance by S3NS 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 im Blick behalten und Abos im Blick behalten.

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

Hinweis

Bevor Sie Monitoring verwenden, 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

In 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, auf dem Messwertdaten, Benachrichtigungsrichtlinien und Logeinträge im Zusammenhang mit Pub/Sub angezeigt werden.

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

  1. Rufen Sie in der Cloud de Confiance 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 Eigenschaft 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

So rufen Sie einen einzelnen Pub/Sub-Messwert über die Cloud de Confiance Console auf:

  1. Rufen Sie in der Cloud de Confiance 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. Klicken Sie auf einen bestimmten Messwert und dann auf Übernehmen.

    Die Seite für eine bestimmte Messwert wird geöffnet.

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

Pub/Sub-Messwerte und ‑Ressourcentypen ansehen

Auf den PromQL-Editor zugreifen

Metrics Explorer ist eine Schnittstelle in Cloud Monitoring, mit der Sie Ihre Messwertdaten untersuchen und visualisieren können. Im Metrics Explorer können Sie die Prometheus-Abfragesprache (PromQL) verwenden, um Ihre Pub/Sub-Messwerte abzufragen und zu analysieren.

Informationen zum Aufrufen des Code-Editors und zum Abfragen von Cloud Monitoring-Messwerten mit PromQL im Metrics Explorer finden Sie unter Code-Editor für PromQL verwenden.

Sie können beispielsweise eine PromQL-Abfrage eingeben, um die Anzahl der Nachrichten zu überwachen, die in einem fortlaufenden Zeitraum von einer Stunde an ein bestimmtes Abo gesendet werden:

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

Kontingentnutzung überwachen

Im IAM-Dashboard „Kontingente“ können Sie die aktuellen Kontingente und die Nutzung für ein bestimmtes Projekt einsehen.

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

Bei diesen Messwerten wird der überwachte Ressourcentyp consumer_quota verwendet. Weitere Messwerte im Zusammenhang mit Kontingenten finden Sie in der Liste der Messwerte.

Mit der folgenden PromQL-Abfrage wird beispielsweise ein Diagramm mit dem Anteil des Publisher-Kontingents erstellt, der in jeder Region verwendet wird:

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

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 Bruchteil des Limits erreicht. Die folgende PromQL-Abfrage löst beispielsweise eine Benachrichtigungsrichtlinie aus, wenn ein Pub/Sub-Kontingent zu mehr als 80% genutzt wird:

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

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

Weitere Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

Abo aktiv halten

Um ein fehlerfreies Abo aufrechtzuerhalten, können Sie verschiedene Aboeigenschaften mithilfe von Pub/Sub-Messwerten überwachen. So können Sie beispielsweise das Volumen nicht bestätigter Nachrichten und das Ablaufen von Fristen für die Bestätigung von Nachrichten im Blick behalten. Sie können auch prüfen, ob Ihr Abo ausreichend ist, um eine niedrige Latenz der Nachrichtenzustellung zu erreichen.

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

Nachrichtenrückstand überwachen

Erstellen Sie ein Dashboard, damit Ihre Abonnenten den Überblick über die Nachrichten behalten. Im Dashboard können die folgenden Backlog-Messwerte für alle Ihre Abos aggregiert nach Ressource angezeigt werden:

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 ist für ein Abo mit einer Million Nachrichten pro Sekunde möglicherweise akzeptabel, für ein Abo mit einer Nachricht pro Sekunde jedoch nicht.

Regionale Versionen der Messwerte anstelle von globalen Versionen verwenden

Pub/Sub bietet regionale und globale Versionen der Messwerte, mit denen Sie den Abo-Rückstand überwachen können. Achten Sie darauf, dass Sie die regionalen Versionen mit dem Suffix by_region verwenden:

Verwenden Sie nicht die globalen Versionen dieser Messwerte, wenn Ihre Monitoring-Dashboards und Benachrichtigungsrichtlinien gegen Ausfälle in einzelnen Regionen geschützt sein sollen. Für die globalen Versionen dieser Messwerte muss der Rückstand in allen Regionen berechnet werden, in denen Nachrichten vorhanden sind. Das bedeutet, dass die Nichtverfügbarkeit in einer einzelnen Region zu einer Datenlücke führt. Bei den by_region-Versionen der Messwerte wird der Rückstand dagegen auf regionaler Basis berechnet und gemeldet. Wenn der Rückstand für eine einzelne Region nicht berechnet werden kann, werden für die anderen Regionen trotzdem Werte für den Messwert ausgegeben.

Häufige Probleme mit dem Backlog

Symptome Problem Lösungen
Sowohl oldest_unacked_message_age_by_region als auch num_unacked_messages_by_region steigen gemeinsam an. Abonnenten können mit dem Nachrichtenvolumen nicht mithalten
  • Fügen Sie weitere Abonnententhreads oder -prozesse hinzu.
  • Fügen Sie weitere Abonnentenmaschinen oder Container hinzu.
  • Suchen Sie in Ihrem Code nach Anzeichen für Fehler, die verhindern, dass Nachrichten erfolgreich bestätigt oder rechtzeitig verarbeitet werden. Weitere Informationen finden Sie unter Ablauf der Bestätigungsfrist überwachen.
Wenn die Größe des Backlogs konstant klein ist und die oldest_unacked_message_age_by_region stetig wächst, können möglicherweise einige Nachrichten nicht verarbeitet werden. Festgefahrene Nachrichten
  • Sehen Sie sich die Anwendungslogs an, um herauszufinden, ob bestimmte Nachrichten dazu führen, dass Ihr Code abstürzt. Es ist unwahrscheinlich, aber möglich, dass die betreffenden Nachrichten in Pub/Sub und nicht in Ihrem Client hängen geblieben sind. Erstellen Sie einen Supportfall, wenn Sie sicher sind, dass Ihr Code jede Nachricht erfolgreich verarbeitet.
  • Wenn einige Nachrichten dazu führen, dass Ihr Code abstürzt, sollten Sie diese Nachrichten an ein Thema für unzustellbare Nachrichten weiterleiten.
Die oldest_unacked_message_age_by_region überschreitet die Aufbewahrungsdauer für Abonachrichten. Permanenter Datenverlust
  • Richten Sie eine Benachrichtigung ein, die vor Ablauf der Aufbewahrungsdauer für Nachrichten ausgelöst wird.

Integrität der Zustellungslatenz überwachen

In Pub/Sub ist die Zustellungs-Latenz die Zeit, die benötigt wird, bis eine veröffentlichte Nachricht an einen Abonnenten zugestellt wird. Wenn Ihr Nachrichtenrückstand zunimmt, können Sie den Status der Zustellungslatenz (subscription/delivery_latency_health_score) verwenden, um zu prüfen, welche Faktoren zu einer erhöhten Latenz beitragen.

Mit diesem Messwert wird der Status eines einzelnen Abos in einem gleitenden 10‑Minuten-Zeitfenster gemessen. Der Messwert gibt Aufschluss über die folgenden Kriterien, die für ein Abo mit konstant niedriger Latenz erforderlich sind:

  • Geringfügige Suchanfragen.

  • Nachrichten, die vernachlässigbar negativ bestätigt wurden.

  • Die Bestätigungsfristen für abgelaufene Nachrichten sind vernachlässigbar.

  • Die Bestätigungslatenz beträgt konstant weniger als 30 Sekunden.

  • Eine gleichbleibend niedrige Auslastung bedeutet, dass das Abo immer genügend Kapazität hat, um neue Nachrichten zu verarbeiten.

Der Messwert Integritätbewertung für Zustellungslatenz gibt für jedes der angegebenen Kriterien einen Wert von 0 oder 1 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, wird der Wert auf 0 gesetzt. Suchen: Wenn Sie ein Abo suchen, werden möglicherweise alte Nachrichten lange nach ihrer ersten Veröffentlichung noch einmal wiedergegeben, was zu einer erhöhten Zustellungslatenz führt.

  • Negativ bestätigte (nacked) Nachrichten: Wenn für das Abo in den letzten 10 Minuten Anfragen mit negativer Bestätigung (nack) eingegangen sind, wird der Wert auf 0 gesetzt. Eine negative Bestätigung führt dazu, dass eine Nachricht mit einer erhöhten Zustelllatenz noch einmal zugestellt wird.

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

  • 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ätigungsverzögerung 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 Fehler oder Ressourcenbeschränkungen auf der Clientseite des Abonnenten hinweisen.

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

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

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

    • Pull: Wenn Sie nicht genügend ausstehende Pull-Anfragen haben, wird die Punktzahl auf 0 gesetzt. Öffnen Sie weitere gleichzeitige Pull-Anfragen, damit Sie bereit sind, neue Nachrichten zu empfangen.

Wenn Sie den Messwert aufrufen möchten, wählen Sie im Metrics Explorer den Messwert Zustelllatenz-Gesamtstatus für den Ressourcentyp „Pub/Sub-Abo“ aus. Fügen Sie einen Filter hinzu, um jeweils nur ein Abo auszuwählen. Wählen Sie das Stapelflächendiagramm aus und zeigen Sie auf einen bestimmten Zeitpunkt, um die Kriterienwerte für das Abo zu diesem Zeitpunkt zu sehen.

Der folgende Screenshot zeigt den Messwert, der für einen Zeitraum von einer Stunde in einem gestapelten Flächendiagramm dargestellt wird. Der kombinierte Systemzustand erreicht um 4:15 Uhr den Wert 5, wobei jedes Kriterium den Wert 1 hat. Später sinkt der kombinierte Wert um 4:20 Uhr auf 4, wenn der Nutzungs-Score auf 0 fällt.

Screenshot des Messwerts für die Zustellungslatenz

PromQL bietet eine textbasierte, sogenannte sprechende Schnittstelle für Cloud Monitoring-Zeitreihendaten. Mit der folgenden PromQL-Abfrage wird ein Diagramm erstellt, mit dem die Integrität der Zustellungslatenz für ein Abo gemessen wird.

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

Ablauf der Bestätigungsfrist im Blick behalten

Um die Latenz bei der Nachrichtenzustellung zu verringern, haben Abonnentenclients in Pub/Sub nur eine begrenzte Zeit, um eine bestimmte Nachricht zu bestätigen. 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 doppelte Nachrichten 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 die Frist für die Bestätigung der Nachricht. 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 die Häufigkeit messen, mit der 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. Eine niedrige Ablaufquote (z. B. 0,1–1%) kann hingegen ein gutes Zeichen sein.

Nachrichtendurchsatz überwachen

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

Sie können den individuellen oder nicht gebündelten 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 PromQL-Abfrage gibt ein Zeitreihendiagramm mit der Gesamtzahl der Nachrichten zurück, die in einem gleitenden 10‑Minuten-Zeitraum an ein bestimmtes Pub/Sub-Abo gesendet wurden. Ersetzen Sie die Platzhalterwerte für $PROJECT_NAME und $SUBSCRIPTION_NAME durch Ihre tatsächlichen Projekt- und Themen-IDs.

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

Push-Abos im Blick behalten

Bei Push-Abos sollten Sie die folgenden Messwerte im Blick behalten:

  • subscription/push_request_count

    Gruppieren Sie den Messwert nach response_code und subscription_id. Da bei Pub/Sub-Push-Abos Antwortcodes als implizite Nachrichtenbestätigungen verwendet werden, ist es wichtig, die Antwortcodes von 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 Benachrichtigung für hohe Fehlerraten einrichten, da diese zu einer langsamen Auslieferung 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 die wachsende Größe und das Alter des Backlogs 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 haben. Sobald der Durchsatz eine Rate in der Größenordnung von 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. Über den Höchstwert hinaus gibt es keine spezifischen Garantien. 1.000 ausstehende Nachrichten sind ein guter Richtwert.

  • subscription/push_request_latencies

    Mit diesem Messwert können Sie die Verteilung der Antwortlatenz des Push-Endpunkts nachvollziehen. 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 Limits für ausstehende Nachrichten zuzugreifen, müssen Push-Abonnenten mehr als 99% der Nachrichten bestätigen, die sie erhalten.

Sie können den Anteil der Nachrichten, die Abonnenten bestätigen, mit PromQL berechnen. Mit der folgenden PromQL-Abfrage wird ein Diagramm mit dem Anteil der Nachrichten erstellt, die Abonnenten in einem Abo bestätigen:

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

Abos mit Filtern im Blick behalten

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

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

Wenn Sie die Rate der automatisch bestätigten Nachrichten überwachen möchten, die nicht dem Filter entsprechen, verwenden Sie den Messwert subscription/ack_message_count mit dem Label delivery_type, das auf filter festgelegt ist.

Wenn Sie den Durchsatz und die Kosten von automatisch bestätigten Nachrichten überwachen möchten, die nicht mit dem Filter übereinstimmen, verwenden Sie den Messwert subscription/byte_cost mit dem Label operation_type, das auf filter_drop festgelegt ist. Weitere Informationen zu den Gebühren für diese Nachrichten finden Sie auf der Pub/Sub-Preisseite.

Abos mit SMTs überwachen

Wenn Ihr Abo eine SMT enthält, mit der Nachrichten herausgefiltert werden, enthalten die Backlog-Messwerte die herausgefilterten Nachrichten, bis die SMT tatsächlich auf sie angewendet wird. Das bedeutet, dass der Rückstand möglicherweise größer und das Alter der ältesten unbestätigten Nachricht möglicherweise höher ist als das, was an deinen Abonnenten gesendet wird. Das ist besonders wichtig, wenn Sie diese Messwerte verwenden, um Abonnenten automatisch zu skalieren.

Weitergeleitete unzustellbare Nachrichten beobachten

Verwenden Sie den Messwert subscription/dead_letter_message_count, um unzustellbare 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.

Um zu prüfen, 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 unzustellbaren Nachrichten in diesem Abo mit den folgenden Messwerten überwachen:

Gesunde Publisher-Beziehungen pflegen

Das primäre Ziel eines Publishers ist es, Nachrichtendaten schnell zu speichern. Behalten Sie die Leistung mit topic/send_request_count im Blick, 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 Besorgnis, da die meisten Cloud-Clientbibliotheken Nachrichtenfehler wiederholen. Untersuchen Sie Fehlerraten, die höher 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.

Es ist ebenso wichtig, fehlgeschlagene Veröffentlichungsanfragen in Ihrem Veröffentlichungsclient zu erfassen. Obwohl Clientbibliotheken fehlgeschlagene Anfragen in der Regel wiederholen, garantieren sie keine Veröffentlichung. Informationen zum Erkennen dauerhafter Veröffentlichungsfehler bei Verwendung von Cloud-Clientbibliotheken finden Sie unter Nachrichten veröffentlichen. Ihre Publisher-Anwendung muss mindestens 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 senden Nachrichten möglicherweise in Batches. Mit den folgenden Messwerten können Sie den von Ihren Publishern gesendeten Nachrichtendurchsatz im Blick behalten:

Verwenden Sie die folgende PromQL-Abfrage, um eine genaue Anzahl der veröffentlichten Nachrichten zu erhalten. Mit dieser PromQL-Abfrage wird die Anzahl der einzelnen Nachrichten abgerufen, die in definierten Zeitintervallen in einem bestimmten Pub/Sub-Thema veröffentlicht wurden. Ersetzen Sie die Platzhalterwerte für $PROJECT_NAME und $TOPIC_ID durch Ihre tatsächlichen Projekt- und Themen-IDs.

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

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

  • Wenn Sie sich Ihre Daten über einen längeren Zeitraum ansehen, erhalten Sie mehr Kontext für tägliche Trends.

  • Verwenden Sie Balkendiagramme, um die tägliche Anzahl von Nachrichten darzustellen.

Nächste Schritte