Hälsomodellering för verksamhetskritiska arbetsbelastningar

Övervakning av program och infrastruktur är en viktig del av alla infrastrukturdistributioner. För en verksamhetskritisk arbetsbelastning är övervakning en viktig del av distributionen. Övervakning av programmets hälsa och viktiga mått för Azure-resurser hjälper dig att förstå om miljön fungerar som förväntat.

För att fullt ut förstå dessa mått och utvärdera den övergripande hälsan för en arbetsbelastning krävs en holistisk förståelse av alla data som övervakas. En hälsomodell kan hjälpa till med utvärderingen av den övergripande hälsostatusen genom att visa en tydlig indikation på hälsotillståndet för arbetsbelastningen i stället för råmått. Statusen visas ofta som "trafikljus"-indikatorer som röd, grön eller gul. En representation av en hälsomodell med tydliga indikatorer gör det intuitivt för en operatör att förstå arbetsbelastningens övergripande hälsa och snabbt svara på problem som uppstår.

Hälsomodellering kan utökas till följande operativa uppgifter för den verksamhetskritiska distributionen:

• Program Hälsotjänst – Programkomponent i beräkningsklustret som tillhandahåller ett API för att fastställa hälsotillståndet för en stämpel.

• Övervakning – Insamling av prestanda- och programräknare som utvärderar programmets och infrastrukturens hälsa och prestanda.

• Aviseringar – Åtgärdsbara aviseringar om problem eller avbrott i infrastrukturen och programmet.

• Felanalys – Uppdelning och analys av eventuella fel, inklusive dokumentation om rotorsaken.

Dessa uppgifter utgör en omfattande hälsomodell för den verksamhetskritiska infrastrukturen. Utvecklingen av en hälsomodell kan och bör vara en fullständig och integrerad del av alla verksamhetskritiska distributioner.

Mer information finns i Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure.

Program Hälsotjänst

Application Hälsotjänst (HealthService) är en programkomponent som finns med katalogtjänsten (CatalogService) och bakgrundsprocessorn (BackgroundProcessor) i beräkningsklustret. HealthService tillhandahåller ett REST-API för Azure Front Door för att anropa för att fastställa hälsotillståndet för en stämpel. HealthService är en komplex komponent som återspeglar beroendens tillstånd, förutom dess egna.

När beräkningsklustret är nere svarar inte hälsotjänsten. När tjänsterna är igång utför den regelbundna kontroller mot följande komponenter i infrastrukturen:

• Den försöker göra en fråga mot Azure Cosmos DB.

• Den försöker skicka ett meddelande till Event Hubs. Meddelandet filtreras bort av bakgrundsarbetaren.

• Den letar upp en tillståndsfil i lagringskontot. Den här filen kan användas för att inaktivera en region, även om de andra kontrollerna fortfarande fungerar korrekt. Den här filen kan användas för att kommunicera med andra processer. Om stämpeln till exempel ska tömmas i underhållssyfte kan filen tas bort för att tvinga fram ett feltillstånd och dirigera om trafiken.

• Den frågar hälsomodellen för att avgöra om alla driftsmått ligger inom de förutbestämda tröskelvärdena. När hälsomodellen anger att stämpeln inte är felfri ska trafiken inte dirigeras till stämpeln även om de andra testerna som HealthService utför returnerar korrekt. Hälsomodellen tar en mer fullständig vy över hälsostatusen i beräkningen.

Alla hälsokontrollresultat cachelagras i minnet under ett konfigurerbart antal sekunder, som standard 10. Den här åtgärden lägger potentiellt till en liten svarstid vid identifiering av avbrott, men det säkerställer att inte alla HealthService-frågor kräver serverdelsanrop, vilket minskar belastningen på klustret och underordnade tjänster.

Det här cachelagringsmönstret är viktigt eftersom antalet HealthService-frågor ökar avsevärt när du använder en global router som Azure Front Door: Varje gränsnod i varje Azure-datacenter som hanterar begäranden anropar Hälsotjänst för att avgöra om den har en funktionell serverdelsanslutning. Cachelagring av resultaten minskar extra klusterbelastning som genereras av hälsokontroller.

Konfiguration

HealthService och CatalogService har konfigurationsinställningar som är gemensamma mellan komponenterna, förutom följande inställningar som uteslutande används av HealthService:

Implementering

Alla kontroller utförs asynkront och parallellt. Om någon av dem misslyckas anses hela stämpeln vara otillgänglig.

Kontrollera att resultaten cachelagras i minnet med hjälp av standard, icke-distribuerad ASP.NET Core MemoryCache. Cache förfallotid styrs av SysConfig.HealthServiceCacheDurationSeconds och är inställd på 10 sekunder som standard.

Följande tabell beskriver hälsokontrollerna för komponenterna i infrastrukturen:

Azure Cosmos DB-frågor

För skrivskyddad fråga används följande fråga, som inte hämtar några data och inte har någon stor effekt på den totala belastningen:

SELECT GetCurrentDateTime ()

Skrivfrågan skapar en dummy ItemRating med minimalt innehåll:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Övervakning

Azure Log Analytics används som det centrala arkivet för loggar och mått för alla program- och infrastrukturkomponenter. Azure Application Insights används för alla programövervakningsdata. Varje stämpel i infrastrukturen har en dedikerad Log Analytics-arbetsyta och Application Insights-instans. En separat Log Analytics-arbetsyta används för globalt delade resurser som Front Door och Azure Cosmos DB.

Alla stämplar är kortlivade och ersätts kontinuerligt med varje ny version. Log Analytics-arbetsytorna per stämpel distribueras som en global resurs i en separat övervakningsresursgrupp som stämpel för Log Analytics-resurser. Dessa resurser delar inte livscykeln för en stämpel.

Mer information finns i Enhetlig datamottagare för korrelerad analys.

Övervakning: Datakällor

• Diagnostikinställningar: Alla Azure-tjänster som används för Azure Mission-Critical är konfigurerade för att skicka alla diagnostikdata, inklusive loggar och mått till den distributionsspecifika (globala eller stämpel) Log Analytics-arbetsytan. Den här processen sker automatiskt som en del av Terraform-distributionen. Nya alternativ identifieras automatiskt och läggs till som en del av terraform apply.

• Kubernetes-övervakning: Diagnostikinställningar används för att skicka Loggar och mått för Azure Kubernetes Service (AKS) till Log Analytics. AKS har konfigurerats för att använda Container Insights. Container Insights distribuerar OMSAgentForLinus via en Kubernetes DaemonSet på varje nod i AKS-klustren. OMSAgentForLinux kan samla in extra loggar och mått inifrån Kubernetes-klustret och skicka dem till motsvarande Log Analytics-arbetsyta. Dessa extra loggar och mått innehåller mer detaljerade data om poddar, distributioner, tjänster och övergripande klusterhälsa. Om du vill få mer insikter från de olika komponenterna, till exempel ingress-nginx, cert-manager och andra komponenter som distribuerats till Kubernetes bredvid den verksamhetskritiska arbetsbelastningen, är det möjligt att använda Prometheus-skrapning. Prometheus-skrapning konfigurerar OMSAgentForLinux för att skrapa Prometheus-mått från olika slutpunkter i klustret.

• Application Insights-telemetri: Application Insights används för att samla in telemetridata från programmet. Koden har instrumenterats för att samla in data om programmets prestanda med Application Insights SDK. Viktig information, till exempel den resulterande statuskoden och varaktigheten för beroendeanrop och räknare för ohanterade undantag samlas in. Den här informationen används i hälsomodellen och är tillgänglig för aviseringar och felsökning.

Övervakning: Application Insights-tillgänglighetstester

För att övervaka tillgängligheten för enskilda stämplar och den övergripande lösningen utifrån , konfigureras Application Insights-tillgänglighetstester på två platser:

• Regionala tillgänglighetstester: Dessa tester konfigureras i de regionala Application Insights-instanserna och används för att övervaka tillgängligheten för stämplarna. Dessa tester riktar sig direkt till klustren och statiska lagringskonton för stämplarna. Om du vill anropa ingresspunkterna i klustren direkt måste begäranden ha rätt Front Door-ID-huvud, annars avvisas de av ingresskontrollanten.

• Globalt tillgänglighetstest: Dessa tester konfigureras i den globala Application Insights-instansen och används för att övervaka tillgängligheten för den övergripande lösningen genom att pinga Front Door. Två tester används: Ett för att testa ett API-anrop mot CatalogService och ett för att testa webbplatsens startsida.

Övervakning: Frågor

Azure Mission-Critical använder olika KQL-frågor (Kusto-frågespråk) för att implementera anpassade frågor som funktioner för att hämta data från Log Analytics. Dessa frågor lagras som enskilda filer i vår kodlagringsplats, avgränsade för globala distributioner och stämpeldistributioner. De importeras och tillämpas automatiskt via Terraform som en del av varje infrastrukturpipelinekörning.

Den här metoden skiljer frågelogik från visualiseringsskiktet. Log Analytics-frågorna anropas direkt från kod, till exempel från HealthService-API:et. Ett annat exempel är från ett visualiseringsverktyg som Azure-instrumentpaneler, övervaka arbetsböcker eller Grafana.

Övervakning: Visualisering

För att visualisera resultatet av våra Log Analytics-hälsofrågor har vi använt Grafana i vår referensimplementering. Grafana används för att visa resultatet av Log Analytics-frågor och innehåller ingen logik i sig. Grafana-stacken är inte en del av lösningens distributionslivscykel, utan släpps separat.

Mer information finns i Visualisering.

Aviseringar

Aviseringar är en viktig del av den övergripande driftsstrategin. Proaktiv övervakning, till exempel användning av instrumentpaneler, bör användas med aviseringar som ger omedelbar uppmärksamhet åt problem.

Dessa aviseringar utgör ett tillägg till hälsomodellen genom att avisera operatorn om en ändring i hälsotillståndet, antingen till degraderat/gult tillstånd eller till felfritt/rött tillstånd. Genom att ställa in aviseringen på rotnoden i hälsomodellen är operatorn omedelbart medveten om alla affärsnivåer som påverkar lösningens tillstånd: Rotnoden blir trots allt gul eller röd om någon av de underliggande användarflödena eller resurserna rapporterar gula eller röda mått. Operatorn kan rikta sin uppmärksamhet mot visualiseringen Hälsomodell för felsökning.

Mer information finns i Automatiserad incidenthantering.

Felanalys

Att skapa felanalysen är främst en teoretisk planeringsövning. Den här teoretiska övningen ska användas som indata för automatiserade felinmatningar som ingår i den kontinuerliga valideringsprocessen. Genom att simulera de fellägen som definieras här kan vi verifiera lösningens återhämtning mot dessa fel för att säkerställa att de inte leder till avbrott.

I följande tabell visas exempel på felfall för de olika komponenterna i referensimplementeringen för Azure Mission-Critical.

Nästa steg

Distribuera referensimplementeringen för att få en fullständig förståelse för de resurser och deras konfiguration som används i den här arkitekturen.