Bearbeiten

Überwachen von Azure Functions und Event Hubs

Azure Event Hubs
Azure-Funktionen
Azure Monitor

Überwachung bietet Einblicke in das Verhalten und die Integrität Ihrer Systeme und hilft dabei, eine ganzheitliche Ansicht der Umgebung und historische Trends zu erhalten, verschiedene Faktoren zu korrelieren und Änderungen bei Leistung, Verbrauch oder Fehlerrate zu messen.

Azure Functions bietet integrierte Integration in Application Insights. Aus Application Insights können Sie Informationen wie die Anzahl von Funktions-App-Instanzen oder Anforderungs- und Abhängigkeitstelemetriedaten einer Funktion erhalten. Bei der Arbeit mit Functions und Event Hubs kann Application Insights auch die ausgehenden Abhängigkeitstelemetriedaten an den Event Hub nachverfolgen, die in der Warteschlange verbrachte Zeit berechnen und den End-to-End-Flow des Systems anzeigen, das über Event Hubs verbunden ist.

In diesem Abschnitt werden nützliche Features und Erkenntnisse eingeführt, die Sie über Application Insights für Ihre Event Hubs- mit Functions-Lösung erhalten können.

Anwendungszuordnung

Die Anwendungsübersicht zeigt, wie die Komponenten in einem System miteinander interagieren. Aufgrund der von Application Insights zur Verfügung gestellten Abhängigkeitstelemetriedaten wird eine Übersicht des Ereignisflusses zwischen Azure Functions und Event Hubs erstellt, einschließlich des Durchschnitts jeder Funktionsausführung und der durchschnittlichen Dauer eines Ereignisses in Event Hubs, sowie der Transaktionen, die rot markierte Fehler enthalten.

Nachdem Sie die erwartete Auslastung an Ihr System gesendet haben, können Sie im Azure-Portal zu Application Insights wechseln und auf der Randleiste Anwendungsübersicht auswählen. Hier sehen Sie eine Übersicht, die drei Funktionen, drei Event Hubs und offensichtliche Fehler beim Schreiben in eine Downstreamdatenbank zeigt:

Anwendungszuordnung

End-to-End-Transaktionsdetails

End-to-End-Transaktionsdetails zeigen in chronologischer Reihenfolge, wie Ihre Systemkomponenten miteinander interagieren. Diese Ansicht zeigt auch, wie viel Zeit ein Ereignis in der Warteschlange verbracht hat. Sie können in dieser Ansicht auch einen Drilldown in die Telemetriedaten der einzelnen Komponenten durchführen, was die komponentenübergreifende Problembehandlung innerhalb derselben Anforderung vereinfacht, wenn ein Problem aufgetreten ist.

End-to-End-Transaktion

Plattformmetriken und Telemetriedaten

Plattformgenerierte Metriken in Azure Monitor für Event Hubs und Azure Functions können für die allgemeine Überwachung des Lösungsverhaltens und der Integrität verwendet werden:

Azure Functions integriert sich in Application Insights, um erweiterte und detaillierte Telemetriedaten und Erkenntnisse über den Functions-Host und die Funktionsausführungen bereitzustellen. Weitere Informationen finden Sie unter Analysieren von Azure Functions-Telemetriedaten in Application Insights. Wenn Sie Application Insights für die Überwachung einer Topologie verwenden, steht Ihnen eine Vielzahl von Konfigurationen zur Verfügung. Weitere Informationen finden Sie unter Konfigurieren der Überwachung für Azure Functions.

Im Folgenden finden Sie ein Beispiel für zusätzliche Telemetriedaten für von Event Hubs ausgelöste Funktionen, die in der Ablaufverfolgungstabelle generiert werden:

Trigger Details: PartionId: 6, Offset: 3985758552064-3985758624640, EnqueueTimeUtc: 2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00, SequenceNumber: 3712266-3712275, Count: 10

Diese Informationen erfordern, dass Sie Event Hubs 4.2.0 oder eine höhere Version verwenden. Diese Daten sind sehr nützlich, da sie Informationen über die Nachricht enthalten, die die Funktionsausführung ausgelöst hat, und für Abfragen und Erkenntnisse verwendet werden können. Sie enthalten die folgenden Daten für jede Auslösung der Funktion:

  • Die Partitions-ID (6)
  • Den Bereich des Partitionsoffsets (3985758552064-3985758624640)
  • Den Zeitbereich für das Einreihen in die Warteschlange in UTC (2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00)
  • Den Sequenznummernbereich 3712266-3712275
  • Die Nachrichtenanzahl (10)

Beispiele zur Verwendung dieser Telemetriedaten finden Sie unter Application Insights-Beispielabfragen.

Benutzerdefinierte Telemetriedaten sind auch für verschiedene Sprachen möglich (C#-Klassenbibliothek, C# Isolated, C# Script, JavaScript, Java, PowerShell und Python). Diese Protokollierung wird in der Ablaufverfolgungstabelle in Application Insights angezeigt. Sie können eigene Einträge in Application Insights erstellen und benutzerdefinierte Dimensionen hinzufügen, die zum Abfragen von Daten sowie zum Erstellen benutzerdefinierter Dashboards verwendet werden können.

Schließlich werden Einträge auch in die Application Insights-Tabelle „Abhängigkeiten“ geschrieben, wenn Ihre Funktions-App mithilfe einer Ausgabebindung eine Verbindung mit einem Event Hub herstellt.

Tabelle „Abhängigkeiten“

Für Event Hubs wird die Korrelation in die Ereignisnutzdaten eingefügt, und Sie sehen eine Eigenschaft Diagnostic-Id in den Ereignissen:

Eigenschaft „Diagnose-ID“

Diese hält das W3C-Ablaufverfolgungskontext-Format ein, das auch als Vorgangs-ID und Vorgangslinks in von Functions erstellten Telemetriedaten verwendet wird. Dadurch kann Application Insights die Korrelation zwischen Event Hub-Ereignissen und Funktionsausführungen herstellen, auch wenn diese verteilt sind.

Korrelation von Batchereignissen

Application Insights-Beispielabfragen

Im Folgenden finden Sie eine Liste hilfreicher Application Insights-Abfragen für die Überwachung von Event Hubs mit Azure Functions. Diese Abfragen zeigen detaillierte Informationen für die vom Event Hub ausgelöste Funktion an, wobei Telemetriedaten verwendet werden, die von der Event Hubs-Erweiterung 4.2.0 oder höher ausgegeben werden.

Wenn in Application Insights die Stichprobenentnahme aktiviert ist, können Lücken in den Daten bestehen.

Ausführliche Informationen zur Ereignisverarbeitung

Die Daten werden nur im richtigen Format ausgegeben, wenn Batchversand verwendet wird. Batchversand bedeutet, dass die Funktion mehrere Ereignisse für jede Ausführung akzeptiert, was unter Leistungsgesichtspunkten empfohlen wird. Beachten Sie dabei die folgenden Aspekte:

  • Der Wert dispatchTimeMilliseconds ist eine Annäherung der Zeit zwischen dem Schreiben des Ereignisses in Event Hub und dem Zeitpunkt, zu dem es von der Funktions-App für die Verarbeitung erfasst wurde.
  • dispatchTimeMilliseconds kann aufgrund von Uhrdrift zwischen dem Event Hub-Server und der Funktions-App negativ oder anderweitig ungenau sein.
  • Event Hubs-Partitionen werden sequenziell verarbeitet. Eine Nachricht wird erst dann zur Verarbeitung an Funktionscode versendet, wenn alle vorherigen Nachrichten verarbeitet wurden. Überwachen Sie die Ausführungszeit Ihrer Funktionen, da längere Ausführungszeiten zu Verzögerungen beim Versand führen.
  • Die Berechnung verwendet die „enqueueTime“ der ersten Nachricht im Batch. Die Versandzeiten für andere Nachrichten im Batch sind möglicherweise niedriger (kürzer).
  • dispatchTimeMilliseconds basiert auf dem Zeitpunkt.
  • Sequenznummern sind partitionsspezifische Werte, und es kann zu doppelter Verarbeitung kommen, weil Event Hubs keine exakt einmalige Nachrichtenübermittlung garantiert.
traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| project timestamp, cloud_RoleInstance, operation_Name, processId =
customDimensions.ProcessId, partitionId, messageCount, sequenceNumberStart,
sequenceNumberEnd, enqueueTimeStart, enqueueTimeEnd, dispatchTimeMilliseconds

Detaillierte Ereignisverarbeitung

Visualisierung der Versandlatenz

Diese Abfrage visualisiert die Ereignisversandlatenz des 50. und 90. Perzentils für eine bestimmte von Event Hub ausgelöste Funktion. Weitere Details und Anmerkungen finden Sie in der obigen Abfrage.

traces
| where operation_Name == "<ENTER THE NAME OF YOUR FUNCTION HERE>"
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize percentiles(dispatchTimeMilliseconds, 50, 90) by bin(timestamp, 5m)
| render timechart

Visualisierung der Versandlatenz

Zusammenfassung der Versandlatenz

Diese Abfrage ähnelt der obigen, zeigt jedoch eine Zusammenfassungsansicht an.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize messageCount = sum(messageCount),
percentiles(dispatchTimeMilliseconds, 50, 90, 99, 99.9, 99.99) by operation_Name

Zusammenfassung der Versandlatenz

Verteilung von Nachrichten auf Partitionen

Diese Abfrage zeigt, wie die Verteilung von Nachrichten auf Partitionen visualisiert wird.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Verteilung von Nachrichten auf Partitionen

Nachrichtenverteilung auf Instanzen

Diese Abfrage zeigt, wie die Verteilung von Nachrichten auf Instanzen visualisiert wird.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Nachrichtenverteilung auf Instanzen

Ausführen von Instanzen und zugeordneten Instanzen

Diese Abfrage zeigt, wie die Anzahl der Azure Functions-Instanzen, die Ereignisse von Event Hubs verarbeiten, sowie die Gesamtzahl der Instanzen (verarbeitend und auf Lease wartend) visualisiert wird. Die meiste Zeit sollten sie identisch sein.

traces
| where message startswith "Trigger Details: Parti"
| summarize type = "Executing Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
| union (
    traces
    | summarize type = "Allocated Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
)
| project timestamp, type, Count
| render timechart

Ausführen von Instanzen und zugeordneten Instanzen

Alle Telemetriedaten für eine bestimmte Funktionsausführung

Das Feld operation_Id kann in den verschiedenen Tabellen in Application Insights verwendet werden. Bei von Event Hubs ausgelösten Azure Functions führt die folgende Abfrage beispielsweise zu den Triggerinformationen, Telemetriedaten aus Protokollen im Funktionscode sowie Abhängigkeiten und Ausnahmen:

union isfuzzy=true requests, exceptions, traces, dependencies
| where * has "<ENTER THE OPERATION_ID OF YOUR FUNCTION EXECUTION HERE>"
| order by timestamp asc

Alle Telemetriedaten für eine bestimmte Funktionsausführung

End-to-End-Latenz für ein Ereignis

Da die enqueueTimeUtc-Eigenschaft in der Triggerdetail-Ablaufverfolgung nur die Zeit der Einreihung in die Warteschlange für das erste Ereignis jedes Batches zeigt, den die Funktion verarbeitet hat, kann eine komplexere Abfrage verwendet werden, um die End-to-End-Latenz von Ereignissen zwischen zwei Funktionen mit dazwischen liegenden Event Hubs zu berechnen. Diese Abfrage erweitert die Vorgangslinks (sofern vorhanden) in der Anforderung der zweiten Funktion und ordnet deren Endzeit derselben entsprechenden Vorgangs-ID der Startzeit der ersten Funktion zu.

let start = view(){
requests
| where operation_Name == "FirstFunction"
| project start_t = timestamp, first_operation_Id = operation_Id
};
let link = view(){
requests
| where operation_Name == "SecondFunction"
| mv-expand ex = parse_json(tostring(customDimensions["_MS.links"]))
| extend parent = case(isnotempty(ex.operation_Id), ex.operation_Id, operation_Id )
| project first_operation_Id = parent, second_operation_Id = operation_Id
};
let finish = view(){
traces
| where customDimensions["EventName"] == "FunctionCompleted" and operation_Name
== "SecondFunction"
| project end_t = timestamp, second_operation_Id = operation_Id
};
start
| join kind=inner (
link
| join kind=inner finish on second_operation_Id
) on first_operation_Id
| project start_t, end_t, first_operation_Id, second_operation_Id
| summarize avg(datetime_diff('second', end_t, start_t))

End-to-End-Latenz für ein Ereignis

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Weitere Informationen finden Sie in diesen verwandten Artikel: