Übung: Definieren von Integritätszuständen, Metriken und Schwellenwerten

  • 6 Minuten

In dieser Übung verwenden wir die Integritätsmodellstruktur, die Sie zuvor erstellt haben. Ihre Aufgabe besteht darin, den Integritätszustand einzelner Komponenten für die Beispielanwendung zu quantifizieren.

Bewerten Sie in der Struktur des Gesundheitsmodells zunächst die Ebenen, die oben mit Benutzerflows beginnen, und fahren Sie mit den unteren Ebenen fort.

Integritätszustand von Benutzerflows

Bisher haben wir zwei Benutzerabläufe identifiziert: Katalogelemente auflisten und Kommentar hinzufügen. Stellen Sie folgende Fragen, um die Integritätszustände der einzelnen Benutzerflows zu ermitteln:

  • Wann gilt der Benutzerflow als fehlerfrei?
  • Kann er im Status „Heruntergestuft“ ausgeführt werden?

Identifizieren Sie basierend auf den Implementierungs- und Funktionsanforderungen die Anwendungskomponenten, die am Benutzerflow beteiligt sind. Die Komponenten werden in Beispielarchitekturkomponenten beschrieben.

Benutzerflow Komponenten
Auflisten von Katalogelementen Interne Front-End-Webanwendung, Katalog-API
Kommentar hinzufügen Interne Front-End-Webanwendung, Katalog-API, Hintergrundprozessor

Wenn eine dieser Komponenten fehlerhaft ist, ist zu erwarten, dass auch der Benutzerflow fehlerhaft wird.

Hinweis

Einige Anwendungen können in einem speziellen Modus namens Heruntergestuft ausgeführt werden. Wenn Contoso Shoes beispielsweise die lokale Browserzwischenspeicherung implementiert, können Mitarbeiter, die die Webanwendung verwenden, Kommentare erstellen, wobei die Kommentare erst gesendet werden und die Kundenansicht erst dann aktualisiert wird, wenn die Katalog-API fehlerfrei ist, was der Browser kontinuierlich überprüfen kann.

Integritätszustand von Anwendungskomponenten

Bestimmen Sie Metriken, die den Integritätszustand einer Komponente bestimmen. Für diesen Schritt müssen Sie die Funktionalität der Komponente kennen. Stellen Sie beispielsweise folgende Fragen:

  • Welche Verarbeitungszeit in der API ist akzeptabel, um eine gute Benutzerfreundlichkeit zu gewährleisten?
  • Sind Fehler zu erwarten? Wie hoch ist die „normale“ Fehlerrate?
  • Was ist die „normale“ Verarbeitungszeit? Was bedeutet es, wenn die Bearbeitungszeit länger als normal ist?
  • Was geschieht mit Schreibvorgängen, wenn Azure Cosmos DB nicht erreichbar ist?

Mit diesen Fragen können Sie spezifische und messbare Schwellenwerte für wichtige Metriken festlegen. Diese Schwellenwerte können Sie beispielsweise für die Komponente „Katalog-API“ in Betracht ziehen.

Metriken und Schwellenwert Integritätsstatus
Antwortzeit < 150 ms Anzahl fehlgeschlagener Anforderungen < 10 Healthy
Antwortzeit < 300 ms Anzahl fehlgeschlagener Anforderungen < 50 Heruntergestuft
Antwortzeit > 300 ms Anzahl fehlgeschlagener Anforderungen > 50 Fehlerhaft

Sie können die Werte aus einer Anwendungsüberwachungslösung wie z. B. Application Insights abrufen.

Azure Resource Health-Status

Azure-Dienstintegritätszustände basieren auf bestimmten Ressourcen. Azure Cosmos DB meldet beispielsweise die DTU-Auslastung (Datenbanktransaktionseinheit), und Azure App Services stellt Informationen zur CPU-Auslastung bereit.

Informationen zu Metriken nach Ressourcentyp finden Sie unter Unterstützte Metriken von Azure Monitor.

Integritätszustände und Schwellenwerte

Nachdem Sie alle Schichten der Anwendung ausgewertet haben, erhalten Sie eine Liste der Komponenten und den zugehörigen Integritätszustandsdefinitionen, die diesem Beispiel ähneln.

Komponente Indikator/Metrik Healthy Heruntergestuft Fehlerhaft
Benutzerflow Katalogelemente auflisten Zugrunde liegender Integritätszustand Front-End fehlerfrei und Katalog-API fehlerfrei
Benutzerflow Kommentar hinzufügen Zugrunde liegender Integritätszustand Front-End fehlerfrei, Katalog-API fehlerfrei und Hintergrundprozessor fehlerfrei
Front-End-Webanwendung Anzahl der Nicht-20x-HTTP-Antworten/Min. 0 1 - 10 > 10
Katalog-API Anzahl der Ausnahmen/Sek. < 10 10-50 > 10
Durchschnittliche Verarbeitungszeit (ms) < 150 150–500 > 500
Hintergrundprozessor Durchschnittliche Zeit in der Warteschlange (ms) < 200 200–1.000 > 1.000
Durchschnittliche Verarbeitungszeit (ms) < 100 100–200 > 200
Fehleranzahl < 3 3–10 > 10
Azure Cosmos DB DTU-Nutzung < 70 % 70–90 % > 90 %
Azure-Schlüsseltresor Fehleranzahl < 3 3–10 > 10
Azure Event Hubs Verarbeitung der Backloglänge (ausgehende/eingehende Nachrichten) < 3 3–20 > 20
Azure Blob Storage Durchschnittliche Latenz (ms) < 100 100–200 > 200

In diesem Beispiel unterscheidet sich die Fehlertoleranz für die Front-End-Webanwendung und die Katalog-API. Dieser Unterschied bezieht sich auf das technische Verständnis der Anwendung. Alle Front-End-Fehler sollten clientseitig behandelt werden, damit es einen Schwellenwert von 0 gibt. Auf API-Ebene sind jedoch 10 Ausnahmen zulässig, um benutzerbedingte Fehler zu berücksichtigen. Beispielsweise weisen Fehler wie 404 – Nicht gefunden nicht unbedingt auf ein Integritätsproblem hin.