Erfassen, Abfragen und Visualisieren von Integritätszuständen
Um ein Integritätsmodell genau darzustellen, müssen Sie verschiedene Datasets aus dem System sammeln. Zu diesen Datasets zählen Protokolle und Leistungsmetriken aus Anwendungskomponenten und zugrunde liegenden Azure-Ressourcen. Es ist wichtig, die Daten zwischen den Datasets zu korrelieren, um eine mehrschichtige Darstellung der Integrität für das System zu erstellen.
Instrumentieren von Code und Infrastruktur
Eine vereinheitlichte Datensenke ist erforderlich, um sicherzustellen, dass alle operativen Daten an einem Ort gespeichert und verfügbar sind, an dem alle Telemetriedaten erfasst werden. Wenn ein*e Mitarbeiter*in beispielsweise einen Kommentar in ihrem Webbrowser erstellt, können Sie diesen Vorgang nachverfolgen und feststellen, dass die Anforderung über die Katalog-API an Azure Event Hubs gesendet wurde. Von dort aus hat der Hintergrundprozessor den Kommentar aufgenommen und in Azure Cosmos DB gespeichert.
Azure Monitor Log Analytics dient als zentrale und vereinheitlichte Azure-native Datensenke zum Speichern und Analysieren von operativen Daten:
Application Insights ist das empfohlene Tool zur Anwendungsleistungsüberwachung (Application Performance Monitoring, APM) für alle Anwendungskomponenten und zum Sammeln von Anwendungsprotokollen, Metriken und Ablaufverfolgungsdaten. Application Insights wird in einer arbeitsbereichsbasierten Konfiguration in jeder Region bereitgestellt.
In der Beispielanwendung wird Azure Functions aufgrund der Back-End-Dienste für die native Integration mit Microsoft .NET 6 verwendet. Da die Back-End-Anwendungen bereits vorhanden sind, erstellt Contoso Shoes nur eine neue Application Insights-Ressource in Azure und konfiguriert die
APPLICATIONINSIGHTS_CONNECTION_STRING-Einstellung für beide Funktions-Apps. Die Azure Functions-Runtime registriert den Application Insights-Protokollierungsanbieter automatisch, sodass Telemetriedaten ohne zusätzlichen Aufwand in Azure angezeigt werden. Für eine besser angepasste Protokollierung können Sie dieILogger-Schnittstelle verwenden.Ein zentralisiertes Dataset ist ein Antimuster für unternehmenskritische Workloads. Jede Region muss über einen dedizierten Log Analytics-Arbeitsbereich und eine Application Insights-Instanz verfügen. Für globale Ressourcen werden separate Instanzen empfohlen. Das allgemeine Architekturmuster finden Sie unter Architekturmuster für unternehmenskritische Workloads in Azure.
Jede Schicht sollte Daten an denselben Log Analytics-Arbeitsbereich senden, um Analysen und Integritätsberechnungen zu vereinfachen.
Abfragen zur Systemüberwachung
Log Analytics, Application Insights und Azure Data Explorer verwenden die Kusto-Abfragesprache (KQL) für Abfragen. Mit KQL können Sie Abfragen erstellen und Funktionen zum Abrufen von Metriken und zum Berechnen von Integritätsbewertungen verwenden.
Informationen zu einzelnen Diensten, die den Integritätsstatus berechnen, finden Sie in den folgenden Beispielabfragen.
Katalog-API
Im folgenden Beispiel wird eine Katalog-API-Abfrage veranschaulicht:
let _maxAge = 2d; // Include data only from the last two days
let _timespanStart = ago(_maxAge); // Start time for the time span
let _timespanEnd = now(-2m); // Account for ingestion lag by stripping the last 2m
// For time frame, compare the averages to the following threshold values
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
"failureCount", 10, 50, // Failed requests, anything non-200, allow a few more than 0 for user-caused errors like 404s
"avgProcessingTime", 150, 500 // Average duration of the request, in ms
];
// Calculate average processing time for each request
let avgProcessingTime = AppRequests
| where AppRoleName startswith "CatalogService"
| where OperationName != "GET /health/liveness" // Liveness requests don't do any processing, including them would skew the results
| make-series Value = avg(DurationMs) default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName= 'avgProcessingTime';
// Calculate failed requests
let failureCount = AppRequests
| where AppRoleName startswith "CatalogService" // Liveness requests don't do any processing, including them would skew the results
| where OperationName != "GET /health/liveness"
| make-series Value=countif(Success != true) default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName= 'failureCount';
// Union all together and join with the thresholds
avgProcessingTime
| union failureCount
| lookup kind = inner Thresholds on MetricName
| extend IsYellow = iff(todouble(Value) > YellowThreshold and todouble(Value) < RedThreshold, 1, 0)
| extend IsRed = iff(todouble(Value) > RedThreshold, 1, 0)
| project-reorder TimeGenerated, MetricName, Value, IsYellow, IsRed, YellowThreshold, RedThreshold
| extend ComponentName="CatalogService"
Azure-Schlüsseltresor
Im folgenden Beispiel wird eine Azure Key Vault-Abfrage veranschaulicht:
let _maxAge = 2d; // Include data only from the last two days
let _timespanStart = ago(_maxAge); // Start time for the time span
let _timespanEnd = now(-2m); // Account for ingestion lag by stripping the last 2m
// For time frame, compare the averages to the following threshold values
let Thresholds = datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
"failureCount", 3, 10 // Failure count on key vault requests
];
let failureStats = AzureDiagnostics
| where TimeGenerated > _timespanStart
| where ResourceProvider == "MICROSOFT.KEYVAULT"
// Ignore authentication operations that have a 401. This is normal when using Key Vault SDK. First an unauthenticated request is made, then the response is used for authentication
| where Category=="AuditEvent" and not (OperationName == "Authentication" and httpStatusCode_d == 401)
| where OperationName in ('SecretGet','SecretList','VaultGet') or '*' in ('SecretGet','SecretList','VaultGet')
// Exclude Not Found responses because these happen regularly during 'Terraform plan' operations, when Terraform checks for the existence of secrets
| where ResultSignature != "Not Found"
// Create ResultStatus with all the 'success' results bucketed as 'Success'
// Certain operations like StorageAccountAutoSyncKey have no ResultSignature; for now, also set to 'Success'
| extend ResultStatus = case ( ResultSignature == "", "Success",
ResultSignature == "OK", "Success",
ResultSignature == "Accepted", "Success",
ResultSignature);
failureStats
| make-series Value=countif(ResultStatus != "Success") default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName="failureCount", ComponentName="Keyvault"
| lookup kind = inner Thresholds on MetricName
| extend IsYellow = iff(todouble(Value) > YellowThreshold and todouble(Value) < RedThreshold, 1, 0)
| extend IsRed = iff(todouble(Value) > RedThreshold, 1, 0)
Integritätsbewertung für den Katalogdienst
Schließlich können Sie verschiedene Integritätsstatusabfragen verknüpfen, um die Integritätsbewertung einer Komponente zu berechnen. In der folgenden Beispielabfrage wird gezeigt, wie die Integritätsbewertung des Katalogdiensts berechnet wird:
CatalogServiceHealthStatus()
| union AksClusterHealthStatus()
| union KeyvaultHealthStatus()
| union EventHubHealthStatus()
| where TimeGenerated < ago(2m)
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed) by bin(TimeGenerated, 2m)
| extend HealthScore = 1 - (YellowScore * 0.25) - (RedScore * 0.5)
| extend ComponentName = "CatalogService", Dependencies="AKSCluster,Keyvault,EventHub" // These values are added to build the dependency visualization
| order by TimeGenerated desc
Tipp
Weitere Abfragebeispiele finden Sie im GitHub-Repository Azure Mission-Critical Online.
Einrichten von abfragebasierten Warnungen
Warnungen machen sofortig auf Probleme aufmerksam, die den Integritätszustand widerspiegeln oder beeinflussen. Wenn sich der Integritätszustand ändert, entweder in einen heruntergestuften (gelb) oder einen fehlerhaften (rot) Zustand, sollten Benachrichtigungen an das zuständige Team gesendet werden. Legen Sie Warnungen auf dem Stammknoten des Integritätsmodells fest, um sofort über jede Änderung des Integritätszustands der Lösung auf Geschäftsebene informiert zu werden. Anschließend können Sie sich Visualisierungen des Integritätsmodells ansehen, um weitere Informationen zu erhalten und Probleme zu behandeln.
Im Beispiel werden Azure Monitor-Warnungen verwendet, um automatisierte Aktionen als Reaktion auf Änderungen am Integritätszustand der Anwendung zu steuern.
Verwenden von Dashboards für die Visualisierung
Es ist wichtig, Ihr Integritätsmodell zu visualisieren, damit Sie die Auswirkungen eines Komponentenausfalls auf das gesamte System schnell verstehen können. Das ultimative Ziel eines Integritätsmodells besteht darin, eine schnelle Diagnose zu ermöglichen, indem eine fundierte Übersicht der Abweichungen vom stabilen Zustand bereitgestellt wird.
Eine gängige Möglichkeit zum Visualisieren von Systemintegritätsinformationen besteht darin, eine mehrschichtige Integritätsmodellansicht mit Drilldownfunktionen für Telemetriedaten in einem Dashboard zu kombinieren.
Die Dashboardtechnologie sollte das Integritätsmodell darstellen können. Beliebte Optionen sind Azure Dashboards, Power BI und Azure Managed Grafana.