Problembehandlung von Azure Stream Analytics-Ausgaben

In diesem Artikel werden häufige Probleme mit Azure Stream Analytics Ausgabeverbindungen und deren Problembehandlung beschrieben. Zu den abgedeckten Problemen gehören Jobs, die keine Ausgabe erzeugen, eine verzögerte erste Ausgabe, eine Ausgabe, die ins Hintertreffen gerät, Schlüsselverletzungen in Azure SQL-Datenbank und das SQL-Verhalten bei Wiederholungsversuchen. Für viele Schritte zur Problembehandlung müssen Ressourcenprotokolle und andere Diagnoseprotokolle für Ihren Stream Analytics-Job aktiviert sein. Wenn Sie Ressourcenprotokolle nicht aktiviert haben, finden Sie weitere Informationen unter Problembehandlung von Azure Stream Analytics mit Ressourcenprotokollen.

Der Job erzeugt keine Ausgabe.

  1. Überprüfen Sie die Verbindung zu jeder Ausgabe mithilfe der Schaltfläche Verbindung testen.

  2. Schauen Sie sich Überwachen des Stream Analytics-Auftrags im Azure-Portal auf der Registerkarte Überwachen an. Da die Werte aggregiert werden, werden die Metriken um einige Minuten verzögert angezeigt.

    • Wenn der Wert Eingabeereignisse größer als 0 ist, kann die Aufgabe die Eingabedaten lesen. Wenn der Wert Eingabeereignisse nicht größer als null ist, liegt ein Problem mit der Eingabe des Auftrags vor. Weitere Informationen finden Sie unter Problembehandlung von Eingabeverbindungen. Wenn Ihr Job über eine Eingabe von Referenzdaten verfügt, wenden Sie bei der Metrik Eingabeereignisse die Aufschlüsselung nach logischem Namen an. Wenn es keine Eingabeereignisse aus Ihren Referenzdaten allein gibt, bedeutet dies wahrscheinlich, dass diese Eingabequelle nicht ordnungsgemäß konfiguriert wurde, um das richtige Referenzdatenset abzurufen.
    • Wenn der Wert Datenkonvertierungsfehler größer als null und ansteigend ist, finden Sie unter Datenfehler in Azure Stream Analytics ausführliche Informationen zu Datenkonvertierungsfehlern.
    • Wenn der Wert Laufzeitfehler größer als null ist, empfängt der Auftrag Daten, generiert jedoch beim Verarbeiten der Abfrage Fehler. Navigieren Sie zur Fehlersuche zu Überwachungsprotokolle, und filtern Sie dann nach dem Status Fehler.
    • Wenn der Wert Eingabeereignisse größer als null und der Wert Ausgabeereignisse gleich null ist, gilt eine der folgenden Aussagen:
      • Die Abfrageverarbeitung führte zu null Ausgabeereignissen.
      • Ereignisse oder Felder könnten fehlerhaft formatiert sein, was nach der Abfrageverarbeitung zu einer Ausgabe von null führt.
      • Der Auftrag konnte die Daten aus Konnektivitäts- oder Authentifizierungsgründen nicht an die Ausgabesenke übertragen.

    Die Meldungen der Vorgangsprotokolle enthalten weitere Details, einschließlich Details zu den Vorgängen. Ausgenommen sind Fälle, in denen die Abfragelogik alle Ereignisse herausfiltert. Wenn die Verarbeitung für mehrere Ereignisse Fehler generiert, werden die Fehler alle 10 Minuten aggregiert.

Verzögerung bei der ersten Ausgabe

Wenn ein Stream Analytics-Auftrag gestartet wird, werden die Eingabeereignisse gelesen. Unter bestimmten Umständen kann es jedoch zu einer Verzögerung bei der Ausgabe kommen.

Große Zeitwerte in zeitlichen Abfrageelementen können zur Ausgabeverzögerung beitragen. Um über große Zeitfenster hinweg die korrekte Ausgabe zu erzeugen, liest der Streaming-Job Daten vom spätestmöglichen Zeitpunkt an, um das Zeitfenster zu füllen. Die Daten können bis zu sieben Tage in der Vergangenheit liegen. Es wird keine Ausgabe erzeugt, bis die ausstehenden Eingabeereignisse gelesen werden. Dieses Problem kann auftreten, wenn das System ein Upgrade der Streamingaufträge ausführt. Bei einem Upgrade wird der Auftrag neu gestartet. Solche Upgrades finden in der Regel alle paar Monate statt.

Gehen Sie beim Entwerfen Ihrer Stream Analytics-Abfrage mit Bedacht vor. Wenn Sie ein großes Zeitfenster für temporale Elemente in der Abfragesyntax des Auftrags verwenden, kann dies zu einer Verzögerung bei der ersten Ausgabe beim Start oder Neustart des Auftrags führen. Als großes Zeitfenster wird eine längere Zeit als mehrere Stunden (bis zu sieben Tage) angesehen.

Eine Lösung für diese Art einer Verzögerung der ersten Ausgabe ist die Verwendung von Abfrageparallelisierungstechniken, z. B. Partitionierung der Daten. Oder Sie können weitere Streamingeinheiten hinzufügen, um den Durchsatz zu verbessern, bis der Auftrag aufgeholt hat. Weitere Informationen finden Sie unter Überlegungen beim Erstellen von Stream Analytics-Aufträgen.

Diese Faktoren haben Auswirkungen auf die Zeit bis zur ersten Ausgabe:

  • Die Verwendung von fensterbasierten Aggregaten, etwa einer GROUP-BY-Klausel für Tumbling-, Hopping- und gleitende Fenster:

    • Für Aggregate von rollierenden oder springenden Fenstern werden die Ergebnisse am Ende des Fensterzeitraums generiert.
    • Für ein gleitendes Fenster werden die Ergebnisse generiert, wenn ein Ereignis in das gleitende Fenster eintritt oder dieses verlässt.
    • Wenn Sie die Verwendung eines großen Fensters planen (z. B. mehr als eine Stunde), empfiehlt es sich, ein springendes oder gleitendes Fenster auszuwählen. Mit diesen Fenstertypen können Sie die Ausgabe häufiger sehen.

  • Verwendung von temporalen Joins (z. B. JOIN mit DATEDIFF):

    • Übereinstimmungen werden generiert, sobald beide Seiten der übereinstimmenden Ereignisse eintreten.
    • Daten, für die es keine Entsprechung gibt, werden, wie bei LEFT OUTER JOIN, am Ende des DATEDIFF-Fensters für jedes Ereignis auf der linken Seite erzeugt.

  • Verwendung von temporalen Analysefunktionen (etwa ISFIRST, LAST und LAG mit LIMIT DURATION):

    • Bei analytischen Funktionen wird die Ausgabe für jedes Ereignis generiert. Es gibt keine Verzögerung.

Die Ausgabe hinkt mit zunehmender Latenz hinterher

Während des normalen Betriebs eines Auftrags kann die Ausgabe immer längere Verzögerungen aufweisen. Wenn die Ausgabe auf diese Weise zurückfällt, können Sie die Grundursachen durch Untersuchen der folgenden Faktoren ermitteln:

  • Ob die Downstreamsenke gedrosselt wird.
  • Ob die Upstreamquelle gedrosselt wird.
  • Ob die Verarbeitungslogik in der Abfrage rechenintensiv ist.

Um die Ausgabedetails anzuzeigen, wählen Sie im Azure-Portal den Streamingauftrag und dann Auftragsdiagramm aus. Für jede Eingabe gibt es eine Backlogereignismetrik pro Partition. Wenn die Metrik weiter ansteigt, weist dies auf begrenzte Systemressourcen hin. Diese Steigung kann auf eine Drosselung der Ausgabesenke oder eine hohe CPU-Auslastung zurückzuführen sein. Weitere Informationen finden Sie unter Datengesteuertes Debuggen mithilfe des Auftragsdiagramms.

Warnung vor Schlüsselkonflikten bei der Azure SQL-Datenbankausgabe

Wenn Sie eine Azure SQL-Datenbank-Instanz als Ausgabe für einen Stream Analytics-Auftrag konfigurieren, werden Datensätze als Masseneintrag in der Zieltabelle hinzugefügt. Grundsätzlich garantiert Azure Stream Analytics eine mindestens einmalige Zustellung an die Ausgabesenke. Sie können nach wie vor eine Genau-einmal-Übermittlung in eine SQL-Ausgabe erreichen, wenn für eine SQL-Tabelle eine eindeutige Einschränkung definiert ist.

Wenn Sie Einschränkungen für eindeutige Schlüssel in der SQL-Tabelle einrichten, entfernt Azure Stream Analytics doppelte Datensätze. Es teilt die Daten in Batches auf und fügt diese rekursiv ein, bis ein einziger doppelter Datensatz gefunden wird. Beim Aufteilen und Einfügen werden die Duplikate einzeln ignoriert. Bei einem Streamingauftrag mit vielen doppelten Zeilen ist dieses Verfahren ineffizient und zeitaufwendig. Wenn Sie in Ihrem Aktivitätsprotokoll für die vergangene Stunde mehrere Warnmeldungen zu Schlüsselverletzungen sehen, verlangsamt Ihre SQL-Ausgabe wahrscheinlich den gesamten Job.

Um dieses Problem zu beheben, konfigurieren Sie den Index, der die Schlüsselverstöße verursacht, indem Sie die Option IGNORE_DUP_KEY aktivieren. Diese Option ermöglicht es SQL, doppelte Werte bei Masseneinfügungen zu ignorieren. Azure SQL-Datenbank gibt lediglich eine Warnmeldung anstelle eines Fehlers aus. Dies führt dazu, dass Azure Stream Analytics keine Fehler aufgrund von Primärschlüsselverletzungen mehr erzeugt.

Beachten Sie die folgenden Beobachtungen, wenn Sie IGNORE_DUP_KEY für mehrere Typen von Indizes konfigurieren:

  • IGNORE_DUP_KEY kann nicht für einen Primärschlüssel oder eine UNIQUE-Einschränkung festgelegt werden, die ALTER INDEX verwendet. Sie müssen den Index löschen und neu erstellen.
  • Sie können IGNORE_DUP_KEY mithilfe von ALTER INDEX für einen eindeutigen Index festlegen. Diese Instanz unterscheidet sich von einer PRIMARY KEY-/UNIQUE-Einschränkung und wird mithilfe einer CREATE INDEX- oder INDEX-Definition erstellt.
  • Die Option IGNORE_DUP_KEY gilt nicht für ColumnStore-Indizes, da für diese keine Eindeutigkeit erzwungen werden kann.

Wiederholungslogik für die Azure SQL-Datenbankausgabe

Wenn ein Stream Analytics-Auftrag mit SQL-Ausgabe den ersten Batch von Ereignissen empfängt, werden die folgenden Schritte ausgeführt:

  1. Es wird versucht, eine Verbindung mit SQL herzustellen.
  2. Der Job ruft das Schema der Zieltabelle ab.
  3. Der Auftrag validiert Spaltennamen und -typen anhand des Schemas der Zieltabelle.
  4. Der Job erstellt aus den Ausgabedatensätzen im Batch eine Datentabelle im Arbeitsspeicher.
  5. Der Job schreibt die Datentabelle mithilfe der BulkCopy-API in SQL.

Während dieser Schritte kann die SQL-Ausgabe die folgenden Fehlertypen aufweisen:

  • Vorübergehende Fehler, bei denen eine Wiederholungsstrategie mit exponentiellem Backoff zur Anwendung kommt. Das Mindestwiederholungsintervall hängt zwar vom jeweiligen Fehlercode ab, die Intervalle betragen jedoch in der Regel weniger als 60 Sekunden. Die Obergrenze liegt bei fünf Minuten.

    Bei Anmeldefehlern und Firewallproblemen wird der entsprechende Vorgang mindestens fünf Minuten nach dem vorherigen Versuch wiederholt, bis er erfolgreich ist.

  • Datenfehler wie etwa Umwandlungsfehler und Schemaeinschränkungsverletzungen werden per Ausgabefehlerrichtlinie behandelt. Diese Fehler werden behandelt, indem binär geteilte Batches so lange erneut versucht werden, bis der einzelne Datensatz, der den Fehler verursacht, übersprungen oder erneut verarbeitet wird. Ein Verstoß gegen die Primär-/Unique-Key-Einschränkung wird immer behandelt.

  • Nicht vorübergehende Fehler können auf Probleme mit dem SQL-Dienst oder auf interne Codefehler zurückzuführen sein. Wenn z. B. Fehler wie (Code 1132) Elastic Pool auf das Speicherlimit stoßen, beheben Wiederholungen den Fehler nicht. In diesen Szenarien kommt es zu einer Beeinträchtigung des Stream Analytics-Auftrags.

  • BulkCopy-Timeouts können während BulkCopy in Schritt 5 auftreten. Für BulkCopy kann es gelegentlich zu Vorgangstimeouts kommen. Der standardmäßig konfigurierte Mindestwert für das Timeout ist auf fünf Minuten festgelegt und wird verdoppelt, wenn er wiederholt erreicht wird. Wenn das Timeout 15 Minuten übersteigt, wird der Hinweis für die maximale Batchgröße für BulkCopy auf die Hälfte reduziert, bis nur noch 100 Ereignisse pro Batch vorhanden sind.

    Wichtig

    Verlassen Sie sich bei nicht netzwerkinjizierten ASA-Aufträgen nicht auf die IP-Quelladresse von Verbindungen, die von ASA stammen. Es kann sich um öffentliche oder private IPs handeln. Dies hängt von Dienstinfrastrukturvorgängen ab, die von Zeit zu Zeit auftreten.

Spaltennamen werden in Azure Stream Analytics (1.0) in Kleinbuchstaben umgewandelt.

Bei Verwendung des ursprünglichen Kompatibilitätsgrads (1.0) werden Spaltennamen von Azure Stream Analytics in Kleinbuchstaben geändert. Dieses Verhalten wurde bei höheren Kompatibilitätsgraden behoben. Um die Schreibweise beizubehalten, wechseln Sie auf Kompatibilitätsstufe 1.1 oder höher. Weitere Informationen finden Sie unter Kompatibilitätsgrad für Stream Analytics-Aufträge.

Hier erhalten Sie Hilfe

Weitere Unterstützung finden Sie auf der Frageseite von Microsoft Q&A (Fragen und Antworten) zu Azure Stream Analytics.

Nächste Schritte

  • Last updated on