Übung: Erstellen eines Anwendungsintegritätsmodells
Contoso Shoes benötigt eine Möglichkeit, Probleme in dieser Architektur zu erkennen, zu diagnostizieren und vorherzusagen. Sie möchten ein Integritätsmodell erstellen, das durch einen auf Benutzer- und Systemabläufe angewandten Integritätsstatus messbar ist. Ziel ist es, potenzielle Fehlerpunkte zu identifizieren, bevor sie einen Ausfall verursachen können.
Aktueller Zustand und Problem
Bisher haben Sie eine API für die Integritätsprüfung hinzugefügt und Funktionen für mehrere Regionen in Ihrer Architektur erstellt. Es gibt jedoch keine Möglichkeit, Einblicke in die komplexe Topologie zu erhalten, die Benutzer- und Systemabläufe umfasst. Diese Lücke muss geschlossen werden, damit das SRE-Team Probleme schnell erkennen und beheben kann.
Bei einem kürzlich aufgetretenen Vorfall war das Team nicht in der Lage, die kaskadenartigen Auswirkungen eines Problems zu erkennen, das durch eine API-Komponente verursacht wurde, die ihre Plattformabhängigkeiten beeinträchtigte. Die Problembehandlung nahm viel Zeit in Anspruch, da die fehlerhafte Komponente nicht sofort erkannt werden konnte. Letztendlich führte diese Ineffizienz zu längeren Ausfallzeiten und damit zu finanziellen Verlusten für das Unternehmen.
Spezifikation
Entwerfen Sie ein Integritätsmodell, das die Beziehungen zwischen allen Komponenten der Architektur einschließlich der Anwendungskomponenten und der Plattformabhängigkeiten zeigt. Berücksichtigen Sie Elemente, die innerhalb des Anforderungsflusses existieren, einschließlich Gateway, Compute, Datenbanken, Speicher, Caches usw. Schließen Sie auch Komponenten ein, die normalerweise außerhalb des Anforderungsflusses existieren. Beispiel: OCI-Artefakte (Open Container Initiative), Geheimnisspeicher, Konfigurationsdienste und andere. Alle Azure-Dienste müssen für das Senden von Diagnosedaten konfiguriert sein.
Fügen Sie eine einheitliche Datensenke in die Architektur ein, um Daten aus verschiedenen Quellen zu sammeln.
Definieren Sie einen allgemeinen Integritätsstatus auf der Grundlage aggregierter Verlaufsprotokolle und -metriken. Stellen Sie den Status in einem der drei Integritätszustände dar: fehlerhaft, heruntergestuft und fehlerfrei.
Visualisieren Sie den Integritätsstatus aller Komponenten in einer Hierarchie, die alle Abläufe darstellt.
Empfohlene Vorgehensweise
Wir empfehlen Ihnen, die folgenden Schritte zu befolgen, um mit Ihrem Entwurf zu beginnen.
Wichtig
Die Integritätsmodellierung ist eine umfassende Aufgabe. Der in diesem Abschnitt beschriebene Ansatz soll Ihnen den Einstieg erleichtern. Wenden Sie das Modell umfassend auf alle funktionalen und nicht funktionalen Abläufe in Ihrem unternehmenskritischen Entwurf an, um eine ganzheitliche Sicht auf das System zu erhalten.
1: Starten der Integritätsmodellierung
Dies ist eine theoretische Übung. Integritätsmodellierung im Rahmen einer Top-Down-Entwurfsaktivität, bei der Sie eine umfassende Liste der in der Architektur verwendeten Komponenten benötigen. Diese Liste sollte alle Anwendungskomponenten und die Azure-Dienste enthalten.
Platzieren Sie diese Komponenten in einem Abhängigkeitsdiagramm, das eine hierarchische Ansicht der Lösung zeigt. Auf der obersten Ebene befinden sich die Benutzerabläufe, die die Anforderungen des Endbenutzers an die Website nachverfolgen, sowie die Abläufe auf der Ebene der Anwendungs-API. Die unterste Ebene enthält die Systemabläufe aus den Azure-Diensten. Ordnen Sie auch die Abhängigkeiten zwischen den Azure-Ressourcen zu.
Ihr Diagramm sollte in etwa so aussehen:
Überprüfen Sie Ihren Fortschritt: Mehrschichtige Anwendungsintegrität
2: Definieren der Integritätsbewertungen
Sammeln Sie für jede Komponente Metriken und Metrikschwellenwerte und entscheiden Sie dann, bei welchem Wert die Komponente als fehlerfrei, heruntergestuft und fehlerhaft eingestuft werden soll. Diese Entscheidung sollte von der erwarteten Leistung und den nicht funktionalen Geschäftsanforderungen beeinflusst werden. Kategorisieren Sie Ihre Metriken wie folgt:
Anwendungsmetriken: Datenpunkte aus Anwendungscode, z. B. die Ausnahmeanzahl.
Dienstmetriken: Datenpunkte aus Azure-Diensten, etwa verwendete Datenbanktransaktionseinheiten (Database Transaction Units, DTUs).
Lösungsmetriken: Datenpunkte auf Lösungsebene, z. B. End-to-End-Verarbeitungszeit einer Anforderung.
Hier folgt ein Beispiel für Azure App Services:
| App-Dienste | Integritätsstatus |
|---|---|
| Antwortzeit < 200 ms HTTP-Serverfehler < 2 |
 |
| Antwortzeit < 500 ms HTTP-Serverfehler < 2 |
 |
| Antwortzeit > 500 ms HTTP-Serverfehler > 2 |
 |
3: Definieren eines allgemeinen Integritätsstatus
Definieren Sie für jeden Benutzer- und Systemablauf einen Gesamtstatus. Sie müssen den Integritätsstatus der einzelnen Komponenten, die an diesem Ablauf beteiligt sind, zusammenfassen.
Angenommen, ein Systemablauf besteht aus einer Anwendungskomponente, einem Azure App Service-Plan und App Services.
| API | App Service-Plan | App-Dienste | Integritätsstatus |
|---|---|---|---|
| Maximale Wartezeit < 30 ms | CPU in % < 70 % Länge der HTTP-Warteschlange < 5 |
Antwortzeit < 200 ms HTTP-Serverfehler < 2 |
|
| Maximale Wartezeit < 30 ms | CPU in % < 90 % Länge der HTTP-Warteschlange < 5 |
Antwortzeit < 500 ms HTTP-Serverfehler < 2 |
|
| Maximale Wartezeit > 30 ms | CPU in % > 90 % Länge der HTTP-Warteschlange > 5 |
Antwortzeit > 500 ms HTTP-Serverfehler > 2 |
|
Die Integritätsbewertung für einen Benutzerablauf sollte durch die niedrigste Bewertung aller zugeordneten Komponenten dargestellt werden. Wenden Sie für Systemabläufe eine angemessene Gewichtung auf der Grundlage der geschäftlichen Bedeutung an. Zwischen den beiden Abläufen sollten die finanziell bedeutsamen oder den Kunden zugewandten Benutzerabläufe priorisiert werden.
Überprüfen Sie Ihren Fortschritt: Beispiel – Mehrschichtiges Integritätsmodell
4: Sammeln von Überwachungsdaten
Sie benötigen in jeder Region eine einheitliche Datensenke, die Protokolle und Metriken für alle Anwendungen und Plattformdienste sammelt, die im Rahmen des regionalen Stempels bereitgestellt werden. Sie benötigen eine weitere Senke für die Speicherung von Metriken, die von globalen Ressourcen wie Azure Front Door und Cosmos DB ausgegeben werden.
Auswahl der Technologie
- Azure Application Insights: Wird verwendet, um alle Anwendungstelemetriedaten zu sammeln.
- Azure Monitor-Protokolle: Sammeln von Application Insights gesendete Daten sowie Plattformmetriken für Azure-Dienste.
- Azure Log Analytics: Wird als zentrales Tool für die Analyse von Protokollen und Metriken von allen Anwendungs- und Infrastrukturkomponenten verwendet.
Überprüfen Sie Ihren Fortschritt: Einheitliche Datensenke für die korrelierte Analyse
5: Einrichten von Abfragen für Überwachungsdaten
Die Kusto-Abfragesprache (KQL) ist vollständig in Log Analytics integriert. Implementieren Sie benutzerdefinierte KQL-Abfragen als Funktionen zum Abrufen von Daten aus Azure Monitor.
Speichern Sie benutzerdefinierte Abfragen im Coderepository, sodass sie automatisch als Teil Ihrer CI/CD-Pipelines (Continuous Integration/Continuous Delivery) importiert und angewendet werden.
6: Visualisieren des Integritätsstatus
Sie können das Abhängigkeitsdiagramm mit Integritätsbewertungen durch die Darstellung einer Ampel visualisieren. Verwenden Sie Tools wie Azure-Dashboards, Monitor-Arbeitsmappen oder Grafana. Hier sehen Sie ein Beispiel:
Überprüfen Sie Ihren Fortschritt: Visualisierung
7: Einrichten von Warnungen bei Statusänderungen
Sie sollten Dashboards mit Warnungen verwenden, um sofort über Probleme informiert zu werden.
Wenn sich der Integritätszustand einer Komponente in Heruntergestuft oder Fehlerhaft ändert, sollte der Operator sofort benachrichtigt werden. Legen Sie Warnungen auf dem Stammknoten fest, da jede Änderung an diesem Knoten auf einen fehlerhaften Zustand der zugrunde liegenden Benutzerabläufe oder Ressourcen hinweist.
Überprüfen Sie Ihren Fortschritt: Warnungen
Arbeit überprüfen
Schauen Sie sich diese Demo zur Überwachung und Integritätsmodellierung an. Haben Sie bei Ihrem Entwurf alle Aspekte berücksichtigt?
- Verfügen Sie über eine einheitliche Datensenke für korrelierte Analysen?
- Haben Sie Anwendungsprotokolle, Plattformmetriken und Lösungsdatenpunkte einbezogen?
- Haben Sie Dashboards eingerichtet, um den Integritätsstatus aller Komponenten zu visualisieren?
- Haben Sie bei jedem Dienst (oder einem Teil dieses Diensts) Fehlerpunkte berücksichtigt, die einen Ausfall verursachen oder Sie an der Skalierung, Bereitstellung und Überwachung hindern könnten?
- Haben Sie Abfragepakete in Betracht gezogen, um wichtige Abfragen zu erfassen, mit denen Sie Probleme schneller selektieren können?
- War Ihre Integritätsprüfungs-API bei diesem Modell hilfreich? Mussten Sie diese API ändern, um sie besser an das Integritätsmodell anzupassen?