Share via

Azure Load Testing mit benutzerdefinierten Plug-Ins

  • Artikel

Lösungsmöglichkeiten

Dieser Artikel ist ein Lösungsvorschlag. Wenn Sie möchten, dass wir diesen Artikel um weitere Informationen ergänzen, z. B. potenzielle Anwendungsfälle, alternative Dienste, Überlegungen zur Implementierung oder Preisempfehlungen, lassen Sie es uns über Feedback auf GitHub wissen.

Diese Lösung bietet Anleitungen für die Verwendung von Azure Load Testing, einem Dienst, mit dem Sie Apache JMeter-Skripts und benutzerdefinierte Plug-Ins ausführen können, um Benutzer- und Geräteverhalten zu simulieren. In dieser Lösung wird auch erläutert, wie Sie Key Performance Indicators (KPIs) entwerfen und ein Dashboard für die Überwachung und Analyse der Ergebnisse des Auslastungstests in einer Beispielanwendung mit Azure Functions und Azure Event Hubs entwickeln. In diesem Artikel wird davon ausgegangen, dass Sie mit JMeter, den Plug-Ins und benutzerdefinierten Plug-Ins sowie Azure Functions und Event Hubs vertraut sind.

Aufbau

Um Auslastungstests durchzuführen, benötigen Sie einen Testplan, der eine Reihe von Anweisungen enthält, die JMeter informiert, was während des Tests zu tun ist. Der Testplan kann mehrere Testszenarien umfassen, die jeweils mit unterschiedlichen Einstellungen und Konfigurationen verwendet werden. Sie können beispielsweise ein Szenario haben, das einen einzelnen Benutzer simuliert, der auf eine Webanwendung zugreift, und ein anderes Szenario, in dem mehrere Benutzer gleichzeitig auf dieselbe Anwendung zugreifen.

Der Testplan kann auch mehrere Testfälle umfassen, die jeweils mit unterschiedlichen Einstellungen und Konfigurationen verwendet werden. In unserem Fall gehen wir davon aus, dass es ein Gerät gibt, das über einen bestimmten Zeitraum Temperatur und Luftfeuchtigkeit meldet. Das Gerät sendet die Daten an einen Event Hub in Azure. Der Event Hub löst eine Azure-Funktion aus, die für die Verarbeitung der Daten verantwortlich ist und dann Daten an andere nachgeschaltete Dienste wie die Azure SQL-Datenbank sendet. Die Azure-Funktion ist der Dienst, den wir testen möchten. Der Testplan wurde entwickelt, um das Verhalten des Geräts zu simulieren und Daten an den Event Hub zu senden.

Diagram of a sample architecture for load testing.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

In diesem Beispiel lautet der Dataflow wie folgt:

  1. Ein simuliertes Gerät sendet Daten über den Azure Load Testing-Agent an einen Event Hub. Jedes Verhalten des Geräts kann mit benutzerdefinierten JMeter-Plug-Ins simuliert werden. Der Azure Load Test-Agent ist für das Senden von Daten an den Event Hub verantwortlich, nachdem das benutzerdefinierte Plug-In für alle Arten simulierter Geräte ausgeführt wurde.
  2. Der Event Hub löst eine Azure-Funktion aus, die für die Verarbeitung der Daten verantwortlich ist und dann Daten an andere nachgeschaltete Dienste wie die Azure SQL-Datenbank und Azure Digital Twins sendet.
  3. Der Azure Monitor-Dienst wird verwendet, um die Azure-Funktion und die Event Hubs zu überwachen.
  4. Der Azure Load Testing-Dienst sammelt die Daten aus dem Azure Monitor-Dienst und zeigt sie dann in einem Dashboard an.

Komponenten

In diesem Beispiel werden die folgenden Komponenten verwendet:

  • Azure Load Testing: Mit Azure Load Testing können Sie Apache JMeter-Skripts und benutzerdefinierte Plug-Ins ausführen, um Benutzer- und Geräteverhalten zu simulieren. Es stellt eine webbasierte Schnittstelle zum Verwalten und Ausführen von Auslastungstests und einer Reihe von APIs bereit, die zum Automatisieren des Prozesses verwendet werden können. Azure Load Testing ist ein vollständig verwalteter Dienst, was bedeutet, dass Sie sich keine Gedanken über die Verwaltung von Servern oder Infrastruktur machen müssen. Sie können Ihre JMeter-Skripts und benutzerdefinierte Plug-Ins hochladen, und Azure Load Testing macht den Rest.
  • Azure Event Hubs: Azure Event Hubs ist ein cloudbasierter Ereignisverarbeitungsdienst, der zum Sammeln, Verarbeiten und Analysieren von Ereignissen und Streamingdaten aus verschiedenen Quellen in Echtzeit verwendet werden kann. Event Hubs unterstützen mehrere Protokolle, einschließlich AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, MQTT (Message Queuing Telemetry Transport) und AMQP über WebSockets. Die Auswahl des richtigen Protokolls hängt von mehreren Faktoren ab, einschließlich des Datentyps, mit dem Sie arbeiten, den spezifischen Anforderungen Ihrer Anwendung sowie den Funktionen und Einschränkungen der Protokolle selbst.
  • Azure Functions: Azure Functions ist ein serverloser Rechendienst, mit dem Sie Code ausführen können, ohne Server oder Infrastruktur verwalten zu müssen. Es unterstützt mehrere Programmiersprachen, darunter C#, F#, Java, JavaScript, PowerShell, Python und TypeScript. Azure Functions können verwendet werden, um Ereignisse und Streamingdaten von Event Hubs sowie andere Quellen wie Azure Storage und Azure Cosmos DB zu verarbeiten.
  • JMeter GUI: JMeter GUI ist ein Open-Source-Lasttesttool, das hauptsächlich zum Testen der Leistung von Webanwendungen verwendet wird. Es wurde ursprünglich für das Testen von Webanwendungen entwickelt. Es kann jedoch auch verwendet werden, um andere Arten von Anwendungen zu testen, z. B. SOAP- und REST-Webdienste, FTP-Server und Datenbanken.
  • Azure Monitor: Azure Monitor bietet Überwachungs- und Warnungsfunktionen für Azure-Ressourcen. Damit können Sie auch die Leistung und Integrität Ihrer Anwendungen und der zugrunde liegenden Infrastruktur überwachen. Azure Monitor kann verwendet werden, um Event Hubs und Azure-Funktionen sowie andere Azure-Dienste wie Azure Storage und Azure Cosmos DB zu überwachen.

Szenariodetails

Mit Azure Load Testing können Sie ein vorhandenes Apache JMeter-Skript verwenden, um einen Auslastungstest auf Cloudebene für eine beliebige Azure-Ressource auszuführen.

Mit JMeter können Tester Lasttests, Stresstests und funktionsbezogene Tests erstellen und ausführen. Es simuliert den gleichzeitigen Zugriff mehrerer Benutzer auf eine Webanwendung und ermöglicht es Testern, potenzielle Leistungsengpässe oder andere Probleme zu erkennen, die bei hoher Auslastung auftreten können. JMeter kann verwendet werden, um verschiedene Leistungsmetriken zu messen, z. B. Antwortzeit, Durchsatz und Fehlerrate.

JMeter verwendet eine GUI-basierte Schnittstelle, um Benutzern das Erstellen von Testplänen zu ermöglichen, die mehrere Testszenarien umfassen können, die jeweils mit unterschiedlichen Einstellungen und Konfigurationen verwendet werden. Tester können JMeter auch mithilfe von Plug-Ins anpassen oder benutzerdefinierten Code schreiben, sodass sie ihre Funktionalität über das hinaus erweitern können, was aus der Box kommt. Die Plug-Ins können uns helfen, mit Diensten zu arbeiten, die nicht-HTTP-Protokolle verwenden, z. B. AMQP und Websocket.

Während JMeter eine breite Palette von Features und Funktionen zum Lastentesten bereitstellt, gibt es möglicherweise bestimmte Anwendungsfälle oder Anforderungen, die nicht von der integrierten Funktionalität abgedeckt werden. Durch die Entwicklung von benutzerdefinierten Plug-Ins können Tester neue Funktionen hinzufügen oder vorhandene Features an ihre Anforderungen anpassen.

Beispielsweise könnte ein benutzerdefiniertes Plug-In entwickelt werden, um eine bestimmte Art von Benutzerverhalten zu simulieren oder realistischere Testdaten zu generieren. Darüber hinaus können benutzerdefinierte Plug-Ins entwickelt werden, um JMeter in andere Tools oder Systeme zu integrieren, z. B. Protokollierungs- und Berichterstellungstools oder kontinuierliche Integrations- und Bereitstellungspipelines Die benutzerdefinierten Plug-Ins können dazu beitragen, den Testprozess zu optimieren und die Integration von Lasttests in den gesamten Softwareentwicklungsworkflow zu vereinfachen. Insgesamt ermöglichen sie Testern, JMeter an ihre spezifischen Bedürfnisse anzupassen und die Genauigkeit und Effektivität ihrer Lasttestbemühungen zu verbessern.

In diesem Beispiel wird davon ausgegangen, dass ein Gerät über einen bestimmten Zeitraum Temperatur und Feuchtigkeit meldet. Wir können dieses einfache Verhalten mithilfe eines benutzerdefinierten JMeter-Plug-Ins simulieren. In der aktuellen Implementierung des hier bereitgestellten benutzerdefinierten Plug-Ins generieren wir zufällige Daten mithilfe einer bereitgestellten Vorlage. Das Plug-In kann jedoch jedes mögliche komplexe Verhalten für alle Geräte enthalten. In diesem Beispiel sendet das Gerät die Daten an einen Event Hub in Azure. Der Event Hub löst eine Azure-Funktion aus, die für die Verarbeitung der Daten verantwortlich ist und sendet dann Daten an andere nachgeschaltete Dienste wie die Azure SQL-Datenbank. Die Azure-Funktion ist der Dienst, den wir testen möchten. Der Testplan wurde entwickelt, um das Verhalten des Geräts zu simulieren und Daten an den Event Hub zu senden.

Mögliche Anwendungsfälle

Die Verwendung von Azure Load Testing mit benutzerdefinierten Plug-Ins kann in verschiedenen Szenarien hilfreich sein, z. B.:

  • Testen der Leistung einer Anwendung, die nicht-HTTP-Protokolle verwendet, z. B. AMQP und Websocket.
  • Testen der Leistung einer Anwendung, die ein benutzerdefiniertes Protokoll verwendet.
  • Testen der Leistung einer Anwendung, die ein nicht von Microsoft stammendes SDK verwendet.
  • Simulieren eines bestimmten Typs von Benutzer- oder Geräteverhalten oder Generieren realistischerer Testdaten.

Benutzerdefinierte Plug-Ins

Benutzerdefinierte Plug-Ins im Kontext von JMeter sind Softwarekomponenten, die JMeter hinzugefügt werden können, um die Funktionalität über das hinaus zu erweitern, was aus der Box kommt. Benutzer oder Nicht-Microsoft-Entwickler können benutzerdefinierte Plug-Ins entwickeln, um neue Features, Funktionen oder Integrationen zu JMeter hinzuzufügen. Benutzerdefinierte Plug-Ins können mit der Java-Programmiersprache und dem JMeter Plugin Development Kit (PDK) entwickelt werden. Der PDK bietet eine Reihe von Tools und APIs, die das Erstellen neuer Plug-Ins erleichtern, einschließlich GUI-Elemente, Listener und Sampler.

Benutzerdefinierte Plug-Ins können JMeter eine breite Palette von Funktionen hinzufügen. Sie können JMeter auch in andere Systeme integrieren, z. B. Protokollierungs- und Berichterstellungstools, oder die Verwendung anderer Datenquellen für Testdaten aktivieren. Insgesamt können Benutzer mit benutzerdefinierten Plugins JMeter erweitern, um ihre spezifischen Anforderungen zu erfüllen und die Genauigkeit und Effektivität ihrer Lasttestbemühungen zu verbessern.

Um einen benutzerdefinierten Sampler für Event Hubs in JMeter zu implementieren, befolgen Sie die Anweisungen unter Azure Load Testing Plugins. Nachdem Ihr benutzerdefinierter Sampler implementiert wurde, können Sie ihn wie jeder andere Sampler in Ihrem JMeter-Testplan in Azure Load Test verwenden.

Ein Testplan kann mithilfe einer Threadgruppe implementiert werden, die die Anzahl der Threads (virtuelle Benutzer und Geräte) steuert, um ein bestimmtes Szenario auszuführen. Jede Threadgruppe kann unterschiedliche Einstellungen für die Anzahl der Threads, den Ramp-up-Zeitraum, die Schleifenanzahl und die Dauer aufweisen. Threadgruppen können entweder sequenziell oder parallel ausgeführt werden, abhängig von der Konfiguration des Testplans und den Anwendungsanforderungen. Sie können den Sampler einer Threadgruppe hinzufügen, seine Parameter festlegen und nach Bedarf konfigurieren. Benutzerdefinierte Sampler können leistungsstarke Tools in JMeter sein, sodass Sie komplexe Szenarien und Anforderungen simulieren können, die von den integrierten Samplern nicht unterstützt werden.

Erstellen eines Apache JMeter-Skripts mit benutzerdefiniertem Plug-In

In diesem Abschnitt erstellen Sie ein Beispiel-JMeter-Testskript zum Laden einer Anwendung mit Event Hubs.

So erstellen Sie ein Beispiel-JMeter-Testskript:

  1. Erstellen Sie eine LoadTest.jmx-Datei auf Ihrem lokalen Computer:

    touch LoadTest.jmx

  2. Öffnen Sie LoadTest.jmx in einem Texteditor, und fügen Sie den folgenden Codeausschnitt in die Datei ein. Dieses Skript simuliert einen Auslastungstest von 36 virtuellen Computern, die gleichzeitig Ereignisse an einen Event Hub senden, und dauert 10 Minuten:

    <?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
            <boolProp name="LoopController.continue_forever">false</boolProp>
            <intProp name="LoopController.loops">-1</intProp>
        </elementProp>
        <stringProp name="ThreadGroup.num_threads">36</stringProp>
        <stringProp name="ThreadGroup.ramp_time">20</stringProp>
        <boolProp name="ThreadGroup.scheduler">true</boolProp>
        <stringProp name="ThreadGroup.duration">600</stringProp>
        <stringProp name="ThreadGroup.delay"></stringProp>
        <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
        <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
            <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
            <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
            <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
        </com.microsoft.eventhubplugin.EventHubPlugin>
        <hashTree/>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

    Die Implementierung voncom.microsoft.eventhubplugin.EventHubPluginGui und com.microsoft.eventhubplugin.EventHubPluginsind unter Azure Samples verfügbar.

  3. Legen Sie in der Datei den Wert des eventHubConnectionVarName Knotens auf den Variablennamen fest, der den Host der Event Hubs-Verbindungszeichenfolge angibt. Wenn Sie beispielsweise möchten, dass die Umgebungsvariable die Verbindungszeichenfolge von Event Hubs speichertEventHubConnectionString, legen Sie diese Variable auf EventHubConnectionStringfest und legen Sie dann den Wert der Umgebungsvariablen fest. ​

    Wichtig

    Stellen Sie sicher, dass der Wert EventHubConnectionString im Rahmen des Azure-Auslastungstesterstellungsprozesses festgelegt wurde, bevor Sie das Auslastungstestskript ausführen.

  4. Legen Sie in der Datei den Wert des eventHubName Knotens auf den Event Hub-Namen fest, z. B.telemetry-data-changed-eh

  5. Legen Sie den Wert des liquidTemplateFileName Knotens auf die Datei fest, die die Nachricht enthält, die an den Event Hub gesendet wird. Erstellen Sie z. B. eine Datei mit dem folgenden Namen StreamingDataTemplate.liquidals:

    {
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}

    In diesem Beispiel ist die Nutzlast für die Event Hub-Nachricht ein JSON-Objekt mit drei Eigenschaften, einschließlich MachineId, TemperatureundHumidity wobei MachineId eine zufällig generierte ID mit der Länge 27 ist Temperatureund Humidity zufällige ganze Zahlen kleiner als 100 sind. Diese Datei ist eine Loquid Template-Syntax. Liquid Template ist eine beliebte Vorlagensprache, die in verschiedenen Webentwicklungs-Frameworks verwendet wird. Mit Liquid Template können Entwickler dynamische Inhalte erstellen, die einfach aktualisiert und geändert werden können. Sie ermöglichen es Ihnen, Variablen, Bedingungen, Schleifen und andere dynamische Elemente in Ihre Event Hub-Nachrichten einzufügen. Die Syntax ist einfach, und es stehen viele Onlineressourcen zur Verfügung, die Ihnen bei den ersten Schritten helfen. Insgesamt bieten Liquid Templates eine leistungsstarke und flexible Möglichkeit zum Erstellen dynamischer, anpassbarer Nachrichten.

  6. Speichern und schließen Sie die Datei.

    Wichtig

    Fügen Sie keine persönlichen Daten in den Sampler-Namen im JMeter-Skript ein. Die Samplernamen werden im Dashboard für Azure Load Testing-Testergebnisse angezeigt. Ein Beispiel für eine Liquid-Vorlage zusammen mit der JMeter-Skriptdatei steht zum Herunterladen unter Azure Samples zur Verfügung.

Ausführen des Auslastungstests mithilfe eines neuen Plug-Ins

Wenn Azure Load Testing ihren Auslastungstest startet, stellt es zuerst das JMeter-Skript zusammen mit allen anderen Dateien in Testmodulinstanzen bereit und startet dann den Auslastungstest, wie unter Anpassen eines Auslastungstests mit Apache JMeter-Plug-Ins und Azure Load Testing beschrieben. Bevor Sie den Test ausführen, wechseln Sie zur Registerkarte Parameter, DefinierenEventHubConnectionString und geben Sie dann den Verbindungszeichenfolge an den Event Hub an.

Screenshot that shows the parameters of the test.

Einrichtung von Leistungstests für die Umgebung

Bei allen Leistungstests ist es wichtig, eine ähnliche Umgebung wie die Produktionsumgebung zu haben. In diesem Beispiel wird die folgende Umgebung für Leistungstests verwendet, um die Systemkapazität und die Leistung des Systems besser zu verstehen.

Je nach Beispielarchitektur können die folgenden Dienste für Leistungstests verwendet werden:

Dienst Konfiguration
Eventhub Premium mit einer Verarbeitungseinheit (PU).
Azure Function Linux mit Premium Plan (EP1) – 210 ACU, 3,5 GB Arbeitsspeicher und 1 vCPU äquivalentem Standard_D1_v2
Region USA, Osten

Die Auswahl der richtigen Dienstebene für alle Azure-Dienste, einschließlich Event Hubs und Azure Functions, ist ein komplexer Prozess und hängt von vielen Faktoren ab. Weitere Informationen finden Sie unter Azure Event Hubs-Preise und Azure Functions-Preise.

Entwerfen von KPIs für Leistungstests

Bevor Sie Key Performance Indicators (KPIs) für Leistungstests entwerfen können, benötigen Sie zwei Dinge: die Geschäftsanforderungen und die Systemarchitektur. Die Geschäftsanforderungen informieren Sie, welche KPIs Sie messen möchten, z. B. Antwortzeit, Durchsatz oder Fehlerrate. Die Systemarchitektur teilt Ihnen mit, wie Sie die Leistung jeder Komponente testen, z. B. Webserver, Datenbanken oder APIs. Sie hilft Ihnen auch, die beste Leistungsteststrategie auszuwählen, z. B. Belastungstests, Stresstests oder Ausdauertests.

In diesem Beispiel sind die geschäftlichen Anforderungen Folgende:

  • Das System sollte 1.000 Anforderungen pro Sekunde verarbeiten können.
  • Die Systemzulässigkeit sollte höher als 0,99 sein.
  • Das System sollte in der Lage sein, 1.000 gleichzeitige Geräte zu verarbeiten, die ihre persönlichen Dateninformationen melden.
  • Angeben der maximalen Kapazität des Systems in Bezug auf die Anzahl der Geräte, die unterstützt werden können. Kann das System beispielsweise mit dreifachen der aktuellen Kapazität 1.000 gleichzeitige Geräte unterstützen?

Je nach diesen Anforderungen können die KPIs für Leistungstests Folgende sein:

KPI Beschreibung
RPS Anforderung pro Sekunde für einen Event Hub
LOAD Anzahl der Lasten oder Anforderungen, die während der Leistungstests an den Event Hub gesendet werden
IR Anzahl der Funktionsausführungen oder Aufnahmerate
RT Durchschnittliche Zeit für die Azure Function-Ausführungszeit
AMU Durchschnittliche Speicherauslastung für Azure Functions
SR Erfolgsquote aller Funktionsausführungen
ARS Durchschnittliche Antwortzeit nachgelagerter Dienste (z. B. SQL-Server oder ein Mikrodienst)
DF Anzahl der Abhängigkeitsfehler einschließlich interner Azure-Funktionsfehler
MRPS Maximale RPS ohne Backlog im Event Hub (Systemkapazität)

Messen von KPIs

Um KPIs zu messen, müssen Sie über eine Leistungsteststrategie verfügen. Die Strategie definiert den Leistungstestansatz für jede Komponente. In diesem Beispiel wird die folgende Leistungsteststrategie verwendet:

  • Event Hubs: Der Leistungstestansatz für den Event Hub besteht darin, viele Nachrichten an den Event Hub zu senden und dann RPS und LOAD zu messen. Das RPS ist die Anzahl der Nachrichten, die pro Sekunde an den Event Hub gesendet werden. LOAD ist die Gesamtanzahl der Nachrichten, die während der Leistungstests an den Event Hub gesendet werden. Der Azure Load Testing-Dienst kann RPS und LOAD messen.
  • Azure Functions: Der Leistungstestansatz für Azure Functions besteht darin, die folgenden Metriken zu messen:
    • Die IR ist die Anzahl der Funktionsausführungen oder der Aufnahmerate.
    • Der RT-Wert ist die durchschnittliche Zeit für die Azure Function Ausführungszeit.
    • Die AMU ist die durchschnittliche Speicherauslastung für Azure Functions.
    • Der SR ist die Erfolgsquote aller Funktionsausführungen.
    • Das ARS ist die durchschnittliche nachgeschaltete Dienstantwortzeit.
    • Der DF ist die Anzahl der Abhängigkeitsfehler, einschließlich interner Azure-Funktionsfehler.
    • Der Azure Monitor-Dienst kann AMU, ARS und DF messen, jedoch nicht IR, RT oder SR.

Um KPIs mithilfe des Azure Monitor-Diensts zu messen, müssen wir Application Insights für Azure Functions aktivieren. Weitere Informationen finden Sie unter Application Insights Integration.

Nach dem Aktivieren des Azure Monitor-Diensts können Sie die folgenden Abfragen verwenden, um KPIs zu messen:

  • IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
  • RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
  • SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Beispiel für das Azure Monitor-Dashboard

Hier ist ein Beispiel für das Azure Monitor-Dashboard, das die KPIs für Azure Functions basierend auf den Abfragen zeigt:

Screenshot samples of the Azure Monitor dashboard.

Zusammenfassung

In diesem Artikel haben Sie erfahren, wie Sie KPIs entwerfen und ein Dashboard für Azure Load Test entwickeln. Außerdem haben Sie erfahren, wie Sie benutzerdefinierte Plug-Ins in JMeter verwenden, um Auslastungstests für Azure Functions durchzuführen, die in Event Hubs integriert sind. Sie können denselben Ansatz verwenden, um Auslastungstests für andere Azure-Dienste durchzuführen. Sie können auch eine kontinuierliche Integrations- und Übermittlungspipeline (CI/CD) für Ihre Auslastungstestskripts mithilfe von Azure DevOps einrichten.

Weitere Informationen finden Sie unter Azure Load Testing.

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