Analysieren der Azure Stream Analytics-Auftragsleistung mithilfe von Metriken und Dimensionen

Um die Integrität eines Azure Stream Analytics-Auftrags zu verstehen, ist es wichtig zu wissen, wie die Metriken und Dimensionen des Auftrags genutzt werden können. Sie können das Azure-Portal, die Stream Analytics-Erweiterung von Visual Studio Code oder ein SDK verwenden, um die Metriken und Dimensionen zu erhalten, an denen Sie interessiert sind.

In diesem Artikel erfahren Sie, wie Sie Metriken und Dimensionen für Stream Analytics-Aufträge verwenden können, um die Leistung eines Auftrags über das Azure-Portal zu analysieren.

Wasserzeichenverzögerung und Eingabeereignisse im Rückstand sind die wichtigsten Metriken zur Bestimmung der Leistung Ihres Stream Analytics-Auftrags. Wenn die Wasserzeichenverzögerung Ihres Auftrags kontinuierlich ansteigt und es zu einem Rückstand von Eingabeereignissen kommt, kann Ihr Auftrag nicht mit der Rate der Eingabeereignisse Schritt halten und rechtzeitig Ausgaben produzieren.

Sehen wir uns einige Beispiele an, um die Leistung eines Auftrags anhand der Metrik für die Wasserzeichenverzögerung zu analysieren.

Keine Eingabe für eine bestimmte Partition erhöht die Wasserzeichenverzögerung des Auftrags

Wenn die Wasserzeichenverzögerung Ihres hochgradig parallelen Auftrags stetig zunimmt, wechseln Sie zu Metriken. Verwenden Sie dann diese Schritte, um herauszufinden, ob die Ursache ein Mangel an Daten in einigen Partitionen Ihrer Eingabequelle ist:

  1. Überprüfen Sie, welche Partition die zunehmende Wasserzeichenverzögerung aufweist. Wählen Sie die Metrik Wasserzeichenverzögerung aus, und teilen Sie sie durch die Dimension Partitions-ID. In dem folgenden Beispiel weist die Partition 465 eine hohe Wasserzeichenverzögerung auf.

    Screenshot: Diagramm, das die Aufteilung der Wasserzeichenverzögerung nach Partitions-ID für den Fall zeigt, dass in einer Partition keine Eingabe erfolgt

  2. Überprüfen Sie, ob Eingabedaten für diese Partition fehlen. Wählen Sie die Metrik Eingabeereignisse aus, und filtern Sie sie nach dieser speziellen Partitions-ID.

    Screenshot: Diagramm, das die Aufteilung der Eingabeereignisse nach Partitions-ID für den Fall zeigt, dass in einer Partition keine Eingabe erfolgt

Welche weiteren Maßnahmen können Sie ergreifen?

Die Wasserzeichenverzögerung für diese Partition nimmt zu, da keine Eingabeereignisse in diese Partition fließen. Wenn das Toleranzfenster für die Eingangsverzögerung Ihres Auftrags mehrere Stunden beträgt und keine Eingabedaten in eine Partition fließen, wird die Wasserzeichenverzögerung für diese Partition voraussichtlich weiter ansteigen, bis das Fenster für die Eingangsverzögerung erreicht ist.

Wenn z. B. Ihr Fenster für die Eingangsverzögerung sechs Stunden beträgt und die Eingabedaten nicht in die Eingabepartition 1 fließen, wird die Wasserzeichenverzögerung für die Ausgabepartition 1 erhöht, bis sie sechs Stunden erreicht. Sie können überprüfen, ob Ihre Eingabequelle wie erwartet Daten erzeugt.

Eingabedatenschiefe verursacht hohe Wasserzeichenverzögerung

Wie bereits im vorherigen Fall erwähnt, müssen Sie bei einem hochgradig parallelen Auftrag mit einer hohen Wasserzeichenverzögerung zunächst die Metrik Wasserzeichenverzögerung durch die Dimension Partitions-ID teilen. Sie können dann feststellen, ob alle Partitionen eine hohe Wasserzeichenverzögerung aufweisen oder nur einige von ihnen.

Im folgenden Beispiel haben die Partitionen 0 und 1 eine höhere Wasserzeichenverzögerung (etwa 20 bis 30 Sekunden) als die anderen acht Partitionen. Die Wasserzeichenverzögerungen der anderen Partitionen liegen immer gleichbleibend bei etwa 8 bis 10 Sekunden.

Screenshot: Diagramm, das die Wasserzeichenverzögerung aufgeteilt nach Partitions-ID für den Fall einer Datenschiefe zeigt

Lassen Sie uns dann überprüfen, wie die Eingabedaten für alle diese Partitionen mit der Metrik Eingabeereignisse aufgeteilt nach Partitions-ID aussehen:

Screenshot: Diagramm, das die Eingabeereignisse aufgeteilt nach Partitions-ID für den Fall einer Datenschiefe zeigt

Welche weiteren Maßnahmen können Sie ergreifen?

Wie im Beispiel gezeigt, erhalten die Partitionen (0 und 1), die eine hohe Wasserzeichenverzögerung aufweisen, deutlich mehr Eingabedaten als andere Partitionen. Wir bezeichnen dies als Datenschiefe. Die Streamingknoten, die die Partitionen mit Datenschiefe verarbeiten, müssen mehr CPU- und Arbeitsspeicherressourcen verbrauchen als andere, wie der folgende Screenshot zeigt.

Screenshot: Diagramm, das die Ressourcenauslastung von Partitionen mit Datenschiefe zeigt

Streamingknoten, die Partitionen mit höherer Datenschiefe verarbeiten, weisen eine höhere CPU- und/oder Streamingeinheitsauslastung (SU) auf. Diese Nutzung beeinträchtigt die Leistung des Auftrags und erhöht die Wasserzeichenverzögerung. Um dies zu entschärfen, müssen Sie Ihre Eingabedaten gleichmäßiger aufteilen.

Sie können dieses Problem auch mit einem physischen Auftragsdiagramm debuggen. Siehe hierzu :Physisches Auftragsdiagramm: Identifizieren der ungleichmäßig verteilten Eingabeereignisse (Datenschiefe).

Überlasteter CPU oder überlasteter Arbeitsspeicher erhöhen die Wasserzeichenverzögerung

Wenn ein hochgradig paralleler Auftrag eine zunehmende Wasserzeichenverzögerung aufweist, kann dies nicht nur auf einer oder mehreren Partitionen, sondern auf allen Partitionen geschehen. Wie können Sie feststellen, ob Ihr Auftrag in diesen Fall fällt?

  1. Teilen Sie die Metrik Wasserzeichenverzögerung durch Partitions-ID auf. Beispiel:

    Screenshot: Diagramm, das die Wasserzeichenverzögerung aufgeteilt nach Partitions-ID für den Fall einer überlasteten CPU oder von überlastetem Arbeitsspeicher zeigt

  2. Teilen Sie die Metrik Eingabeereignisse nach Partitions-ID auf, um festzustellen, ob es bei den Eingabedaten für jede Partition eine Datenschiefe gibt.

  3. Überprüfen Sie die CPU- und SU-Auslastung, um festzustellen, ob die Auslastung in allen Streamingknoten zu hoch ist.

    Screenshot: Diagramm, das die CPU- und Arbeitsspeicherauslastung aufgeteilt nach Knotennamen für den Fall einer überlasteten CPU und eines überlasteten Arbeitsspeichers zeigt

  4. Wenn die CPU- und SU-Auslastung in allen Streamingknoten sehr hoch ist (mehr als 80 Prozent), können Sie daraus schließen, dass bei diesem Auftrag in jedem Streamingknoten eine große Datenmenge verarbeitet wird.

    Sie können außerdem überprüfen, wie viele Partitionen einem Streamingknoten zugeordnet sind, indem Sie die Metrik Eingabeereignisse überprüfen. Filtern Sie nach der ID des Streamingknotens mit der Dimension Knotenname, und teilen Sie nach Partitions-ID auf.

    Screenshot: Diagramm, das die Anzahl der Partitionen auf einem Streamingknoten für den Fall einer überlasteten CPU und eines überlasteten Arbeitsspeichers zeigt

  5. Der vorangehende Screenshot zeigt, dass einem Streamingknoten vier Partitionen zugeordnet sind, die etwa 90 bis 100 Prozent der Streamingknotenressourcen beanspruchen. Sie können einen ähnlichen Ansatz verwenden, um die übrigen Streamingknoten zu überprüfen, um sicherzustellen, dass sie ebenfalls Daten aus vier Partitionen verarbeiten.

Welche weiteren Maßnahmen können Sie ergreifen?

Möglicherweise sollten Sie die Anzahl der Partitionen für jeden Streamingknoten verringern, um die Eingabedaten für jeden Streamingknoten zu reduzieren. Um dies zu erreichen, können Sie die SUs verdoppeln, damit jeder Streamingknoten die Daten von zwei Partitionen verarbeiten kann. Oder Sie können die SUs vervierfachen, damit jeder Streamingknoten die Daten einer Partition verarbeiten kann. Informationen über die Beziehung zwischen SU-Zuweisung und Anzahl der Streamingknoten finden Sie unter Verstehen und Anpassen von Streamingeinheiten.

Wie können Sie vorgehen, wenn die Wasserzeichenverzögerung weiter zunimmt, während ein Streamingknoten die Daten von einer Partition bearbeitet? Partitionieren Sie Ihre Eingabe mit mehreren Partitionen neu, um die Datenmenge in jeder Partition zu reduzieren. Weitere Informationen finden Sie unter Verwenden der Neupartitionierung zur Optimierung von Azure Stream Analytics-Aufträgen.

Sie können dieses Problem auch mit einem physischen Auftragsdiagramm debuggen. Siehe hierzu :Physisches Auftragsdiagramm: Identifizieren der ungleichmäßig verteilten Eingabeereignisse (Datenschiefe).

Nächste Schritte