Shromažďování, dotazování a vizualizace stavů
Pokud chcete přesně znázorňovat model stavu, musíte shromáždit různé datové sady ze systému. Datové sady zahrnují protokoly a metriky výkonu z komponent aplikací a základních prostředků Azure. Je důležité korelovat data mezi datovými sadami za účelem vytvoření vrstvené reprezentace stavu systému.
Instrumentace kódu a infrastruktury
Jednotná datová jímka se vyžaduje, aby se všechna provozní data ukládaly a byly dostupné v jediném umístění, kde se shromažďují všechna telemetrická data. Když například zaměstnanec ve webovém prohlížeči vytvoří komentář, můžete tuto operaci sledovat a zjistit, že žádost prošla rozhraním API katalogu do služby Azure Event Hubs. Odtud byl komentář vyzvednut procesorem na pozadí a uloženým ve službě Azure Cosmos DB.
Azure Monitor Log Analytics slouží jako základní jednotná datová jímka nativní pro Azure pro ukládání a analýzu provozních dat:
Aplikační Přehledy je doporučený nástroj APM (Application Sledování výkonu ing) napříč všemi komponentami aplikace, který shromažďuje protokoly aplikací, metriky a trasování. Aplikační Přehledy se nasadí v konfiguraci založené na pracovním prostoru v každé oblasti.
V ukázkové aplikaci se Azure Functions používá v microsoft .NET 6 pro své back-endové služby pro nativní integraci. Vzhledem k tomu, že back-endové aplikace už existují, společnost Contoso Shoes vytvoří pouze nový prostředek Přehledy aplikace v Azure a nakonfiguruje
APPLICATIONINSIGHTS_CONNECTION_STRINGnastavení pro obě aplikace funkcí. Modul runtime Azure Functions zaregistruje zprostředkovatele protokolování aplikace Přehledy automaticky, takže telemetrie se zobrazí v Azure bez dalšího úsilí. K přizpůsobení protokolování můžete použít rozhraní ILogger.Centralizovaná datová sada je antipattern pro klíčové úlohy. Každá oblast musí mít vyhrazený pracovní prostor služby Log Analytics a instanci Přehledy aplikace. U globálních prostředků se doporučují samostatné instance. Základní vzor architektury najdete v tématu Model architektury pro klíčové úlohy v Azure.
Každá vrstva by měla odesílat data do stejného pracovního prostoru služby Log Analytics, aby se usnadnily výpočty analýzy a stavu.
Dotazy monitorování stavu
Log Analytics, application Přehledy a Azure Data Explorer používají pro své dotazy dotazovací jazyk Kusto (KQL). KQL můžete použít k sestavení dotazů a použití funkcí k načtení metrik a výpočtu skóre stavu.
Jednotlivé služby, které vypočítají stav, najdete v následujících ukázkových dotazech.
Rozhraní API pro katalog
Následující ukázka ukazuje dotaz rozhraní API katalogu:
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
Následující ukázka ukazuje dotaz služby Azure Key Vault:
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)
Skóre Stav služby katalogu
Nakonec můžete spojit různé dotazy na stav a vypočítat skóre stavu komponenty. Následující ukázkový dotaz ukazuje, jak vypočítat skóre katalogu Stav služby:
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
Další příklady dotazů najdete v úložišti GitHubu Azure Mission-Critical Online .
Nastavení upozornění založených na dotazech
Výstrahy vyvolávají okamžitou pozornost problémům, které odrážejí nebo ovlivňují stav. Kdykoli dojde ke změně stavu, ať už ke zhoršení (žlutému) stavu, nebo ke špatnému stavu (červenému) stavu, měla by se oznámení odeslat zodpovědnému týmu. Nastavte upozornění v kořenovém uzlu modelu stavu, abyste okamžitě věděli o všech změnách na úrovni podniku ve stavu řešení. Pak se můžete podívat na vizualizace modelu stavu a získat další informace a řešit potíže.
V příkladu se používají upozornění služby Azure Monitor k řízení automatizovaných akcí v reakci na změny stavu aplikace.
Použití řídicích panelů pro vizualizaci
Je důležité vizualizovat model stavu, abyste mohli rychle porozumět vlivu výpadku komponenty na celý systém. Konečným cílem zdravotnického modelu je usnadnit rychlou diagnózu poskytnutím informovaného pohledu na odchylky od stabilního stavu.
Běžným způsobem, jak vizualizovat informace o stavu systému, je kombinovat zobrazení modelu stavu vrstvené s možnostmi přechodu k podrobnostem telemetrie na řídicím panelu.
Technologie řídicího panelu by měla být schopná reprezentovat model stavu. Mezi oblíbené možnosti patří Řídicí panely Azure, Power BI a Azure Managed Grafana.