Statussen verzamelen, opvragen en visualiseren
Als u een statusmodel nauwkeurig wilt weergeven, moet u verschillende gegevenssets van het systeem verzamelen. De gegevenssets bevatten logboeken en prestatiegegevens van toepassingsonderdelen en onderliggende Azure-resources. Het is belangrijk om gegevens tussen de gegevenssets te correleren om een gelaagde weergave van de status voor het systeem te bouwen.
Instrumentering van code en infrastructuur
Een geïntegreerde gegevenssink is vereist om ervoor te zorgen dat alle operationele gegevens worden opgeslagen en beschikbaar zijn op één locatie waar alle telemetriegegevens worden verzameld. Wanneer een werknemer bijvoorbeeld een opmerking in zijn webbrowser maakt, kunt u deze bewerking bijhouden en zien dat de aanvraag via de Catalogus-API naar Azure Event Hubs is verzonden. Van daaruit heeft de achtergrondprocessor de opmerking opgehaald en opgeslagen in Azure Cosmos DB.
Azure Monitor Log Analytics fungeert als de kern van de geïntegreerde Azure-gegevenssink voor het opslaan en analyseren van operationele gegevens:
Application Insights is het aanbevolen APM-hulpprogramma (Application Performance Monitoring) voor alle toepassingsonderdelen om toepassingslogboeken, metrische gegevens en traceringen te verzamelen. Application Insights wordt geïmplementeerd in een configuratie op basis van een werkruimte in elke regio.
In de voorbeeldtoepassing wordt Azure Functions gebruikt op Microsoft .NET 6 voor de back-endservices voor systeemeigen integratie. Omdat de back-endtoepassingen al bestaan, maakt Contoso Shoes alleen een nieuwe Application Insights-resource in Azure en configureert de
APPLICATIONINSIGHTS_CONNECTION_STRINGinstelling voor beide functie-apps. De Azure Functions-runtime registreert de Application Insights-logboekregistratieprovider automatisch, zodat telemetrie wordt weergegeven in Azure zonder extra inspanning. Voor meer aangepaste logboekregistratie kunt u deILoggerinterface gebruiken.Gecentraliseerde gegevensset is een antipatroon voor bedrijfskritieke workloads. Elke regio moet de toegewezen Log Analytics-werkruimte en een Application Insights-exemplaar hebben. Voor globale resources worden afzonderlijke exemplaren aanbevolen. Zie het architectuurpatroon voor bedrijfskritieke workloads in Azure om het kernarchitectuurpatroon te bekijken.
Elke laag moet gegevens verzenden naar dezelfde Log Analytics-werkruimte, om analyse- en statusberekeningen eenvoudiger te maken.
Statuscontrolequery's
Log Analytics, Application Insights en Azure Data Explorer gebruiken allemaal Kusto-querytaal (KQL) voor hun query's. U kunt KQL gebruiken om query's te bouwen en functies te gebruiken om metrische gegevens op te halen en statusscores te berekenen.
Zie de volgende voorbeeldquery's voor afzonderlijke services die de status berekenen.
Catalog API
In het volgende voorbeeld ziet u een Catalogus-API-query:
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 Key Vault
In het volgende voorbeeld ziet u een Azure Key Vault-query:
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)
Catalogus Servicestatus score
Uiteindelijk kunt u verschillende statusstatusquery's samenvoegen om een statusscore van een onderdeel te berekenen. In de volgende voorbeeldquery ziet u hoe u een catalogus Servicestatus score berekent:
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
Tip
Bekijk meer queryvoorbeelden in de GitHub-opslagplaats Azure Mission-Critical Online .
Waarschuwingen op basis van query's instellen
Waarschuwingen vestigen onmiddellijke aandacht op problemen die de status weerspiegelen of beïnvloeden. Wanneer er een wijziging in de status is, ofwel in een gedegradeerde (gele) status of in een beschadigde (rode) status, moeten meldingen worden verzonden naar het verantwoordelijke team. Stel waarschuwingen in op het hoofdknooppunt van het statusmodel om onmiddellijk op de hoogte te worden van elke wijziging op bedrijfsniveau in de status van de oplossing. Vervolgens kunt u de visualisaties van het statusmodel bekijken om meer informatie te krijgen en om problemen op te lossen.
In het voorbeeld worden Azure Monitor-waarschuwingen gebruikt om geautomatiseerde acties uit te voeren als reactie op wijzigingen in de status van de toepassing.
Dashboards gebruiken voor visualisatie
Het is belangrijk om uw statusmodel te visualiseren, zodat u snel inzicht krijgt in het effect van een storing in een onderdeel op het hele systeem. Het ultieme doel van een gezondheidsmodel is om snelle diagnose te vergemakkelijken door geïnformeerde kijk te geven op afwijkingen van een stabiele toestand.
Een veelvoorkomende manier om systeemstatusgegevens te visualiseren, is door een gelaagde statusmodelweergave te combineren met mogelijkheden voor inzoomen op telemetrie in een dashboard.
De dashboardtechnologie moet het statusmodel kunnen vertegenwoordigen. Populaire opties zijn Onder andere Azure Dashboards, Power BI en Azure Managed Grafana.