Sie können Diagramme im Tab Jobmesswerte der Dataflow-UI aufrufen. Die Messwerte sind in folgenden Dashboards organisiert:
Übersichtsmesswerte
Streamingmesswerte (nur Streamingpipelines)
- Datenaktualität (mit und ohne Streaming Engine)
- Systemlatenz (mit und ohne Streaming Engine)
- Rückstand
- Verarbeitung (nur Streaming Engine)
- Parallelität (nur Streaming Engine)
- Persistenz (nur Streaming Engine)
- Duplikate (nur Streaming Engine)
- Timer (nur Streaming Engine)
Ressourcenmesswerte
Eingabemesswerte
Ausgabemesswerte
Klicken Sie auf den Schalter Diagrammlegende maximieren, um auf zusätzliche Informationen in diesen Diagrammen zuzugreifen.
Einige dieser Diagramme gelten nur für Streamingpipelines. Eine Liste der Szenarien, in denen diese Messwerte für die Fehlerbehebung nützlich sein können, finden Sie im Abschnitt Dataflow-Monitoringmesswerte verwenden.
Zum Schreiben von Messwertdaten erfordert ein nutzerverwaltetes Dienstkonto die IAM-Berechtigung monitoring.timeSeries.create, die in der Rolle Dataflow-Worker enthalten ist.
Weitere Informationen zur Verwendung dieser Messwerte außerhalb der Dataflow-UI finden Sie in der vollständigen Liste der Dataflow-Messwerte.
Der Dataflow-Dienst meldet die reservierte CPU-Zeit nach dem Abschluss von Jobs. Bei unbegrenzten Jobs (Streamingjobs) wird die reservierte CPU-Zeit erst gemeldet, nachdem die Jobs abgebrochen wurden oder fehlgeschlagen sind. Daher enthalten die Jobmesswerte keine reservierte CPU-Zeit für Streamingjobs.
Anzeigebereich- und Worker-Messwerte
Die folgenden Abschnitte enthalten Details zu den in der Monitoring-Oberfläche verfügbaren Phasen- und Worker-Messwerten.
Autoscaling
Der Dataflow-Dienst wählt automatisch die zum Ausführen des Autoscaling-Jobs erforderliche Anzahl von Worker-Instanzen aus. Die Anzahl der Worker-Instanzen kann sich im Laufe der Zeit entsprechend den Jobanforderungen ändern.
Sie können den Verlauf der Autoscaling-Änderungen durch Klicken auf die Schaltfläche Weiteren Verlauf aufrufen. Eine Tabelle mit Informationen zum Worker-Verlauf Ihrer Pipeline wird angezeigt.
Durchsatz
Der Durchsatz ist das Datenvolumen, das zu einem bestimmten Zeitpunkt verarbeitet wird. Dieser Messwert pro Schritt wird als Anzahl der Elemente pro Sekunde angezeigt. Scrollen Sie zum Diagramm Durchsatz (Byte/Sek.), um diesen Messwert in Byte pro Sekunde anzusehen.
Logzähler für Worker-Fehler
In Logzähler für Worker-Fehler sehen Sie die Fehlerquote der einzelnen Worker zum jeweiligen Zeitpunkt.
Datenaktualität (mit und ohne Streaming Engine)
Der Messwert zur Datenaktualität zeigt die Differenz in Sekunden zwischen dem Zeitstempel des Datenelements und dem Zeitpunkt, zu dem das Ereignis in Ihrer Pipeline verarbeitet wird. Das Datenelement erhält einen Zeitstempel, wenn ein Ereignis für das Element auftritt, z. B. ein Klick auf eine Website oder eine Aufnahme durch Pub/Sub. Die Zeit, zu der die Daten verarbeitet werden, ist das Ausgabewasserzeichen.
Der Dataflow-Job kann jederzeit mehrere Elemente verarbeiten. Die Datenpunkte im Datenaktualitätsdiagramm zeigen das Element mit der größten Verzögerung im Verhältnis zur Ereigniszeit an. Daher enthält dieselbe Linie im Diagramm Daten für mehrere Elemente, wobei jeder Datenpunkt in der Linie Daten für das langsamste Element in dieser Phase in der Pipeline anzeigt.
Wenn irgendwelche Eingabedaten noch nicht verarbeitet wurden, kann das Ausgabewasserzeichen verzögert sein, was sich auf die Datenaktualität auswirkt. Ein erheblicher Unterschied zwischen der Wasserzeichenzeit und der Ereigniszeit zeigt einen langsamen Vorgang an.
Für kürzlich aktualisierte Streamingjobs sind möglicherweise keine Jobstatus- und Wasserzeicheninformationen verfügbar. Der Aktualisierungsvorgang nimmt mehrere Änderungen vor, deren Weitergabe an die Monitoring-Oberfläche von Dataflow einige Minuten dauern kann. Aktualisieren Sie die Monitoring-Oberfläche 5 Minuten nach der Aktualisierung Ihres Jobs.
Weitere Informationen finden Sie in der Apache Beam-Dokumentation unter Wasserzeichen und verspätete Daten.
Das Dashboard enthält die folgenden zwei Diagramme:
- Datenaktualität nach Phasen
- Datenaktualität
In der vorherigen Abbildung zeigt der markierte Bereich einen erheblichen Unterschied zwischen der Ereigniszeit und der Ausgabezeit im Wasserzeichen, was auf einen langsamen Vorgang hinweist.
Systemlatenz (mit und ohne Streaming Engine)
Die Systemlatenz ist die aktuelle maximale Dauer in Sekunden, die ein Datenelement verarbeitet wurde oder auf die Verarbeitung wartet. Dieser Messwert gibt an, wie lange ein Element innerhalb einer Quelle in der Pipeline wartet. Die maximale Dauer wird nach der Verarbeitung angepasst. Weitere Hinweise:
- Bei mehreren Quellen und Senken ist die Systemlatenz die maximale Zeitspanne, die ein Element innerhalb einer Quelle wartet, bevor es in alle Senken geschrieben wird.
- Manchmal gibt eine Quelle keinen Wert für den Zeitraum an, für den ein Element innerhalb der Quelle wartet. Außerdem kann das Element keine Metadaten haben, um die Ereigniszeit zu definieren. In diesem Szenario wird die Systemlatenz ab dem Zeitpunkt berechnet, an dem die Pipeline das Element empfängt.
Das Dashboard enthält die folgenden zwei Diagramme:
- Systemlatenz nach Phasen
- Systemlatenz
Rückstand
Das Dashboard Rückstand enthält Informationen zu Elementen, die noch verarbeitet werden müssen. Das Dashboard enthält die folgenden zwei Diagramme:
- Rückstandssekunden (nur Streaming Engine)
- Rückstand in Byte (mit und ohne Streaming Engine)
Das Diagramm Rückstandsekunden zeigt eine Schätzung der Zeit in Sekunden, die benötigt wird, um den aktuellen Rückstand zu verarbeiten, wenn keine neuen Daten eintreffen und sich der Durchsatz nicht ändert. Die geschätzte Rückstandszeit wird sowohl aus dem Durchsatz als auch aus den Rückstandbyte aus der Eingabequelle berechnet, die noch verarbeitet werden müssen. Dieser Messwert wird vom Feature Streaming-Autoscaling verwendet, um zu bestimmen, wann hoch- oder herunterskaliert werden soll.
Das Diagramm Rückstandbyte zeigt die Menge der bekannten nicht verarbeiteten Eingaben für eine Phase in Byte an. Bei diesem Messwert werden die verbleibenden Byte, die von jeder Phase verbraucht werden, mit den vorgelagerten Phasen verglichen. Damit dieser Messwert genau die Berichte meldet, muss jede von der Pipeline aufgenommene Quelle korrekt konfiguriert sein. Native Quellen wie Pub/Sub und BigQuery werden bereits standardmäßig unterstützt. Benutzerdefinierte Quellen erfordern jedoch eine zusätzliche Implementierung. Weitere Informationen finden Sie unter Autoscaling für benutzerdefinierte unbegrenzte Quellen.
Verarbeitung (nur Streaming Engine)
Das Dashboard Verarbeitung enthält Informationen zu aktiven Nutzervorgängen. Das Dashboard enthält die folgenden zwei Diagramme:
- Heatmap der Nutzerverarbeitungslatenzen
- Nutzerverarbeitungslatenzen nach Phase
Die Heatmap zur Nutzerverarbeitungslatenz zeigt die maximalen Latenzen für Nutzervorgänge über die Verteilungen des 50., 95. und 99. Perzentils. Mit der Heatmap können Sie feststellen, ob Longtail-Vorgänge eine hohe Gesamtsystemlatenz oder die Gesamtdatenaktualität negativ beeinträchtigen.
Hohe Latenzen im 99. Perzentil sind in der Regel weniger wichtig für den Job als hohe Latenzen im 50. Perzentil. Um ein Upstream-Problem zu beheben, bevor es zu einem Problem wird, legen Sie eine Benachrichtigungsrichtlinie für hohe Latenzen im 50. Perzentil fest.
Im Diagramm Latenzen der Nutzerverarbeitung nach Phase wird das 99. Perzentil für jeden aktiven Nutzervorgang nach Phase angezeigt. Verursacht Nutzercode einen Engpass, wird in diesem Diagramm angezeigt, welche Phase den Engpass enthält. Mit den folgenden Schritten können Sie Fehler in der Pipeline beheben:
Verwenden Sie das Diagramm, um eine Phase mit ungewöhnlich hoher Latenz zu finden.
Wählen Sie auf der Seite mit den Jobdetails auf dem Tab Ausführungsdetails für Grafikansicht die Option Phasenworkflow aus. Suchen Sie im Diagramm Phasenworkflow nach der Phase mit ungewöhnlich hoher Latenz.
Klicken Sie im Diagramm auf den Knoten für diese Phase, um die zugehörigen Nutzervorgänge zu ermitteln.
Für weitere Details rufen Sie Cloud Profiler auf und verwenden Sie Cloud Profiler, um Fehler im Stacktrace zum richtigen Zeitraum zu beheben. Suchen Sie nach den Nutzervorgängen, die Sie im vorherigen Schritt ermittelt haben.
Parallelität (nur Streaming Engine)
Das Diagramm Parallelverarbeitung zeigt die ungefähre Anzahl der Schlüssel an, die für die Datenverarbeitung in jeder Phase verwendet werden. Dataflow skaliert auf der Grundlage der Parallelität einer Pipeline. In Dataflow ist die Parallelität einer Pipeline eine Schätzung der Anzahl der Threads, die für die effizienteste Verarbeitung von Daten zu einem bestimmten Zeitpunkt erforderlich sind. Die Verarbeitung für einen bestimmten Schlüssel ist serialisiert, sodass die Gesamtzahl der Schlüssel für eine Phase die maximal verfügbare Parallelität in dieser Phase darstellt. Parallelitätsmesswerte können nützlich sein, um heiße Schlüssel oder Engpässe für langsame oder hängende Pipelines zu ermitteln.
Persistenz (nur Streaming Engine)
Das Dashboard Persistenz bietet Informationen zur Rate, mit der nichtflüchtiger Speicher von einer bestimmten Pipelinephase in Byte pro Sekunde geschrieben und gelesen wird. Das Dashboard enthält die folgenden zwei Diagramme:
- Schreiben in Speicher
- Speicherlesevorgänge
Die Geschwindigkeit von Schreib- und Lesevorgängen wird durch die maximale IOPS (Eingabe-/Ausgabevorgänge pro Sekunde) des ausgewählten Laufwerks begrenzt. Überprüfen Sie die IOPS der von den Workern verwendeten Laufwerke, um festzustellen, ob das aktuelle Laufwerk einen Engpass verursacht. Weitere Informationen zu den Leistungsgrenzen für nichtflüchtige Speicher finden Sie unter Leistungslimits.
Duplikate (nur Streaming Engine)
Das Diagramm Duplikate zeigt die Anzahl der Nachrichten, die von einer bestimmten Phase verarbeitet wurden und als Duplikate herausgefiltert wurden.
Dataflow unterstützt viele Quellen und Senken, die eine at least once-Zustellung garantieren. Der Nachteil der at least once-Zustellung ist, dass sie zu Duplikaten führen kann.
Dataflow garantiert die exactly once-Zustellung, d. h. Duplikate werden automatisch herausgefiltert.
Nachgelagerte Phasen werden aus der erneuten Verarbeitung derselben Elemente gespeichert, wodurch sichergestellt wird, dass der Status und die Ausgaben nicht betroffen sind.
Die Pipeline kann für Ressourcen und Leistung optimiert werden, indem die Anzahl der Duplikate in jeder Phase reduziert wird.
Timer (nur Streaming Engine)
Das Dashboard Timer enthält Informationen zur Anzahl der ausstehenden Timer und zur Anzahl der Timer, die bereits in einer bestimmten Pipelinephase verarbeitet wurden. Da Fenster auf Timer angewiesen sind, können Sie mit diesem Messwert den Fortschritt von Fenstern verfolgen.
Das Dashboard enthält die folgenden zwei Diagramme:
- Ausstehende Timer nach Phase
- Timer für die Verarbeitung nach Phase
Diese Diagramme zeigen die Rate, zu der Fenster zu einem bestimmten Zeitpunkt ausstehen oder verarbeitet werden. Das Diagramm Timer nach Phase gibt an, wie viele Fenster aufgrund von Engpässen verzögert werden. Das Diagramm Timer nach Phase gibt an, wie viele Fenster derzeit Elemente erfassen.
In diesen Diagrammen werden alle Job-Timer angezeigt. Wenn Timer an anderer Stelle im Code verwendet werden, werden diese Timer ebenfalls in diesen Diagrammen angezeigt.
CPU-Auslastung
Die CPU-Auslastung ist die genutzte CPU-Kapazität, geteilt durch die CPU-Kapazität, die für die Verarbeitung verfügbar ist. Dieser Messwert pro Worker wird als Prozentsatz angezeigt. Das Dashboard enthält die folgenden vier Diagramme:
- CPU-Auslastung (Alle Worker)
- CPU-Auslastung (Stats)
- CPU-Auslastung (Obere 4)
- CPU-Auslastung (Untere 4)
Arbeitsspeicherauslastung
Die Speicherauslastung ist die geschätzte Speichermenge, die von den Workern in Byte pro Sekunde verwendet wird. Das Dashboard enthält die folgenden zwei Diagramme:
- Maximale Worker-Speicherauslastung (geschätzte Byte pro Sekunde)
- Speicherauslastung (geschätzte Byte pro Sekunde)
Das Diagramm Maximale Worker-Auslastung enthält Informationen zu den Workern, die zu jedem Zeitpunkt den meisten Arbeitsspeicher im Dataflow-Job verwenden. Wenn sich der Worker an verschiedenen Punkten während eines Jobs ändert, der die maximale Speichermenge verwendet, zeigt dieselbe Linie im Diagramm Daten für mehrere Worker an, wobei jeder Datenpunkt in der Zeile Daten für den Worker mit der maximalen Speichermenge zu diesem Zeitpunkt anzeigt. Das Diagramm vergleicht den geschätzten Worker, der vom Worker verwendet wird, mit dem Arbeitsspeicherlimit in Byte.
Sie können dieses Diagramm verwenden, um Probleme mit unzureichendem Speicherplatz zu beheben. Abstürze ohne Worker-Speicher werden in diesem Diagramm nicht angezeigt.
Das Diagramm Speicherauslastung zeigt eine Schätzung des Arbeitsspeichers, der von allen Workern im Dataflow-Job verwendet wird, im Vergleich zum Arbeitsspeicherlimit in Byte.
Eingabe- und Ausgabemesswerte
Eingabemesswerte und Ausgabemesswerte werden angezeigt, wenn Ihr Streaming Dataflow-Job Datensätze mit Pub/Sub liest oder schreibt.
Alle Eingabemesswerte desselben Typs werden kombiniert und auch alle Ausgabemesswerte werden kombiniert. Beispielsweise werden alle Pub/Sub-Messwerte in einem Abschnitt gruppiert. Jeder Messwerttyp ist in einem separaten Abschnitt organisiert. Wählen Sie den Abschnitt auf der linken Seite aus, der die gewünschten Messwerte darstellt, um die angezeigten Messwerte zu ändern. In den folgenden Abbildungen sind alle verfügbaren Abschnitte aufgeführt.
Die folgenden beiden Diagramme werden sowohl im Bereich Eingabemesswerte als auch im Bereich Ausgabemesswerte angezeigt.
Anfragen pro Sekunde
„Anfragen pro Sekunde“ ist die Rate von API-Anfragen der Quelle oder Senke zum Lesen oder Schreiben von Daten im Zeitverlauf. Wenn diese Rate auf null sinkt oder erheblich für einen längeren Zeitraum relativ zum erwarteten Verhalten sinkt, kann die Pipeline bestimmte Vorgänge möglicherweise nicht ausführen. Außerdem liegen unter Umständen keine Daten zum Lesen vor. Überprüfen Sie in einem solchen Fall die Jobschritte mit einem hohen Systemwasserzeichen. Überprüfen Sie auch die Worker-Logs auf Fehler oder Hinweise auf eine langsame Verarbeitung.
Antwortfehler pro Sekunde nach Fehlertyp
„Antwortfehler pro Sekunde nach Fehlertyp“ ist die Rate fehlgeschlagener API-Anfragen von der Quelle oder Senke zum Lesen oder Schreiben von Daten im Zeitverlauf. Wenn solche Fehler häufig auftreten, verlangsamen diese API-Anfragen möglicherweise die Verarbeitung. Diese fehlgeschlagenen API-Anfragen müssen untersucht werden. Informationen zur Behebung dieser Probleme finden Sie in der allgemeinen Dokumentation zu E/A-Fehlercodes und allen von der Quelle oder Senke verwendeten Dokumentationen zu spezifischen Fehlercodes, z. B. den Pub/Sub-Fehlercodes.
Messwert-Explorer verwenden
Die folgenden Dataflow-E/A-Messwerte können in Metrics Explorer aufgerufen werden:
job/pubsub/write_count: Pub/Sub-Veröffentlichungsanfragen von PubsubIO.Write in Dataflow-Jobs.job/pubsub/read_count: Pub/Sub-Pull-Anfragen von Pubsub.IO.Read in Dataflow-Jobsjob/bigquery/write_count: BigQuery-Veröffentlichungsanfragen von BigQueryIO.Write in Dataflow-Jobsjob/bigquery/write_count-Messwerte sind in Python-Pipelines mithilfe der WriteToBigQuery-Transformation verfügbar, wennmethod='STREAMING_INSERTS'für Apache Beam Version 2.28.0 oder höher aktiviert ist.
Die vollständige Liste der Dataflow-Messwerte finden Sie in der Dokumentation zu Google Cloud-Messwerten.
Bevorstehende Änderungen für Pub/Sub-Messwerte (nur Streaming Engine)
Streaming Engine verwendet derzeit die synchrone Pull-Zustellung, um Daten aus Pub/Sub zu nutzen. Demnächst werden wir jedoch zur Verbesserung der Leistung zu Streaming Pull migrieren. Die vorhandenen Grafiken und Messwerte mit Anfragen pro Sekunde und Antwortfehler pro Sekunde eignen sich nur für Synchronous Pull-Vorgänge. Wir fügen einen Messwert zum Zustand von Streaming Pull-Verbindungen hinzu und alle Fehler, die diese Verbindungen beenden.
Für die Migration ist keine Einbindung der Nutzer erforderlich. Während der Migration verwendet ein Job möglicherweise für einen bestimmten Zeitraum Synchronous Pull und für einen anderen Zeitraum Streaming Pull. Daher werden für denselben Job möglicherweise die Synchronous Pull-Messwerte für einen bestimmten Zeitraum und die Streaming Pull-Messwerte für einen anderen Zeitraum angezeigt. Nach Abschluss der Migration werden die Synchronous Pull-Messwerte von der Benutzeroberfläche entfernt.
Die Migration wirkt sich auch auf die Messwerte job/pubsub/read_count und job/pubsub/read_latencies in Cloud Monitoring aus. Diese Zähler werden während der Verwendung eines Streaming Pull-Jobs nicht erhöht.
Streamingjobs, die keine Streaming Engine verwenden, werden nicht zu Streaming Pull migriert und sind von dieser Änderung nicht betroffen. Sie zeigen weiterhin die Synchronous Pull-Messwerte an.
Weitere Informationen zur Streaming Pull-Migration finden Sie auf der Seite Streaming mit Pub/Sub.
Bei Fragen zu dieser Änderung wenden Sie sich bitte an Ihr Account-Management-Team.