Überwachung der serverlosen Ereignisverarbeitung

Dieser Artikel enthält einen Leitfaden zur Überwachung serverloser ereignisgesteuerter Architekturen.

Die Überwachung bietet Einblicke in das Verhalten und die Integrität Ihrer Systeme. Sie hilft Ihnen, eine ganzheitliche Ansicht der Umgebung zu erstellen, historische Trends abzurufen, verschiedene Faktoren zu korrelieren und Änderungen in Leistung, Verbrauch oder Fehlerrate zu messen. Sie können die Überwachung verwenden, um Warnungen zu definieren, wenn Bedingungen auftreten, die sich auf die Qualität Ihres Diensts auswirken können, oder wenn Bedingungen auftreten, die für Ihre spezifische Umgebung von besonderem Interesse sind.

In diesem Artikel wird die Verwendung von Azure Monitor zum Überwachen einer serverlosen Anwendung veranschaulicht, die mit Event Hubs und Azure Functions erstellt wurde. Er erläutert nützliche zu überwachende Metriken, beschreibt die Integration in Application Insights und erfasst benutzerdefinierte Metriken und stellt Codebeispiele bereit.

Annahmen

In diesem Artikel wird davon ausgegangen, dass Sie über eine Architektur wie die in der Referenzarchitektur serverlose Ereignisverarbeitung beschriebenen Architektur verfügen. Im Grunde funktioniert das folgendermaßen:

• Ereignisse treffen auf Azure Event Hubs ein.
• Eine Funktions-App wird ausgelöst, um das Ereignis zu bearbeiten.
• Azure Monitor ist für die Verwendung mit Ihrer Architektur verfügbar.

Metriken aus Azure Monitor

Zunächst müssen wir entscheiden, welche Metriken benötigt werden, bevor wir damit beginnen können, nützliche Erkenntnisse über die Architektur zu formulieren. Jede Ressource führt unterschiedliche Aufgaben aus und generiert wiederum unterschiedliche Metriken.

Diese Metriken von Event Hub sind von Interesse, um nützliche Erkenntnisse zu erfassen:

• Eingehende Anforderungen
• Ausgehende Anforderungen
• Gedrosselte Anforderungen
• Erfolgreiche Anforderungen
• Eingehende Nachrichten
• Ausgehende Nachrichten
• Erfasste Nachrichten
• Eingehende Bytes
• Ausgehende Bytes
• Erfasste Bytes
• Benutzerfehler

Ebenso sind diese Metriken aus Azure Functions von Interesse, um nützliche Erkenntnisse zu erfassen:

• Ausführungsanzahl für Funktion
• Verbindungen
• Daten in
• Ausgehende Daten
• HTTP-Serverfehler
• Requests
• Requests In Application Queue (Anforderungen in der Anwendungswarteschlange)
• Antwortzeit

Verwenden der Diagnoseprotokollierung zum Erfassen von Erkenntnissen

Bei der gemeinsamen Analyse können die oben genannten Metriken verwendet werden, um die folgenden Erkenntnisse zu formulieren und zu erfassen:

• Rate der Anforderungen, die von Event Hub verarbeitet werden
• Rate der von Azure Functions verarbeiteten Anforderungen
• Event Hub-Gesamtdurchsatz
• Benutzerfehler
• Dauer von Azure Functions
• End-to-End-Wartezeit
• Wartezeit in jeder Phase
• Anzahl verlorener Nachrichten
• Anzahl der mehr als einmal verarbeiteten Nachrichten

Um sicherzustellen, dass Event Hubs die erforderlichen Metriken erfasst, müssen wir zunächst Diagnoseprotokolle aktivieren (die standardmäßig deaktiviert sind). Anschließend müssen wir auswählen, welche Protokolle gewünscht sind, und den richtigen Log Analytics-Arbeitsbereich als Ziel konfigurieren.

Die Protokoll- und Metrikkategorien, an denen wir interessiert sind, sind:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (für Apache Kafka-Workloads)
• KafkaUserErrorLogs (für Apache Kafka-Workloads)
• EventHubVNetConnectionEvent
• AllMetrics

Die Azure-Dokumentation enthält Anweisungen zum Einrichten von Diagnoseprotokollen für einen Azure Event Hub. Der folgende Screenshot zeigt einen Beispielkonfigurationsbereich für die Diagnoseeinstellung, in dem die richtigen Protokoll- und Metrikkategorien ausgewählt und ein Log Analytics-Arbeitsbereich als Ziel festgelegt ist. (Wenn ein externes System zum Analysieren der Protokolle verwendet wird, kann stattdessen die Option An einen Event Hub streamen verwendet werden.)

Hinweis

Um die Protokolldiagnose zum Erfassen von Erkenntnissen zu nutzen, sollten Sie Event Hubs in verschiedenen Namespaces erstellen. Dies liegt an einer Einschränkung in Azure.

Das in einem bestimmten Event Hubs-Namespace festgelegte Event Hubs wird in Azure Monitor-Metriken unter einer Dimension namens EntityName dargestellt. Im Azure-Portal können Daten für einen bestimmten Event Hub normalerweise auf dieser Instanz von Azure Monitor angezeigt werden. Wenn die Metrikdaten jedoch an die Protokolldiagnose weitergeleitet werden, gibt es derzeit keine Möglichkeit, Daten pro Event Hub durch Filtern nach der EntityName-Dimension anzuzeigen.

Als Abhilfe hilft das Erstellen von Event Hubs in verschiedenen Namespaces, um die Metriken für einen bestimmten Hub zu finden.

Verwenden von Application Insights

Sie können Application Insights aktivieren, um Metriken und benutzerdefinierte Telemetriedaten aus Azure Functions zu erfassen. Auf diese Weise können Sie Analysen definieren, die für Ihre Zwecke geeignet sind. So erhalten Sie eine weitere Möglichkeit, wichtige Erkenntnisse für das Szenario der serverlosen Ereignisverarbeitung zu gewinnen.

Dieser Screenshot zeigt eine Beispielauflistung von benutzerdefinierten Metriken und Telemetriedaten in Application Insights:

Benutzerdefinierte Standardmetriken

In Application Insights werden benutzerdefinierte Metriken für Azure Functions in der Tabelle customMetrics gespeichert. Sie enthält die folgenden Werte, die sich über eine Zeitachse für verschiedene Funktionsinstanzen erstrecken:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

Diese Metriken können verwendet werden, um die aggregierten Durchschnittswerte für die mehreren Funktionsinstanzen effizient zu berechnen, die in einer Ausführung aufgerufen werden.

Dieser Screenshot zeigt, wie diese benutzerdefinierten Standardmetriken aussehen, wenn sie in Application Insights angezeigt werden:

Benutzerdefinierte Nachrichten

Im Azure-Funktionscode protokollierte benutzerdefinierte Nachrichten (unter Verwendung von ILogger) werden aus der Tabelle traces in Application Insights abgerufen.

Die Tabelle traces enthält unter anderem die folgenden wichtigen Eigenschaften:

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Hier ist ein Beispiel dafür, wie eine benutzerdefinierte Nachricht in der Application Insights-Schnittstelle aussehen kann:

Wenn die eingehende Event Hub-Nachricht oder EventData[] als Teil dieser benutzerdefinierten ILogger-Nachricht protokolliert wird, wird dies auch in Application Insights zur Verfügung gestellt. Dies kann sehr nützlich sein.

Für unser serverloses Ereignisverarbeitungsszenario protokollieren wir den serialisierten JSON-Nachrichtentext, der vom Event Hub empfangen wird. Dies ermöglicht es uns, das unformatierte Bytearray zusammen mit SystemProperties wie z. B. x-opt-sequence-number, x-opt-offset und x-opt-enqueued-time zu erfassen. Um zu bestimmen, wann jede Nachricht vom Event Hub empfangen wurde, wird die Eigenschaft x-opt-enqueued-time verwendet.

Beispielabfrage:

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

Die Beispielabfrage würde eine Meldung ähnlich dem folgenden Beispielergebnis zurückgeben, das standardmäßig in Application Insights protokolliert wird. Die Eigenschaften von Trigger Details können verwendet werden, um zusätzliche Erkenntnisse zu Nachrichten zu finden und zu erfassen, die über PartitionId, Offset und SequenceNumber empfangen werden.

Beispielergebnis der Beispielabfrage:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Warnung

Die Bibliothek für Azure Java Functions weist derzeit ein Problem auf, das den Zugriff auf PartitionID und PartitionContext verhindert, wenn EventHubTrigger verwendet wird. Weitere Informationen finden Sie in diesem GitHub-Problembericht.

Nachverfolgen des Nachrichtenflusses mithilfe einer Transaktions-ID mit Application Insights

In Application Insights können wir alle Telemetriedaten im Zusammenhang mit einer bestimmten Transaktion anzeigen, indem wir eine Transaktionssuchabfrage für den Wert Operation Id der Transaktion ausführen. Dies kann besonders nützlich sein, um die Perzentilwerte der durchschnittlichen Zeiten für Nachrichten zu erfassen, während die Transaktion die Ereignisstreampipeline durchläuft.

Der folgende Screenshot zeigt eine Beispieltransaktionssuche in der Application Insights-Schnittstelle. Der gewünschte Wert für Operation ID wird in das Abfragefeld eingegeben, mit einem Lupensymbol identifiziert (und hier in einem roten Feld dargestellt). Am unteren Rand des Hauptbereichs werden auf der Registerkarte Results übereinstimmende Ereignisse in sequenzieller Reihenfolge angezeigt. In jedem Ereigniseintrag wird der Wert für Operation ID zur einfachen Überprüfung dunkelblau hervorgehoben.

Eine Abfrage, die für eine bestimmte Vorgangs-ID generiert wird, sieht wie folgt aus. Beachten Sie, dass die Operation ID-GUID in der where * has-Klausel der dritten Zeile angegeben ist. In diesem Beispiel wird die Abfrage zwischen zwei verschiedenen datetimes weiter eingeengt.

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Der folgende Screenshot zeigt, wie die Abfrage und die entsprechenden Ergebnisse in der Application Insights-Schnittstelle aussehen können:

Erfassen benutzerdefinierter Metriken aus Azure Functions

.NET-Funktionen

Die strukturierte Protokollierung wird in den Azure-Funktionen von .NET verwendet, um benutzerdefinierte Dimensionen in der Tabelle „Überwachungen“ in Application Insights zu erfassen. Diese benutzerdefinierten Dimensionen können dann zum Abfragen von Daten verwendet werden.

Hier sehen Sie beispielsweise die Protokollanweisung in .NET TransformingFunction:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

Die daraus resultierenden Protokolle, die in Application Insights erstellt werden, enthalten die oben genannten Parameter als benutzerdefinierte Dimensionen, wie in diesem Screenshot gezeigt:

Diese Protokolle können wie folgt abgefragt werden:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Hinweis

Um sicherzustellen, dass wir die Leistung in diesen Tests nicht beeinträchtigen, haben wir die Samplingeinstellungen von Azure-Funktionsprotokollen für Application Insights mithilfe der host.json-Datei wie unten gezeigt aktiviert. Dies bedeutet, dass alle aus der Protokollierung erfassten Statistiken als Durchschnittswerte und nicht als tatsächliche Anzahl betrachtet werden.

Beispiel für „host.json“:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Java-Funktionen

Derzeit wird die strukturierte Protokollierung in Java Azure-Funktionen nicht unterstützt, um benutzerdefinierte Dimensionen in der Tabelle „Überwachungen“ in Application Insights zu erfassen.

Hier sehen Sie beispielsweise die Protokollanweisung in Java TransformingFunction:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

Die daraus resultierenden Protokolle, die in Application Insights erstellt wurden, enthalten die oben genannten Parameter in der Meldung, wie unten dargestellt:

Diese Protokolle können wie folgt abgefragt werden:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Hinweis

Um sicherzustellen, dass wir die Leistung in diesen Tests nicht beeinträchtigen, haben wir die Samplingeinstellungen von Azure-Funktionsprotokollen für Application Insights mithilfe der host.json-Datei wie unten gezeigt aktiviert. Dies bedeutet, dass alle aus der Protokollierung erfassten Statistiken als Durchschnittswerte und nicht als tatsächliche Anzahl betrachtet werden.

Beispiel für „host.json“:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Beitragende

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

Hauptautor:

• Rajasa Savant | Senior Software Engineer

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

Zugehörige Ressourcen

• Die serverlose Ereignisverarbeitung ist eine Referenzarchitektur, die eine typische Architektur dieses Typs mit Codebeispielen und einer Erläuterung wichtiger Überlegungen detailliert erläutert.
• Die Debatchierung und Filterung in der serverlosen Ereignisverarbeitung mit Event Hubs beschreibt ausführlicher, wie diese Teile der Referenzarchitektur funktionieren.
• Das Private Link-Szenario bei der Verarbeitung von Ereignisstreams ist eine Lösungslösung für die Implementierung einer ähnlichen Architektur in einem virtuellen Netzwerk (VNET) mit privaten Endpunkten, um die Sicherheit zu erhöhen.
• Azure Kubernetes in der Ereignisstreamverarbeitung beschreibt eine Variation einer serverlosen ereignisgesteuerten Architektur, die in Azure Kubernetes mit KEDA Scaler ausgeführt wird.