Integritätsmodellierung und Beobachtbarkeit unternehmenskritischer Workloads in Azure

Integritätsmodellierung und Beobachtbarkeit sind wichtige Konzepte zur Maximierung der Zuverlässigkeit, die sich auf robuste und kontextbezogene Instrumentierung und Überwachung konzentriert. Diese Konzepte bieten einen kritischen Einblick in die Anwendungsintegrität und fördern die schnelle Identifizierung und Lösung von Problemen.

Die meisten unternehmenskritischen Anwendungen sind sowohl hinsichtlich der Skalierung als auch der Komplexität von Bedeutung und generieren daher große Mengen an betriebsbezogenen Daten, sodass es schwierig ist, optimale betriebliche Maßnahmen zu bewerten und zu bestimmen. Die Integritätsmodellierung zielt letztendlich darauf ab, die Beobachtbarkeit zu maximieren, indem rohe Überwachungsprotokolle und Metriken mit wichtigen Geschäftsanforderungen zur Quantifizierung der Anwendungsintegrität erweitert werden, wodurch die automatisierte Auswertung von Integritätszuständen unterstützt wird, um konsistente und beschleunigte Vorgänge zu erreichen.

Dieser Entwurfsbereich konzentriert sich auf den Prozess zum Definieren eines robusten Integritätsmodells, das quantifizierte Anwendungsintegritätszustände durch Beobachtbarkeit und operative Konstrukte zuordnen, um die Betriebsreife zu erreichen.

Wichtig

Dieser Artikel ist Teil der Unternehmenskritisch-Workloadreihe von Azure Well-Architected . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit einer unternehmenskritischen Workload zu beginnen?

Bei der Maximierung der Zuverlässigkeit gibt es drei Standard Reifegrade.

1. Erkennen und Reagieren auf Probleme, wenn sie auftreten.
2. Diagnostizieren Sie Probleme, die auftreten oder bereits aufgetreten sind.
3. Vorhersagen und Verhindern von Problemen, bevor sie auftreten.

Video: Definieren eines Integritätsmodells für Ihre unternehmenskritische Workload

Mehrschichtige Anwendungsintegrität

Um ein Integritätsmodell zu erstellen, definieren Sie zunächst die Anwendungsintegrität im Kontext der wichtigsten Geschäftsanforderungen, indem Sie die Zustände "fehlerfrei" und "fehlerhaft" in einem mehrstufigen und messbaren Format quantifizieren. Verfeinern Sie dann für jede Anwendungskomponente die Definition im Kontext eines zustandsbeständigen Betriebs und aggregiert gemäß den Benutzerflows der Anwendung. Überlagern sie mit wichtigen, nicht funktionalen Geschäftsanforderungen in Bezug auf Leistung und Verfügbarkeit. Schließlich aggregieren Sie die Integritätszustände für jeden einzelnen Benutzerflow, um eine akzeptable Darstellung der gesamten Anwendungsintegrität zu bilden. Nach der Einrichtung sollten diese mehrstufigen Integritätsdefinitionen verwendet werden, um kritische Überwachungsmetriken für alle Systemkomponenten zu informieren und die Zusammensetzung des betriebsbezogenen Subsystems zu überprüfen.

Wichtig

Stellen Sie beim Definieren der "fehlerhaften" Zustände für alle Ebenen der Anwendung dar. Es ist wichtig, zwischen vorübergehenden und nicht vorübergehenden Fehlerzuständen zu unterscheiden, um die Dienstbeeinträchtigung im Verhältnis zur Nichtverfügbarkeit zu qualifizieren.

Überlegungen zum Entwurf

• Der Prozess der Modellierung der Integrität ist eine Top-down-Entwurfsaktivität, die mit einer Architekturübung beginnt, um alle Benutzerflows zu definieren und Abhängigkeiten zwischen funktionalen und logischen Komponenten zuzuordnen, wodurch Abhängigkeiten zwischen Azure-Ressourcen implizit zugeordnet werden.

• Ein Integritätsmodell ist vollständig vom Kontext der Lösung abhängig, die es darstellt, und kann daher nicht sofort gelöst werden, da "eine Größe nicht alle passt".

  • Anwendungen unterscheiden sich in Der Zusammensetzung und den Abhängigkeiten
  • Metriken und Metrikschwellenwerte für Ressourcen müssen auch in Bezug darauf optimiert werden, welche Werte fehlerfreie und fehlerhafte Zustände darstellen, die stark von umfassenden Anwendungsfunktionen und nicht funktionalen Anforderungen beeinflusst werden.

• Ein Mehrschicht-Integritätsmodell ermöglicht es, die Anwendungsintegrität auf Abhängigkeiten niedrigerer Ebene zurückzuverfolgen, wodurch die Ursache von Dienstbeeinträchtigungen schnell ermittelt werden kann.

• Um Integritätszustände für eine einzelne Komponente zu erfassen, müssen die unterschiedlichen Betriebseigenschaften dieser Komponente unter einem stabilen Zustand verstanden werden, der die Produktionslast widerspiegelt. Leistungstests sind daher eine wichtige Funktion zum Definieren und kontinuierlichen Auswerten der Anwendungsintegrität.

• Fehler innerhalb einer Cloudlösung treten möglicherweise nicht isoliert auf. Ein Ausfall in einer einzelnen Komponente kann dazu führen, dass mehrere Funktionen oder zusätzliche Komponenten nicht mehr verfügbar sind.

  • Solche Fehler sind möglicherweise nicht sofort erkennbar.

Entwurfsempfehlungen

• Definieren Sie ein messbares Integritätsmodell als Priorität, um ein klares betriebsbezogenes Verständnis der gesamten Anwendung sicherzustellen.

  • Das Integritätsmodell sollte überlappend sein und die Anwendungsstruktur reflektieren.
  • Die grundlegende Ebene sollte einzelne Anwendungskomponenten berücksichtigen, z. B. Azure-Ressourcen.
  • Grundlegende Komponenten sollten zusammen mit wichtigen nicht funktionalen Anforderungen aggregiert werden, um die Integrität von Systemflows in den Kontext des Unternehmens zu integrieren.
  • Systemflows sollten mit geeigneten Gewichtungen basierend auf der Unternehmenskritikalität aggregiert werden, um eine aussagekräftige Definition der allgemeinen Anwendungsintegrität zu erstellen. Finanziell signifikante oder kundenorientierte Benutzerflows sollten priorisiert werden.
  • Jede Ebene des Integritätsmodells sollte erfassen, welche Zustände "fehlerfrei" und "fehlerhaft" darstellen.
  • Stellen Sie sicher, dass das Heath-Modell zwischen vorübergehenden und nicht vorübergehenden fehlerhaften Zuständen unterscheiden kann, um die Dienstbeeinträchtigung von der Nichtverfügbarkeit zu isolieren.

• Stellen Sie Integritätszustände mithilfe einer präzisen Integritätsbewertung für jede einzelne Anwendungskomponente und jeden Benutzerfluss dar, indem Sie Integritätsbewertungen für zugeordnete abhängige Komponenten aggregieren, wobei wichtige nicht funktionale Anforderungen als Koeffizienten berücksichtigt werden.

  • Die Integritätsbewertung für einen Benutzerflow sollte durch die niedrigste Bewertung für alle zugeordneten Komponenten dargestellt werden, wobei die relative Erlangung gegenüber nicht funktionalen Anforderungen für den Benutzerflow eingerechnet wird.
  • Das Modell, das zum Berechnen von Integritätsbewertungen verwendet wird, muss die Betriebsintegrität konsistent widerspiegeln. Andernfalls sollte das Modell angepasst und erneut bereitgestellt werden, um neue Erkenntnisse widerzuspiegeln.
  • Definieren Sie Schwellenwerte für die Integritätsbewertung, um integritäts- status widerzuspiegeln.

• Die Integritätsbewertung muss automatisch basierend auf zugrunde liegenden Metriken berechnet werden, die durch Beobachtbarkeitsmuster visualisiert und mithilfe automatisierter betrieblicher Verfahren ausgeführt werden können.

  • Die Integritätsbewertung sollte zum Kern der Überwachungslösung werden, sodass Betriebsteams betriebsbezogene Daten nicht mehr interpretieren und der Anwendungsintegrität zuordnen müssen.

• Verwenden Sie das Integritätsmodell, um die Verfügbarkeit des Service Level Objective (SLO)-Erreichens anstelle der Rohverfügbarkeit zu berechnen, um sicherzustellen, dass die Abgrenzung zwischen Dienstbeeinträchtigung und Nichtverfügbarkeit als separate SLOs widerzuspiegeln ist.

• Verwenden Sie das Integritätsmodell in CI/CD-Pipelines und Testzyklen, um zu überprüfen, ob die Anwendungsintegrität nach Code- und Konfigurationsupdates beibehalten wird.

  • Das Integritätsmodell sollte verwendet werden, um die Integrität während Auslastungstests und Chaostests im Rahmen von CI/CD-Prozessen zu beobachten und zu überprüfen.

• Das Erstellen und Verwalten eines Gesundheitsmodells ist ein iterativer Prozess, und die Technischen Investitionen sollten ausgerichtet werden, um kontinuierliche Verbesserungen voranzutreiben.

  • Definieren Sie einen Prozess, um die Genauigkeit des Modells kontinuierlich auszuwerten und zu optimieren, und erwägen Sie, in Machine Learning-Modelle zu investieren, um das Modell weiter zu trainieren.

Beispiel: Mehrschichtige Integritätsmodell

Dies ist eine vereinfachte Darstellung eines mehrstufigen Anwendungsintegritätsmodells zu Veranschaulichungszwecken. Ein umfassendes und kontextbezogenes Integritätsmodell wird in den Mission-Critical-Referenzimplementierungen bereitgestellt:

• Unternehmenskritisch Online
• Unternehmenskritisch verbunden

Bei der Implementierung eines Integritätsmodells ist es wichtig, die Integrität einzelner Komponenten über die Aggregation und Interpretation wichtiger Metriken auf Ressourcenebene zu definieren. Ein Beispiel dafür, wie Ressourcenmetriken verwendet werden können, ist die folgende Abbildung:

Diese Definition der Integrität kann anschließend durch eine KQL-Abfrage dargestellt werden, wie die folgende Beispielabfrage veranschaulicht, die InsightsMetrics (Container Insights) und AzureMetrics (Diagnose Einstellung für AKS-Cluster) aggregiert und (innere Verknüpfung) mit modellierten Integritätsschwellenwerten vergleicht.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

Die resultierende Tabellenausgabe kann anschließend in eine Integritätsbewertung umgewandelt werden, um die Aggregation auf höheren Ebenen des Integritätsmodells zu vereinfachen.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Diese aggregierten Bewertungen können anschließend als Abhängigkeitsdiagramm dargestellt werden, indem Visualisierungstools wie Grafana verwendet werden, um das Integritätsmodell zu veranschaulichen.

Diese Abbildung zeigt ein Beispiel für mehrschichtige Integritätsmodell aus der Azure Mission-Critical Onlinereferenzimplementierung und veranschaulicht, wie sich eine Änderung des Integritätszustands für eine grundlegende Komponente kaskadierende Auswirkungen auf Benutzerflows und die allgemeine Anwendungsintegrität haben kann (die Beispielwerte entsprechen der Tabelle in der vorherigen Abbildung).

Demovideo: Demo zur Überwachung und Integritätsmodellierung

Einheitliche Datensenke für korrelierte Analysen

Viele operative Datasets müssen von allen Systemkomponenten erfasst werden, um ein definiertes Heidemodell genau darzustellen, wobei Protokolle und Metriken sowohl von Anwendungskomponenten als auch von zugrunde liegenden Azure-Ressourcen berücksichtigt werden. Diese große Menge an Daten muss letztendlich in einem Format gespeichert werden, das eine Interpretation nahezu in Echtzeit ermöglicht, um schnelle operative Maßnahmen zu ermöglichen. Darüber hinaus ist eine Korrelation über alle eingeschlossenen Datasets erforderlich, um sicherzustellen, dass eine effektive Analyse nicht gebunden ist, was eine mehrstufige Darstellung der Integrität ermöglicht.

Eine einheitliche Datensenke ist erforderlich, um sicherzustellen, dass alle operativen Daten schnell gespeichert und für korrelierte Analysen zur Verfügung gestellt werden, um eine Darstellung der Anwendungsintegrität in einem einzigen Bereich zu erstellen. Azure bietet unter dem Dach von Azure Monitor mehrere verschiedene Betriebstechnologien, und der Log Analytics-Arbeitsbereich dient als zentrale Azure-native Datensenke zum Speichern und Analysieren von Betriebsdaten.

Überlegungen zum Entwurf

Azure Monitor

• Azure Monitor ist standardmäßig für alle Azure-Abonnements aktiviert, aber Azure Monitor-Protokolle (Log Analytics-Arbeitsbereich) und Application Insights-Ressourcen müssen bereitgestellt und konfiguriert werden, um Datensammlungs- und Abfragefunktionen zu integrieren.

• Azure Monitor unterstützt drei Arten von Beobachtbarkeitsdaten: Protokolle, Metriken und verteilte Ablaufverfolgungen.

  • Protokolle werden in Log Analytics-Arbeitsbereichen gespeichert, die auf Azure Data Explorer basieren. Protokollabfragen werden in Abfragepaketen gespeichert, die abonnementübergreifend freigegeben werden können, und werden verwendet, um Überwachungskomponenten wie Dashboards, Arbeitsmappen oder andere Berichterstellungs- und Visualisierungstools zu steuern.
  • Metriken werden in einer internen Zeitreihendatenbank gespeichert. Für die meisten Azure-Ressourcen werden Metriken automatisch erfasst und 93 Tage lang aufbewahrt . Metrikdaten können auch mithilfe einer Diagnoseeinstellung für die Ressource an den Log Analytics-Arbeitsbereich gesendet werden.

• Alle Azure-Ressourcen machen Protokolle und Metriken verfügbar, aber Ressourcen müssen entsprechend konfiguriert sein, um Diagnosedaten an Die gewünschte Datensenke weiterzuleiten.

Tipp

Azure bietet verschiedene integrierte Richtlinien, die angewendet werden können, um sicherzustellen, dass bereitgestellte Ressourcen so konfiguriert sind, dass Protokolle und Metriken an einen Log Analytics-Arbeitsbereich gesendet werden.

• Es ist nicht ungewöhnlich, dass bei behördlichen Kontrollen betriebsbezogene Daten innerhalb von Ursprungsregionen oder Ländern/Regionen verbleiben. Gesetzliche Anforderungen können die Aufbewahrung kritischer Datentypen für einen längeren Zeitraum vorsehen. Beispielsweise müssen im regulierten Bankwesen Prüfungsdaten mindestens sieben Jahre lang aufbewahrt werden.

• Unterschiedliche Betriebsdatentypen erfordern möglicherweise unterschiedliche Aufbewahrungszeiträume. Beispielsweise müssen Sicherheitsprotokolle möglicherweise für einen längeren Zeitraum aufbewahrt werden, während Leistungsdaten außerhalb des AIOps-Kontexts wahrscheinlich keine langfristige Aufbewahrung erfordern.

• Daten können für langfristige Aufbewahrungs- und/oder Überwachungszwecke aus Log Analytics-Arbeitsbereichen archiviert oder exportiert werden.

• Dedizierte Cluster bieten eine Bereitstellungsoption, die Verfügbarkeitszonen zum Schutz vor Zonenfehlern in unterstützten Azure-Regionen ermöglicht. Dedizierte Cluster erfordern eine minimale tägliche Datenerfassungsverpflichtung.

• Log Analytics-Arbeitsbereiche werden in einer angegebenen Azure-Region bereitgestellt.

• Zum Schutz vor Datenverlusten aufgrund der Nichtverfügbarkeit eines Log Analytics-Arbeitsbereichs können Ressourcen mit mehreren Diagnoseeinstellungen konfiguriert werden. Jede Diagnoseeinstellung kann Metriken und Protokolle an einen separaten Log Analytics-Arbeitsbereich senden.

  • Daten, die an jeden zusätzlichen Log Analytics-Arbeitsbereich gesendet werden, verursachen zusätzliche Kosten.
  • Der redundante Log Analytics-Arbeitsbereich kann in derselben Azure-Region oder in separaten Azure-Regionen bereitgestellt werden, um zusätzliche regionale Redundanz zu erzielen.
  • Beim Senden von Protokollen und Metriken aus einer Azure-Ressource an einen Log Analytics-Arbeitsbereich in einer anderen Region fallen Kosten für den Datenausgang zwischen den Regionen an.
  • Einige Azure-Ressourcen erfordern einen Log Analytics-Arbeitsbereich in derselben Region wie die Ressource selbst.
  • Weitere Verfügbarkeitsoptionen für den Log Analytics-Arbeitsbereich finden Sie unter Bewährte Methoden für Azure Monitor-Protokolle .

• Log Analytics-Arbeitsbereichsdaten können kontinuierlich, geplant oder einmalig in Azure Storage oder Azure Event Hubs exportiert werden.

  • Der Datenexport ermöglicht eine langfristige Datenarchivierung und schützt vor möglichen betriebsbedingten Datenverlusten durch Nichtverfügbarkeit.
  • Verfügbare Exportziele sind Azure Storage oder Azure Event Hubs. Azure Storage kann für unterschiedliche Redundanzstufen konfiguriert werden, einschließlich zonengebundener oder regionaler Redundanzstufen . Beim Datenexport nach Azure Storage werden die Daten in JSON-Dateien gespeichert.
  • Datenexportziele müssen sich in derselben Azure-Region wie der Log Analytics-Arbeitsbereich befinden. Ein Event Hub-Datenexportziel, das sich in derselben Region wie der Log Analytics-Arbeitsbereich befindet. Azure Event Hubs Geo-Notfallwiederherstellung ist für dieses Szenario nicht anwendbar.
  • Es gibt mehrere Einschränkungen für den Datenexport. Nur bestimmte Tabellen im Arbeitsbereich werden für den Datenexport unterstützt.
  • Die Archivierung kann verwendet werden, um Daten in einem Log Analytics-Arbeitsbereich für die langfristige Aufbewahrung zu geringeren Kosten zu speichern, ohne sie zu exportieren.

• Azure Monitor-Protokolle weisen Einschränkungen für Benutzerabfragen auf, die möglicherweise als eingeschränkte Verfügbarkeit für Clients angezeigt werden, z. B. Für Dashboards zur Beobachtbarkeit.

  • Fünf gleichzeitige Abfragen pro Benutzer: Wenn bereits fünf Abfragen ausgeführt werden, werden zusätzliche Abfragen in einer Parallelitätswarteschlange pro Benutzer platziert, bis eine ausgeführte Abfrage endet.
  • Zeit in Parallelitätswarteschlange: Wenn sich eine Abfrage mehr als drei Minuten in der Parallelitätswarteschlange befindet, wird sie beendet und ein Fehlercode 429 zurückgegeben.
  • Parallelitätswarteschlangentiefe: Die Parallelitätswarteschlange ist auf 200 Abfragen beschränkt, und zusätzliche Abfragen werden mit einem Fehlercode von 429 abgelehnt.
  • Abfrageratenlimit: Es gibt ein Limit pro Benutzer von 200 Abfragen pro 30 Sekunden für alle Arbeitsbereiche.

• Abfragepakete sind Azure Resource Manager-Ressourcen, die zum Schützen und Wiederherstellen von Protokollabfragen verwendet werden können, wenn der Log Analytics-Arbeitsbereich nicht verfügbar ist.

  • Abfragepakete enthalten Abfragen als JSON und können ähnlich wie andere Infrastructure-as-Code-Ressourcen außerhalb von Azure gespeichert werden.
    • Bereitstellung über die Microsoft.Insights-REST-API.
    • Wenn ein Log Analytics-Arbeitsbereich neu erstellt werden muss, kann das Abfragepaket über eine extern gespeicherte Definition erneut bereitgestellt werden.

• Application Insights kann in einem arbeitsbereichsbasierten Bereitstellungsmodell bereitgestellt werden, das von einem Log Analytics-Arbeitsbereich unterstützt wird, in dem alle Daten gespeichert sind.

• Die Stichprobenerstellung kann in Application Insights aktiviert werden, um die Menge der gesendeten Telemetriedaten zu reduzieren und die Kosten für die Datenerfassung zu optimieren.

• Alle von Azure Monitor gesammelten Daten, einschließlich Application Insights, werden basierend auf der Menge der erfassten Daten und der Aufbewahrungsdauer der Daten in Rechnung gestellt .

  • In einem Log Analytics-Arbeitsbereich erfasste Daten können bis zu den ersten 31 Tagen (90 Tage, wenn Sentinel aktiviert ist) ohne zusätzliche Kosten aufbewahrt werden.
  • Daten, die in einem arbeitsbereichsbasierten Application Insights erfasst werden, werden für die ersten 90 Tage ohne zusätzliche Kosten aufbewahrt.

• Das Tarifmodell für log Analytics-Verpflichtungen bietet niedrigere Kosten und einen vorhersagbaren Ansatz für die Datenerfassungsgebühren.

  • Jede Nutzung über der Reservierungsstufe wird zum gleichen Preis wie der aktuelle Tarif in Rechnung gestellt.

• Log Analytics, Application Insights und Azure Data Explorer verwenden die Kusto-Abfragesprache (KQL).

• Log Analytics-Abfragen werden als Funktionen im Log Analytics-Arbeitsbereich (savedSearches) gespeichert.

Entwurfsempfehlungen

• Verwenden Sie den Log Analytics-Arbeitsbereich als einheitliche Datensenke, um einen "einzelnen Bereich" für alle betrieblichen Datasets bereitzustellen.

  • Dezentralisieren Sie Log Analytics-Arbeitsbereiche in allen verwendeten Bereitstellungsregionen. Jede Azure-Region mit einer Anwendungsbereitstellung sollte einen Log Analytics-Arbeitsbereich in Betracht ziehen, um alle Betriebsdaten aus dieser Region zu sammeln. Alle globalen Ressourcen sollten einen separaten dedizierten Log Analytics-Arbeitsbereich verwenden, der in einer primären Bereitstellungsregion bereitgestellt werden sollte.
    • Das Senden aller Betriebsdaten an einen einzelnen Log Analytics-Arbeitsbereich würde einen single point of failure erzeugen.
    • Anforderungen für die Datenresidenz können daten verhindern, die Ursprungsregion zu verlassen, und Verbundarbeitsbereiche werden für diese Anforderung standardmäßig gelöst.
    • Mit der Regionsübertragung von Protokollen und Metriken sind erhebliche Ausgehende Kosten verbunden.
  • Alle Bereitstellungsstempel in derselben Region können denselben regionalen Log Analytics-Arbeitsbereich verwenden.

• Erwägen Sie das Konfigurieren von Ressourcen mit mehreren Diagnoseeinstellungen, die auf unterschiedliche Log Analytics-Arbeitsbereiche verweisen, um die Nichtverfügbarkeit von Azure Monitor für Anwendungen mit weniger regionalen Bereitstellungsstempeln zu schützen.

• Nutzen Sie Application Insights als einheitliches Tool zur Anwendungsleistungsüberwachung (Application Performance Monitoring, APM) für alle Anwendungskomponenten und zum Sammeln von Anwendungsprotokollen, Metriken und Ablaufverfolgungsdaten.

  • Stellen Sie Application Insights in einer arbeitsbereichsbasierten Konfiguration bereit, um sicherzustellen, dass jeder regionale Log Analytics-Arbeitsbereich Protokolle und Metriken aus Anwendungskomponenten und zugrunde liegenden Azure-Ressourcen enthält.

• Verwenden Sie arbeitsbereichsübergreifende Abfragen , um einen einheitlichen "einzelnen Bereich" für die verschiedenen Arbeitsbereiche zu verwalten.

• Verwenden Sie Abfragepakete , um Protokollabfragen bei Nichtverfügbarkeit des Arbeitsbereichs zu schützen.

  • Speichern Sie Abfragepakete im Git-Repository der Anwendung als Infrastructure-as-Code-Ressourcen.

• Alle Log Analytics-Arbeitsbereiche sollten als Ressourcen mit langer Ausführungsdauer mit einem anderen Lebenszyklus als Anwendungsressourcen innerhalb eines regionalen Bereitstellungsstempels behandelt werden.

• Exportieren Sie kritische Betriebsdaten aus dem Log Analytics-Arbeitsbereich für langfristige Aufbewahrung und Analysen, um AIOps und erweiterte Analysen zu erleichtern, um das zugrunde liegende Integritätsmodell zu verfeinern und Vorhersagemaßnahmen zu unterstützen.

• Bewerten Sie sorgfältig, welcher Datenspeicher für die langfristige Aufbewahrung verwendet werden soll; nicht alle Daten müssen in einem heißen und abfragbaren Datenspeicher gespeichert werden.

  • Es wird dringend empfohlen, Azure Storage in einer GRS-Konfiguration für die langfristige operative Datenspeicherung zu verwenden.
    • Verwenden Sie die Exportfunktion des Log Analytics-Arbeitsbereichs, um alle verfügbaren Datenquellen in Azure Storage zu exportieren.

• Wählen Sie geeignete Aufbewahrungsfristen für betriebsbezogene Datentypen innerhalb der Protokollanalyse aus, und konfigurieren Sie längere Aufbewahrungszeiträume innerhalb des Arbeitsbereichs, in dem "heiße" Beobachtbarkeitsanforderungen bestehen.

• Verwenden Sie Azure Policy, um sicherzustellen, dass alle regionalen Ressourcen Betriebsdaten an den richtigen Log Analytics-Arbeitsbereich weiterleiten.

Hinweis

Wenn bei der Bereitstellung in einer Azure-Zielzone eine zentrale Speicherung von Betriebsdaten erforderlich ist, können Sie Daten bei der Instanziierung forken , sodass sie sowohl in zentralisierten Tools als auch in Log Analytics-Arbeitsbereichen erfasst werden, die der Anwendung gewidmet sind. Alternativ können Sie den Zugriff auf Log Analytics-Anwendungsarbeitsbereiche verfügbar machen, damit zentrale Teams Anwendungsdaten abfragen können. Es ist letztendlich wichtig, dass Betriebsdaten, die aus der Lösung stammen, in Log Analytics-Arbeitsbereichen verfügbar sind, die für die Anwendung vorgesehen sind.

Wenn die SIEM-Integration erforderlich ist, senden Sie keine unformatierten Protokolleinträge, sondern senden Sie stattdessen kritische Warnungen.

• Konfigurieren Sie die Stichprobenerstellung in Application Insights nur, wenn dies zur Optimierung der Leistung erforderlich ist, oder wenn die Stichprobenerstellung nicht kostenintensiv ist.

  • Eine übermäßige Stichprobenentnahme kann zu verpassten oder ungenauen Betriebssignalen führen.

• Verwenden Sie Korrelations-IDs für alle Ablaufverfolgungsereignisse und Protokollmeldungen, um sie einer bestimmten Anforderung zuzuordnen.

  • Zurückgeben von Korrelations-IDs an den Aufrufer für alle Aufrufe, nicht nur für fehlgeschlagene Anforderungen.

• Stellen Sie sicher, dass der Anwendungscode die richtige Instrumentierung und Protokollierung enthält, um das Integritätsmodell zu informieren und bei Bedarf die nachfolgende Problembehandlung oder Die Ursachenanalyse zu erleichtern.

  • Der Anwendungscode sollte Application Insights verwenden, um die verteilte Ablaufverfolgung zu erleichtern, indem dem Aufrufer eine umfassende Fehlermeldung bereitgestellt wird, die eine Korrelations-ID enthält, wenn ein Fehler auftritt.

• Verwenden Sie die strukturierte Protokollierung für alle Protokollmeldungen.

• Fügen Sie allen Anwendungskomponenten aussagekräftige Integritätstests hinzu.

  • Konfigurieren Sie bei Verwendung von AKS die Integritätsendpunkte für jede Bereitstellung (Pod), damit Kubernetes ordnungsgemäß feststellen kann, ob ein Pod fehlerfrei oder fehlerhaft ist.
  • Konfigurieren Sie bei Verwendung von Azure App Service die Integritätsprüfungen so, dass horizontale Horizontalskalierungsvorgänge keine Fehler verursachen, indem Sie Datenverkehr an Instanzen senden, die noch nicht bereit sind, und stellen Sie sicher, dass fehlerhafte Instanzen schnell wiederverwendet werden.

Wenn die Anwendung beim Microsoft Mission-Critical Support abonniert ist, sollten Sie erwägen, wichtige Integritätstests für Microsoft-Support verfügbar zu machen, damit die Anwendungsintegrität durch Microsoft-Support genauer modelliert werden kann.

• Protokollieren Sie erfolgreiche Integritätsprüfungsanforderungen, es sei denn, höhere Datenmengen können im Kontext der Anwendungsleistung nicht toleriert werden, da sie zusätzliche Erkenntnisse für die analytische Modellierung bieten.

• Konfigurieren Sie keine Produktions-Log Analytics-Arbeitsbereiche, um eine tägliche Obergrenze anzuwenden, die die tägliche Erfassung von Betriebsdaten einschränkt, da dies zum Verlust kritischer Betriebsdaten führen kann.

  • In niedrigeren Umgebungen wie Entwicklung und Test kann eine tägliche Obergrenze als optionaler Mechanismus zur Kosteneinsparung betrachtet werden.

• Wenn die Volumes für die erfassung von betriebsbezogenen Daten den Mindesttarifschwellenwert erreichen, konfigurieren Sie Log Analytics-Arbeitsbereiche so, dass sie auf Verpflichtungsebene basierende Preise verwenden, um die Kosteneffizienz im Verhältnis zum Preismodell mit nutzungsbasierter Bezahlung zu steigern.

• Es wird dringend empfohlen, Log Analytics-Abfragen mithilfe der Quellcodeverwaltung zu speichern und CI/CD-Automatisierung zu verwenden, um sie in relevanten Log Analytics-Arbeitsbereichsinstanzen bereitzustellen.

Visualisierung

Die visuelle Darstellung des Integritätsmodells mit kritischen operativen Daten ist von entscheidender Bedeutung, um effektive Vorgänge zu erzielen und die Zuverlässigkeit zu maximieren. Dashboards sollten letztendlich verwendet werden, um nahezu in Echtzeit Einblicke in die Anwendungsintegrität für DevOps-Teams zu liefern, um die schnelle Diagnose von Abweichungen vom stabilen Zustand zu erleichtern.

Microsoft bietet mehrere Datenvisualisierungstechnologien, einschließlich Azure Dashboards, Power BI und Azure Managed Grafana (derzeit in der Vorschau). Azure Dashboards ist in der Lage, eine eng integrierte sofort einsatzbereite Visualisierungslösung für Betriebsdaten in Azure Monitor bereitzustellen. Es spielt daher eine grundlegende Rolle bei der visuellen Darstellung von Betriebsdaten und der Anwendungsintegrität für eine unternehmenskritische Workload. Es gibt jedoch mehrere Einschränkungen in Bezug auf die Positionierung von Azure Dashboards als ganzheitliche Beobachtbarkeitsplattform, und daher sollte die zusätzliche Verwendung marktführender Beobachtbarkeitslösungen wie Grafana in Betracht gezogen werden, die auch als verwaltete Lösung in Azure bereitgestellt wird.

Dieser Abschnitt konzentriert sich auf die Verwendung von Azure Dashboards und Grafana, um eine robuste Dashboardumgebung zu erstellen, die technische und geschäftliche Objektive für die Anwendungsintegrität bereitstellen und DevOps-Teams und einen effektiven Betrieb ermöglichen kann. Ein robustes Dashboarding ist unerlässlich, um bereits aufgetretene Probleme zu diagnostizieren und operative Teams bei der Erkennung und Reaktion darauf zu unterstützen.

Überlegungen zum Entwurf

• Beachten Sie beim Visualisieren des Integritätsmodells mithilfe von Protokollabfragen, dass es Log Analytics-Grenzwerte für gleichzeitige und Warteschlangenabfragen sowie die Gesamtabfragerate gibt, wobei nachfolgende Abfragen in die Warteschlange eingereiht und gedrosselt werden.

• Abfragen zum Abrufen von Betriebsdaten, die zum Berechnen und Darstellen von Integritätsbewertungen verwendet werden, können in Log Analytics oder Azure Data Explorer geschrieben und ausgeführt werden.

  • Beispielabfragen sind hier verfügbar.

• Log Analytics legt mehrere Abfragegrenzwerte fest, für die beim Entwerfen operativer Dashboards konzipiert werden muss.

• Die Visualisierung von Rohressourcenmetriken, z. B. CPU-Auslastung oder Netzwerkdurchsatz, erfordert eine manuelle Auswertung durch Betriebsteams, um Auswirkungen auf die Integrität status zu ermitteln. Dies kann bei einem aktiven Incident eine Herausforderung darstellen.

• Wenn mehrere Benutzer Dashboards in einem Tool wie Grafana verwenden, vervielfacht sich die Anzahl der an Log Analytics gesendeten Abfragen schnell.

  • Wenn Sie das Limit für gleichzeitige Abfragen in Log Analytics erreichen, werden nachfolgende Abfragen in die Warteschlange gestellt, sodass sich die Dashboard "langsam" anfühlt.

Entwurfsempfehlungen

• Sammeln und präsentieren Sie abgefragte Ausgaben aus allen regionalen Log Analytics-Arbeitsbereichen und dem globalen Log Analytics-Arbeitsbereich, um eine einheitliche Ansicht der Anwendungsintegrität zu erstellen.

Hinweis

Bei der Bereitstellung in einer Azure-Zielzone sollten Sie den Log Analytics-Arbeitsbereich der zentralen Plattform abfragen, wenn wichtige Abhängigkeiten von Plattformressourcen vorhanden sind, z. B. ExpressRoute für die lokale Kommunikation.

• Ein „Ampelmodell“ sollte zum Einsatz kommen, um „fehlerfreie“ und „fehlerhafte“ Zustände visuell darzustellen, wobei „grün“ bedeutet, dass die wichtigsten nicht funktionalen Anforderungen vollständig erfüllt sind und Ressourcen optimal genutzt werden. Verwenden Sie "Grün", "Bernstein" und "Rot", um die Zustände "Fehlerfrei", "Beeinträchtigt" und "Nicht verfügbar" darzustellen.

• Verwenden Sie Azure Dashboards, um Betriebslinsen für globale Ressourcen und regionale Bereitstellungsstempel zu erstellen, die wichtige Metriken wie die Anforderungsanzahl für Azure Front Door, serverseitige Latenz für Azure Cosmos DB, eingehende/ausgehende Nachrichten für Event Hubs und CPU-Auslastung oder Bereitstellungsstatus für AKS darstellen. Dashboards sollten so zugeschnitten sein, dass sie die betriebliche Effektivität steigern und Erkenntnisse aus Fehlerszenarien liefern, um sicherzustellen, dass DevOps-Teams direkten Einblick in wichtige Metriken haben.

• Wenn Azure Dashboards nicht verwendet werden können, um das Integritätsmodell und die erforderlichen Geschäftsanforderungen genau darzustellen, wird dringend empfohlen, Grafana als alternative Visualisierungslösung zu betrachten, die marktführende Funktionen und ein umfangreiches Open-Source-Plug-In-Ökosystem bietet. Bewerten Sie das verwaltete Grafana-Vorschauangebot, um die betriebstechnische Komplexität der Verwaltung der Grafana-Infrastruktur zu vermeiden.

• Verwenden Sie bei der Bereitstellung von selbstgehosteten Grafana ein hochverfügbares und geoverteilbares Design, um sicherzustellen, dass kritische operative Dashboards gegenüber regionalen Plattformausfällen und kaskadierenden Fehlerszenarien widerstandsfähig sein können.

  • Trennen Sie den Konfigurationszustand in einen externen Datenspeicher, z. B. Azure Database for Postgres oder MySQL, um sicherzustellen, dass Grafana-Anwendungsknoten zustandslos bleiben.

    • Konfigurieren der Datenbankreplikation über Bereitstellungsregionen hinweg.

  • Bereitstellen von Grafana-Knoten in App Services in einer hochverfügbaren Konfiguration innerhalb einer Region mithilfe von containerbasierten Bereitstellungen.

    • Stellen Sie App Service Instanzen in betrachteten Bereitstellungsregionen bereit.

    App Services bietet eine Containerplattform mit geringem Reibungsaufwand, die sich ideal für Szenarien mit geringer Skalierung eignet, z. B. operative Dashboards, und die Isolierung von Grafana von AKS bietet eine klare Trennung zwischen der primären Anwendungsplattform und den operativen Darstellungen für diese Plattform. Weitere Konfigurationsempfehlungen finden Sie im Bereich Application Platform Deign.

  • Verwenden Sie Azure Storage in einer GRS-Konfiguration, um benutzerdefinierte Visuals und Plug-Ins zu hosten und zu verwalten.

  • Stellen Sie Grafana-Komponenten für App Service und Datenbank-Lesereplikate in mindestens zwei Bereitstellungsregionen bereit, und erwägen Sie, ein Modell zu verwenden, bei dem Grafana in allen betrachteten Bereitstellungsregionen bereitgestellt wird.

Für Szenarien mit einem >SLO von 99,99 % sollte Grafana in mindestens 3 Bereitstellungsregionen bereitgestellt werden, um die Gesamtzuverlässigkeit für wichtige operative Dashboards zu maximieren.

• Verringern Sie die Log Analytics-Abfragelimits, indem Sie Abfragen in eine einzelne oder kleine Anzahl von Abfragen aggregieren, z. B. mithilfe des KQL-Operator union, und legen Sie eine entsprechende Aktualisierungsrate für die Dashboard fest.

  • Eine angemessene maximale Aktualisierungsrate hängt von der Anzahl und Komplexität der Dashboard Abfragen ab. Eine Analyse der implementierten Abfragen ist erforderlich.

• Wenn das Gleichzeitige Abfragelimit von Log Analytics erreicht wird, sollten Sie das Abrufmuster optimieren, indem Sie die für die Dashboard erforderlichen Daten (vorübergehend) in einem Hochleistungsdatenspeicher wie Azure SQL speichern.

Automatisierte Reaktion auf Vorfälle

Wenngleich die visuelle Darstellung der Anwendungsintegrität wertvolle operative und geschäftliche Erkenntnisse liefert, um die Problemerkennung und -diagnose zu unterstützen, ist es erforderlich, dass operative Teams angemessen reagieren und diese Erkenntnisse richtig interpretieren. Ebenso müssen die von Menschen ausgelösten Reaktionen auf ermittelte Probleme effektiv sein. Daher ist es erforderlich, um die Zuverlässigkeit zu maximieren, umfangreiche Warnungen zu implementieren, um proaktiv zu erkennen und nahezu in Echtzeit auf Probleme zu reagieren.

Azure Monitor bietet ein umfassendes Warnungsframework zum Erkennen, Kategorisieren und Reagieren auf Betriebssignale über Aktionsgruppen. Dieser Abschnitt konzentriert sich daher auf die Verwendung von Azure Monitor-Warnungen zum Ausführen automatisierter Aktionen als Reaktion auf aktuelle oder potenzielle Abweichungen von einem fehlerfreien Anwendungszustand.

Wichtig

Warnungen und automatisierte Aktionen sind wichtig, um Probleme effektiv zu erkennen und schnell zu reagieren, bevor größere negative Auswirkungen auftreten können. Warnungen bieten auch einen Mechanismus, um eingehende Signale zu interpretieren und zu reagieren, um Probleme zu verhindern, bevor sie auftreten.

Überlegungen zum Entwurf

• Warnungsregeln werden so definiert, dass sie ausgelöst werden, wenn ein bedingtes Kriterium für eingehende Signale erfüllt ist, die verschiedene Datenquellen wie Metriken, Protokollabfragen oder Verfügbarkeitstests umfassen können.

• Warnungen können in Log Analytics oder Azure Monitor für die jeweilige Ressource definiert werden.

• Einige Metriken können nur in Azure Monitor abfragt werden, da nicht alle Diagnosedatenpunkte in Log Analytics verfügbar gemacht werden.

• Die Azure Monitor-Warnungs-API kann verwendet werden, um aktive und historische Warnungen abzurufen.

• Es gibt Abonnementlimits für Warnungen und Aktionsgruppen, die für folgendes konzipiert sein müssen:

  • Für die Anzahl konfigurierbarer Warnungsregeln gibt es Grenzwerte.
  • Die Warnungs-API weist Einschränkungen auf, die bei extremen Nutzungsszenarien berücksichtigt werden sollten.
  • Aktionsgruppen weisen mehrere feste Grenzwerte für die Anzahl konfigurierbarer Antworten auf, für die entworfen werden muss.
    • Jeder Antworttyp hat ein Limit von 10 Aktionen, abgesehen von E-Mail, die ein Limit von 1.000 Aktionen hat.

• Warnungen können in ein mehrschichtiges Integritätsmodell integriert werden, indem eine Warnungsregel für eine gespeicherte Protokollsuchabfrage aus der Stammbewertungsfunktion des Modells erstellt wird. Beispiel: Verwenden von "WebsiteHealthScore" und Warnungen für einen numerischen Wert, der den Zustand "Fehlerhaft" darstellt.

Entwurfsempfehlungen

• Erstellen Sie für ressourcenorientierte Warnungen Warnungsregeln in Azure Monitor, um sicherzustellen, dass alle Diagnosedaten für die Warnungsregelkriterien verfügbar sind.

• Konsolidieren Sie automatisierte Aktionen in einer minimalen Anzahl von Aktionsgruppen, die so auf Dienstteams abgestimmt sind, dass ein DevOps-Ansatz unterstützt wird.

• Reagieren Sie auf Signale einer übermäßigen Ressourcenauslastung durch automatisierte Skalierungsvorgänge, und nutzen Sie dabei nach Möglichkeit native Azure-Funktionen für die automatische Skalierung. Wenn die integrierte Funktion zur automatischen Skalierung nicht in Frage kommt, verwenden Sie den Integritätspunktwert der Komponente, um Signale zu modellieren und zu bestimmen, wann Sie mit automatischen Skalierungsvorgängen reagieren müssen. Stellen Sie sicher, dass automatisierte Skalierungsvorgänge gemäß einem Kapazitätsmodell definiert werden. Dieses Modell quantifiziert die Skalierungsbeziehungen zwischen Komponenten, sodass Skalierungsreaktionen die Komponenten umfassen, die im Verhältnis zu anderen Komponenten skaliert werden müssen.

• Modellaktionen, um eine priorisierte Reihenfolge zu berücksichtigen, die von den Geschäftlichen Auswirkungen bestimmt werden sollte.

• Verwenden Sie die Azure Monitor-Warnungs-API, um Verlaufswarnungen zu sammeln, die in den "kalten" betrieblichen Speicher für erweiterte Analysen integriert werden.

• Für kritische Fehlerszenarien, die nicht mit einer automatisierten Antwort erfüllt werden können, stellen Sie sicher, dass die operative "Runbookautomatisierung" vorhanden ist, um schnelle und konsistente Maßnahmen zu ermöglichen, sobald eine manuelle Interpretation und Abmeldung bereitgestellt wurde. Verwenden von Warnungsbenachrichtigungen, um die schnelle Identifizierung von Problemen zu fördern, die eine manuelle Interpretation erfordern

• Erstellen Sie Zertifikate innerhalb von Engineering-Sprints, um inkrementelle Verbesserungen bei Warnungen voranzutreiben, um sicherzustellen, dass neue Fehlerszenarien, die bisher nicht berücksichtigt wurden, in neuen automatisierten Aktionen vollständig berücksichtigt werden können.

• Führen Sie als Teil von CI/CD-Prozessen Betriebsbereitschaftstests durch, um wichtige Warnungsregeln für Bereitstellungsaktualisierungen zu überprüfen.

Predictive Action und KI-Vorgänge (AIOps)

Machine Learning-Modelle können angewendet werden, um Betriebsdaten zu korrelieren und zu priorisieren, um wichtige Erkenntnisse im Zusammenhang mit der Filterung übermäßiger Warnungsgeräusche und der Vorhersage von Problemen zu gewinnen, bevor sie Auswirkungen haben, sowie die Reaktion auf Vorfälle zu beschleunigen, wenn dies der Fall ist.

Genauer gesagt kann eine AIOps-Methodik auf wichtige Erkenntnisse über das Verhalten des Systems, der Benutzer und der DevOps-Prozesse angewendet werden. Zu diesen Erkenntnissen gehören die Identifizierung eines problems, das jetzt auftritt (erkennen), quantifizieren, warum das Problem auftritt (Diagnose) oder das Signalisieren, was in zukunft passieren wird (vorhersagen). Solche Erkenntnisse können verwendet werden, um Aktionen voranzutreiben, die die Anwendung anpassen und optimieren, um aktive oder potenzielle Probleme zu beheben, indem wichtige Geschäftsmetriken, Systemqualitätsmetriken und DevOps-Produktivitätsmetriken verwendet werden, um entsprechend den geschäftlichen Auswirkungen zu priorisieren. Durchgeführte Aktionen können selbst über eine Feedbackschleife in das System integriert werden, die das zugrunde liegende Modell weiter trainiert, um zusätzliche Effizienz zu erzielen.

Es gibt mehrere Analysetechnologien in Azure, z. B. Azure Synapse und Azure Databricks, mit denen analytische Modelle für AIOps erstellt und trainiert werden können. In diesem Abschnitt geht es darum, wie diese Technologien innerhalb eines Anwendungsentwurfs positioniert werden können, um KIOps zu berücksichtigen und Vorhersageaktionen zu fördern. Dabei geht es um Azure Synapse, die die Reibung reduzieren, indem die besten Datendienste von Azure zusammen mit leistungsstarken neuen Features zusammengeführt werden.

AIOps wird verwendet, um prädiktive Aktionen zu fördern, komplexe Betriebssignale zu interpretieren und zu korrelieren, die über einen längeren Zeitraum beobachtet werden, um Probleme besser zu reagieren und zu verhindern, bevor sie auftreten.

Überlegungen zum Entwurf

• Azure Synapse Analytics bietet mehrere Ml-Funktionen (Machine Learning).

  • ML-Modelle können in Synapse Spark-Pools mit Bibliotheken wie MLLib, SparkML und MMLSpark sowie beliebten Open-Source-Bibliotheken wie Scikit Learn trainiert und ausgeführt werden.
  • ML-Modelle können mit gängigen Data Science-Tools wie PySpark/Python, Scala oder .NET trainiert werden.

• Synapse Analytics ist über Azure Synapse Notebooks in Azure ML integriert, sodass ML-Modelle in einem Azure ML-Arbeitsbereich mithilfe von Automatisiertem ML trainiert werden können.

• Synapse Analytics ermöglicht auch ML-Funktionen mithilfe von Azure Cognitive Services , um allgemeine Probleme in verschiedenen Domänen zu lösen, z. B. Anomalieerkennung. Cognitive Services kann in Azure Synapse, Azure Databricks und über SDKs und REST-APIs in Clientanwendungen verwendet werden.

• Azure Synapse nativ in Azure Data Factory Tools zum Extrahieren, Transformieren und Laden von Daten (ETL) oder Erfassung von Daten in Orchestrierungspipelines integriert.

• Azure Synapse ermöglicht die Registrierung externer Datasets für Daten, die in Azure Blob Storage oder Azure Data Lake Storage gespeichert sind.

  • Registrierte Datasets können in Synapse Spark-Pool-Datenanalyseaufgaben verwendet werden.

• Azure Databricks kann für zusätzliche Spark-Funktionen in Azure Synapse Analytics-Pipelines integriert werden.

  • Synapse orchestriert das Lesen und Senden von Daten an einen Databricks-Cluster, wo sie transformiert und für das ML-Modelltraining vorbereitet werden können.

• Quelldaten müssen in der Regel für Analysen und ML vorbereitet werden.

  • Synapse bietet verschiedene Tools zur Unterstützung bei der Datenaufbereitung, darunter Apache Spark, Synapse Notebooks und serverlose SQL-Pools mit T-SQL und integrierten Visualisierungen.

• ML-Modelle, die trainiert, operationalisiert und bereitgestellt wurden, können für die Batchbewertung in Synapse verwendet werden.

  • AIOps-Szenarien, z. B. das Ausführen von Regressions- oder Verschlechterungsvorhersagen in CI/ CD-Pipelines , erfordern möglicherweise eine Bewertung in Echtzeit.

• Es gibt Abonnementlimits für Azure Synapse, die im Kontext einer AIOps-Methodik vollständig verstanden werden sollten.

• Um AIOps vollständig zu integrieren, ist es notwendig, nahezu echtzeitbasierte Beobachtbarkeitsdaten in Ml-Rückschlussmodelle in Echtzeit einzuspeisen.

  • Funktionen wie die Anomalieerkennung sollten innerhalb des Datenstroms zur Beobachtbarkeit ausgewertet werden.

Entwurfsempfehlungen

• Stellen Sie sicher, dass alle Azure-Ressourcen und -Anwendungskomponenten vollständig instrumentiert sind, damit ein vollständiges operatives Dataset für die AIOps-Modellschulung verfügbar ist.

• Erfassen Sie Log Analytics-Betriebsdaten aus den globalen und regionalen Azure Storage-Konten in Azure Synapse zur Analyse.

• Verwenden Sie die Azure Monitor-Warnungs-API, um verlaufsbezogene Warnungen abzurufen und sie im Cold Storage zu speichern, damit betriebsbezogene Daten später in ML-Modellen verwendet werden können. Wenn der Log Analytics-Datenexport verwendet wird, speichern Sie Verlaufswarnungsdaten in den gleichen Azure Storage-Konten wie die exportierten Log Analytics-Daten.

• Nachdem die erfassten Daten für das ML-Training vorbereitet wurden, schreiben Sie sie wieder in Azure Storage, sodass sie für das ML-Modelltraining verfügbar sind, ohne dass Synapse-Datenvorbereitungs-Computeressourcen ausgeführt werden müssen.

• Stellen Sie sicher, dass die Operationalisierung des ML-Modells sowohl die Batch- als auch die Echtzeitbewertung unterstützt.

• Wenn AIOps-Modelle erstellt werden, implementieren Sie MLOps und wenden Sie DevOps-Methoden an, um den ML-Lebenszyklus für Training, Operationalisierung, Bewertung und kontinuierliche Verbesserung zu automatisieren. Erstellen Sie einen iterativen CI/CD-Prozess für AIOps ML-Modelle.

• Bewerten Sie Azure Cognitive Services aufgrund des geringen Verwaltungs- und Integrationsaufwands für bestimmte Vorhersageszenarien. Betrachten Sie die Anomalieerkennung , um unerwartete Abweichungen in Datenströmen der Beobachtbarkeit schnell zu kennzeichnen.

Nächster Schritt

Sehen Sie sich die Überlegungen zur Bereitstellung und zum Testen an.

Bereitstellung und Tests