Dela via

Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure

  • Artikel

Hälsomodellering och observerbarhet är viktiga begrepp för att maximera tillförlitligheten, som fokuserar på robust och kontextualiserad instrumentering och övervakning. De här begreppen ger viktig inblick i programmets hälsa och främjar snabb identifiering och lösning av problem.

De flesta verksamhetskritiska program är viktiga både vad gäller skala och komplexitet och genererar därför stora mängder driftdata, vilket gör det svårt att utvärdera och fastställa optimala operativa åtgärder. Hälsomodellering strävar i slutändan efter att maximera observerbarheten genom att utöka råa övervakningsloggar och mått med viktiga affärskrav för att kvantifiera programmets hälsa, vilket driver automatiserad utvärdering av hälsotillstånd för att uppnå konsekventa och snabba åtgärder.

Det här designområdet fokuserar på processen för att definiera en robust hälsomodell, mappa kvantifierade hälsotillstånd för program genom observerbarhet och driftskonstruktioner för att uppnå operativ mognad.

Viktigt

Den här artikeln är en del av azure Well-Architected verksamhetskritiska arbetsbelastningsserie . Om du inte är bekant med den här serien rekommenderar vi att du börjar med en verksamhetskritisk arbetsbelastning?

Det finns tre huvudsakliga nivåer av operativ mognad när du strävar efter att maximera tillförlitligheten.

  1. Identifiera och svara på problem när de inträffar.
  2. Diagnostisera problem som inträffar eller som redan har inträffat.
  3. Förutse och förhindra problem innan de inträffar.

Video: Definiera en hälsomodell för din verksamhetskritiska arbetsbelastning

Hälsotillstånd för skiktade program

Om du vill skapa en hälsomodell måste du först definiera programhälsa i samband med viktiga affärskrav genom att kvantifiera "felfria" och "inte felfria" tillstånd i ett lager och mätbart format. För varje programkomponent förfinar du sedan definitionen i kontexten för ett stabilt körningstillstånd och aggregeras enligt programmets användarflöden. Lägg till viktiga icke-funktionella affärskrav för prestanda och tillgänglighet. Slutligen aggregerar du hälsotillstånden för varje enskilt användarflöde för att bilda en acceptabel representation av det övergripande programmets hälsotillstånd. När dessa hälsodefinitioner i lager har upprättats bör de användas för att informera kritiska övervakningsmått för alla systemkomponenter och validera sammansättningen av det operativa undersystemet.

Viktigt

När du definierar vilka "ej felfria" tillstånd, representerar för alla nivåer i programmet. Det är viktigt att skilja mellan tillfälliga och icke-tillfälliga feltillstånd för att kvalificera tjänstförsämring i förhållande till otillgänglighet.

Designöverväganden

  • Processen för modelleringshälsa är en designaktivitet uppifrån och ned som börjar med en arkitekturövning för att definiera alla användarflöden och mappa beroenden mellan funktionella och logiska komponenter och därmed implicit mappa beroenden mellan Azure-resurser.

  • En hälsomodell är helt beroende av kontexten för den lösning som den representerar och kan därför inte lösas "out-of-the-box" eftersom "en storlek inte passar alla".

    • Programmen skiljer sig åt i sammansättning och beroenden
    • Mått och tröskelvärden för mått för resurser måste också finjusteras med avseende på vilka värden som representerar felfria och felaktiga tillstånd, som påverkas kraftigt av omfattande programfunktioner och mål för icke-funktionella krav.

  • En hälsomodell med flera lager gör att programhälsan kan spåras tillbaka till beroenden på lägre nivå, vilket hjälper till att snabbt orsaka försämring av tjänsten.

  • För att samla in hälsotillstånd för en enskild komponent måste komponentens distinkta driftegenskaper förstås under ett stabilt tillstånd som återspeglar produktionsbelastningen. Prestandatestning är därför en viktig funktion för att definiera och kontinuerligt utvärdera programmets hälsa.

  • Fel i en molnlösning kanske inte sker isolerat. Ett avbrott i en enda komponent kan leda till flera funktioner eller att ytterligare komponenter blir otillgängliga.

    • Sådana fel kanske inte kan observeras omedelbart.

Designrekommendationer

  • Definiera en mätbar hälsomodell som en prioritet för att säkerställa en tydlig operativ förståelse för hela programmet.

    • Hälsomodellen bör vara skiktad och återspegla programstrukturen.
    • Det grundläggande lagret bör ta hänsyn till enskilda programkomponenter, till exempel Azure-resurser.
    • Grundläggande komponenter bör aggregeras tillsammans med viktiga icke-funktionella krav för att skapa en affärskontextualiserad lins i hälsotillståndet för systemflöden.
    • Systemflöden bör aggregeras med lämpliga vikter baserat på affärskritiskhet för att skapa en meningsfull definition av övergripande programhälsa. Ekonomiskt viktiga användarflöden eller kundriktade användarflöden bör prioriteras.
    • Varje lager i hälsomodellen bör fånga upp vad "felfria" och "ohälsosamma" tillstånd representerar.
    • Se till att hälsomodellen kan skilja mellan tillfälliga och icke-tillfälliga feltillstånd för att isolera tjänstförsämring från otillgänglighet.

  • Representerar hälsotillstånd med hjälp av en detaljerad hälsopoäng för varje distinkt programkomponent och varje användarflöde genom att aggregera hälsopoäng för mappade beroende komponenter, med hänsyn till viktiga icke-funktionella krav som koefficienter.

    • Hälsopoängen för ett användarflöde ska representeras av den lägsta poängen för alla mappade komponenter, med hänsyn till relativ uppnåendet mot icke-funktionella krav för användarflödet.
    • Modellen som används för att beräkna hälsopoäng måste konsekvent återspegla driftshälsan, och om den inte gör det bör modellen justeras och distribueras om för att återspegla nya lärdomar.
    • Definiera tröskelvärden för hälsopoäng för att återspegla hälsostatus.

  • Hälsopoängen måste beräknas automatiskt baserat på underliggande mått, som kan visualiseras via observerbarhetsmönster och åtgärdas via automatiserade operativa procedurer.

    • Hälsopoängen bör bli kärnan i övervakningslösningen, så att driftsteamen inte längre behöver tolka och mappa driftdata till programmets hälsa.

  • Använd hälsomodellen för att beräkna tillgängligheten för servicenivåmål (SLO) i stället för rå tillgänglighet, vilket säkerställer att avgränsningen mellan tjänstförsämring och otillgänglighet återspeglas som separata servicenivåmål.

  • Använd hälsomodellen i CI/CD-pipelines och testcykler för att verifiera att programmets hälsa upprätthålls efter kod- och konfigurationsuppdateringar.

    • Hälsomodellen bör användas för att observera och verifiera hälsa under belastningstestning och kaostestning som en del av CI/CD-processer.

  • Att skapa och underhålla en hälsomodell är en iterativ process och tekniska investeringar bör anpassas för att driva på kontinuerliga förbättringar.

    • Definiera en process för att kontinuerligt utvärdera och finjustera modellens noggrannhet och överväg att investera i maskininlärningsmodeller för att ytterligare träna modellen.

Exempel – Layered Health-modell

Det här är en förenklad representation av en hälsomodell med flera lager för program i illustrerande syfte. En omfattande och kontextualiserad hälsomodell finns i Mission-Critical referensimplementeringar:

När du implementerar en hälsomodell är det viktigt att definiera hälsotillståndet för enskilda komponenter genom aggregering och tolkning av viktiga mått på resursnivå. Ett exempel på hur resursmått kan användas är bilden nedan:

Verksamhetskritiska exempel på hälsodefinitioner

Den här definitionen av hälsa kan därefter representeras av en KQL-fråga, vilket visas av exempelfrågan nedan som aggregerar InsightsMetrics (Container insights) och AzureMetrics (diagnostikinställning för AKS-kluster) och jämför (inre koppling) med modellerade hälsotrösklar.

// 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

De resulterande tabellutdata kan därefter omvandlas till en hälsopoäng för enklare aggregering på högre nivåer i hälsomodellen.

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

Dessa aggregerade poäng kan därefter representeras som ett beroendediagram med hjälp av visualiseringsverktyg som Grafana för att illustrera hälsomodellen.

Den här bilden visar ett exempel på en hälsomodell med flera lager från Azure Mission-Critical onlinereferensimplementering och visar hur en ändring i hälsotillståndet för en grundläggande komponent kan ha en sammanhängande inverkan på användarflöden och övergripande programhälsa (exempelvärdena motsvarar tabellen i föregående bild).

Verksamhetskritiskt exempel på hälsomodellvisualisering

Demovideo: Demonstration av övervakning och hälsomodellering

Enhetlig datamottagare för korrelerad analys

Många driftdatauppsättningar måste samlas in från alla systemkomponenter för att korrekt representera en definierad hälsomodell, med tanke på loggar och mått från både programkomponenter och underliggande Azure-resurser. Den här stora mängden data måste i slutändan lagras i ett format som möjliggör tolkning i nästan realtid för att underlätta snabba operativa åtgärder. Dessutom krävs korrelation mellan alla datauppsättningar som omfattas för att säkerställa att effektiv analys är obundna, vilket möjliggör en skiktad representation av hälsa.

En enhetlig datamottagare krävs för att säkerställa att alla driftdata snabbt lagras och görs tillgängliga för korrelerad analys för att skapa en "enskild fönsterruta"-representation av programmets hälsa. Azure tillhandahåller flera olika drifttekniker inom ramen för Azure Monitor, och Log Analytics-arbetsytan fungerar som den centrala Azure-interna datamottagaren för att lagra och analysera driftdata.

Mission Critical Health Data Collection

Designöverväganden

Azure Monitor

  • Azure Monitor är aktiverat som standard för alla Azure-prenumerationer, men Azure Monitor-loggar (Log Analytics-arbetsyta) och Application Insights-resurser måste distribueras och konfigureras för att införliva datainsamlings- och frågefunktioner.

  • Azure Monitor stöder tre typer av observerbarhetsdata: loggar, mått och distribuerade spårningar.

    • Loggar lagras på Log Analytics-arbetsytor, som baseras på Azure Data Explorer. Loggfrågor lagras i frågepaket som kan delas mellan prenumerationer och används för att driva observerbarhetskomponenter som instrumentpaneler, arbetsböcker eller andra verktyg för rapportering och visualisering.
    • Mått lagras i en intern tidsseriedatabas. För de flesta Azure-resurser samlas mått automatiskt in och behålls i 93 dagar. Måttdata kan också skickas till Log Analytics-arbetsytan med hjälp av en diagnostikinställning för resursen.

  • Alla Azure-resurser exponerar loggar och mått, men resurserna måste vara korrekt konfigurerade för att dirigera diagnostikdata till önskad datamottagare.

Tips

Azure tillhandahåller olika inbyggda principer som kan tillämpas för att säkerställa att distribuerade resurser är konfigurerade för att skicka loggar och mått till en Log Analytics-arbetsyta.

  • Det är inte ovanligt att regleringskontroller kräver att driftdata förblir inom ursprungsområden eller länder/regioner. Regelkrav kan föreskriva kvarhållning av kritiska datatyper under en längre tid. Inom reglerade banktjänster måste till exempel granskningsdata bevaras i minst sju år.

  • Olika typer av driftdata kan kräva olika kvarhållningsperioder. Säkerhetsloggar kan till exempel behöva behållas under en lång period, medan prestandadata sannolikt inte kommer att kräva långsiktig kvarhållning utanför AIOps-kontexten.

  • Data kan arkiveras eller exporteras från Log Analytics-arbetsytor för långsiktig kvarhållning och/eller granskning.

  • Dedikerade kluster tillhandahåller ett distributionsalternativ som gör det möjligt att Tillgänglighetszoner för skydd mot zonindelade fel i Azure-regioner som stöds. Dedikerade kluster kräver ett minsta åtagande för daglig datamatning.

  • Log Analytics-arbetsytor distribueras till en angiven Azure-region.

  • För att skydda mot dataförlust från otillgänglighet för en Log Analytics-arbetsyta kan resurser konfigureras med flera diagnostikinställningar. Varje diagnostikinställning kan skicka mått och loggar till en separat Log Analytics-arbetsyta.

    • Data som skickas till varje ytterligare Log Analytics-arbetsyta medför extra kostnader.
    • Den redundanta Log Analytics-arbetsytan kan distribueras till samma Azure-region eller i separata Azure-regioner för ytterligare regional redundans.
    • Att skicka loggar och mått från en Azure-resurs till en Log Analytics-arbetsyta i en annan region medför utgående kostnader för datautgående mellan regioner.
    • Vissa Azure-resurser kräver en Log Analytics-arbetsyta i samma region som själva resursen.
    • Se Metodtips för Azure Monitor-loggar för ytterligare tillgänglighetsalternativ för Log Analytics-arbetsytan.

  • Log Analytics-arbetsytedata kan exporteras till Azure Storage eller Azure Event Hubs på kontinuerlig, schemalagd eller engångsbasis.

    • Dataexport möjliggör långsiktig dataarkivering och skyddar mot eventuell förlust av driftdata på grund av otillgänglighet.
    • Tillgängliga exportmål är Azure Storage eller Azure Event Hubs. Azure Storage kan konfigureras för olika redundansnivåer , inklusive zonindelade eller regionala. Dataexport till Azure Storage lagrar data i .json-filer.
    • Dataexportmål måste finnas i samma Azure-region som Log Analytics-arbetsytan. Ett händelsehubbdataexportmål som ska finnas i samma region som Log Analytics-arbetsytan. Azure Event Hubs geo-haveriberedskap gäller inte för det här scenariot.
    • Det finns flera begränsningar för dataexport. Endast specifika tabeller på arbetsytan stöds för dataexport.
    • Arkivering kan användas för att lagra data på en Log Analytics-arbetsyta för långsiktig kvarhållning till en lägre kostnad utan att exportera dem.

  • Azure Monitor-loggar har begränsningar för användarfrågor, vilket kan se ut som minskad tillgänglighet för klienter, till exempel instrumentpaneler för observerbarhet.

    • Fem samtidiga frågor per användare: om fem frågor redan körs placeras ytterligare frågor i en samtidighetskö per användare tills en löpande fråga avslutas.
    • Tid i samtidighetskö: om en fråga finns i samtidighetskö i över tre minuter avslutas den och en 429-felkod returneras.
    • Ködjupsgräns för samtidighet: samtidighetskön är begränsad till 200 frågor och ytterligare frågor avvisas med en 429-felkod.
    • Frågefrekvensgräns: det finns en gräns per användare på 200 frågor per 30 sekunder på alla arbetsytor.

  • Frågepaket är Azure Resource Manager resurser som kan användas för att skydda och återställa loggfrågor om Log Analytics-arbetsytan inte är tillgänglig.

    • Frågepaket innehåller frågor som JSON och kan lagras utanför Azure på liknande sätt som andra infrastruktur-som-kod-tillgångar.
      • Kan distribueras via Rest-API:et för Microsoft.Insights.
      • Om en Log Analytics-arbetsyta måste återskapas kan frågepaketet distribueras om från en externt lagrad definition.

  • Application Insights kan distribueras i en arbetsytebaserad distributionsmodell, underbyggd av en Log Analytics-arbetsyta där alla data lagras.

  • Sampling kan aktiveras i Application Insights för att minska mängden telemetri som skickas och optimera datainmatningskostnader.

  • Alla data som samlas in av Azure Monitor, inklusive Application Insights, debiteras baserat på mängden data som matas in och hur länge data behålls.

    • Data som matas in i en Log Analytics-arbetsyta kan behållas utan extra kostnad upp till de första 31 dagarna (90 dagar om Sentinel är aktiverat)
    • Data som matas in i en arbetsytebaserad Application Insights behålls under de första 90 dagarna utan extra kostnad.

  • Prismodellen för Log Analytics-åtagandenivå ger en lägre kostnad och en förutsägbar metod för datainmatningsavgifter.

    • All användning över reservationsnivån debiteras till samma pris som den aktuella nivån.

  • Log Analytics, Application Insights och Azure Data Explorer använda Kusto-frågespråk (KQL).

  • Log Analytics-frågor sparas som funktioner på Log Analytics-arbetsytan (savedSearches).

Designrekommendationer

  • Använd Log Analytics-arbetsytan som en enhetlig datamottagare för att tillhandahålla ett "enda fönster" för alla driftdatauppsättningar.

    • Decentralisera Log Analytics-arbetsytor i alla använda distributionsregioner. Varje Azure-region med en programdistribution bör överväga en Log Analytics-arbetsyta för att samla in alla driftdata som kommer från den regionen. Alla globala resurser bör använda en separat dedikerad Log Analytics-arbetsyta som ska distribueras i en primär distributionsregion.
      • Om du skickar alla driftdata till en enda Log Analytics-arbetsyta skapas en felpunkt.
      • Krav för datahemvist kan förhindra att data lämnar den ursprungliga regionen, och federerade arbetsytor löser detta krav som standard.
      • Det finns en betydande utgående kostnad som är associerad med överföring av loggar och mått mellan regioner.
    • Alla distributionsstämplar i samma region kan använda samma regionala Log Analytics-arbetsyta.

  • Överväg att konfigurera resurser med flera diagnostikinställningar som pekar på olika Log Analytics-arbetsytor för att skydda mot att Azure Monitor inte är tillgängligt för program med färre regionala distributionsstämplar.

  • Använd Application Insights som ett konsekvent APM-verktyg (Application Performance Monitoring) för alla programkomponenter för att samla in programloggar, mått och spårningar.

    • Distribuera Application Insights i en arbetsytebaserad konfiguration för att säkerställa att varje regional Log Analytics-arbetsyta innehåller loggar och mått från både programkomponenter och underliggande Azure-resurser.

  • Använd frågor mellan arbetsytor för att upprätthålla ett enhetligt "enskilt fönster" på de olika arbetsytorna.

  • Använd frågepaket för att skydda loggfrågor om arbetsytan inte är tillgänglig.

    • Lagra frågepaket på git-lagringsplatsen för programmet som infrastruktur-som-kod-tillgångar.

  • Alla Log Analytics-arbetsytor ska behandlas som långvariga resurser med en annan livscykel än programresurser inom en regional distributionsstämpel.

  • Exportera kritiska driftdata från Log Analytics-arbetsytan för långsiktig kvarhållning och analys för att underlätta AIOps och avancerad analys för att förfina den underliggande hälsomodellen och informera om förutsägelseåtgärder.

  • Utvärdera noggrant vilket datalager som ska användas för långsiktig kvarhållning. alla data måste inte lagras i ett frekvent och frågebart datalager.

    • Vi rekommenderar starkt att du använder Azure Storage i en GRS-konfiguration för långsiktig datalagring.
      • Använd exportfunktionen för Log Analytics-arbetsytan för att exportera alla tillgängliga datakällor till Azure Storage.

  • Välj lämpliga kvarhållningsperioder för driftdatatyper i Log Analytics, konfigurera längre kvarhållningsperioder på arbetsytan där det finns "frekventa" observerbarhetskrav.

  • Använd Azure Policy för att säkerställa att alla regionala resurser dirigerar driftdata till rätt Log Analytics-arbetsyta.

Anteckning

När du distribuerar till en Azure-landningszon, om det finns ett krav på centraliserad lagring av driftdata, kan du förgrena data vid instansiering så att de matas in i både centraliserade verktyg och Log Analytics-arbetsytor som är dedikerade till programmet. Du kan också exponera åtkomst till log analytics-arbetsytor för program så att centrala team kan fråga programdata. Det är ytterst viktigt att driftdata från lösningen är tillgängliga i Log Analytics-arbetsytor som är dedikerade till programmet.

Om SIEM-integrering krävs ska du inte skicka råloggposter, utan i stället skicka kritiska aviseringar.

  • Konfigurera endast sampling i Application Insights om det krävs för att optimera prestanda, eller om inte sampling blir kostnadsöverkomligt.

    • Överdriven sampling kan leda till missade eller felaktiga driftsignaler.

  • Använd korrelations-ID:t för alla spårningshändelser och loggmeddelanden för att koppla dem till en viss begäran.

    • Returnera korrelations-ID:t till anroparen för alla anrop, inte bara misslyckade begäranden.

  • Se till att programkoden innehåller rätt instrumentation och loggning för att informera hälsomodellen och underlätta efterföljande felsökning eller rotorsaksanalys vid behov.

    • Programkoden bör använda Application Insights för att underlätta distribuerad spårning genom att ge anroparen ett omfattande felmeddelande som innehåller ett korrelations-ID när ett fel inträffar.

  • Använd strukturerad loggning för alla loggmeddelanden.

  • Lägg till meningsfulla hälsoavsökningar till alla programkomponenter.

    • När du använder AKS konfigurerar du hälsoslutpunkterna för varje distribution (podd) så att Kubernetes korrekt kan avgöra när en podd är felfri eller inte felfri.
    • När du använder Azure App Service konfigurerar du hälsokontrollerna så att utskalningsåtgärder inte orsakar fel genom att skicka trafik till instanser som ännu inte är klara och se till att felaktiga instanser återanvänds snabbt.

Om programmet prenumererar på Microsoft Mission-Critical Support bör du överväga att exponera viktiga hälsoavsökningar för Microsoft Support, så att programmets hälsa kan modelleras mer korrekt av Microsoft Support.

  • Logga lyckade hälsokontrollbegäranden, såvida inte ökade datavolymer inte kan tolereras i samband med programprestanda, eftersom de ger ytterligare insikter för analysmodellering.

  • Konfigurera inte log analytics-arbetsytor för produktion för att tillämpa ett dagligt tak, vilket begränsar den dagliga inmatningen av driftdata, eftersom detta kan leda till förlust av kritiska driftdata.

    • I lägre miljöer, till exempel Utveckling och test, kan ett dagligt tak betraktas som en valfri mekanism för kostnadsbesparing.

  • Tillhandahållna volymer för inmatning av driftdata uppfyller tröskelvärdet för miniminivån och konfigurerar Log Analytics-arbetsytor att använda priser på åtagandenivå för att öka kostnadseffektiviteten i förhållande till prismodellen "betala per användning".

  • Vi rekommenderar starkt att du lagrar Log Analytics-frågor med källkontroll och använder CI/CD-automatisering för att distribuera dem till relevanta Log Analytics-arbetsyteinstanser.

Visualisering

Det är viktigt att visuellt representera hälsomodellen med kritiska driftdata för att uppnå effektiva åtgärder och maximera tillförlitligheten. Instrumentpaneler bör i slutändan användas för att ge insikter i nästan realtid om programhälsa för DevOps-team, vilket underlättar en snabb diagnos av avvikelser från stabilt tillstånd.

Microsoft tillhandahåller flera datavisualiseringstekniker, inklusive Azure-instrumentpaneler, Power BI och Azure Managed Grafana (för närvarande i förhandsversion). Azure-instrumentpaneler är placerade för att tillhandahålla en nära integrerad lösning för visualisering för driftdata i Azure Monitor. Det har därför en grundläggande roll att spela i den visuella representationen av driftdata och programhälsa för en verksamhetskritisk arbetsbelastning. Det finns dock flera begränsningar när det gäller positionering av Azure-instrumentpaneler som en holistisk observerbarhetsplattform, och därför bör hänsyn tas till den kompletterande användningen av marknadsledande observerbarhetslösningar, till exempel Grafana, som också tillhandahålls som en hanterad lösning i Azure.

Det här avsnittet fokuserar på användningen av Azure-instrumentpaneler och Grafana för att skapa en robust instrumentpanelsupplevelse som kan ge tekniska och affärslinser till programhälsa, vilket möjliggör DevOps-team och effektiv drift. Robust instrumentpanelshantering är viktigt för att diagnostisera problem som redan har inträffat och stödja operativa team när det gäller att identifiera och svara på problem när de inträffar.

Designöverväganden

  • När du visualiserar hälsomodellen med hjälp av loggfrågor bör du tänka på att det finns Log Analytics-gränser för samtidiga och köade frågor, samt den övergripande frågefrekvensen, med efterföljande frågor i kö och begränsade.

  • Frågor för att hämta driftdata som används för att beräkna och representera hälsopoäng kan skrivas och köras i Log Analytics eller Azure Data Explorer.

    • Exempelfrågor finns här.

  • Log Analytics har flera frågegränser som måste utformas för när du utformar driftsinstrumentpaneler.

  • Visualiseringen av råa resursmått, till exempel CPU-användning eller nätverksdataflöde, kräver manuell utvärdering av driftsteam för att fastställa hälsostatuspåverkan, och detta kan vara en utmaning under en aktiv incident.

  • Om flera användare använder instrumentpaneler i ett verktyg som Grafana multipliceras antalet frågor som skickas till Log Analytics snabbt.

    • Om du når gränsen för samtidiga frågor i Log Analytics placeras efterföljande frågor i kö, vilket gör att instrumentpanelsupplevelsen känns "långsam".

Designrekommendationer

  • Samla in och presentera efterfrågade utdata från alla regionala Log Analytics-arbetsytor och den globala Log Analytics-arbetsytan för att skapa en enhetlig vy över programmets hälsa.

Anteckning

Om du distribuerar till en Azure-landningszon bör du överväga att fråga den centrala plattformen Log Analytics-arbetsytan om det finns viktiga beroenden för plattformsresurser, till exempel ExpressRoute för lokal kommunikation.

  • En "trafikljusmodell" ska användas för att visuellt representera "felfria" och "ohälsosamma" tillstånd, med grönt som används för att illustrera när viktiga icke-funktionella krav är helt uppfyllda och resurser utnyttjas optimalt. Använd "Green", "Amber och "Red" för att representera tillstånden "Felfri", "Degraderad" och "Ej tillgänglig".

  • Använd Azure-instrumentpaneler för att skapa driftlinser för globala resurser och regionala distributionsstämplar, som representerar viktiga mått, till exempel antal förfrågningar för Azure Front Door, svarstid på serversidan för Azure Cosmos DB, inkommande/utgående meddelanden för Event Hubs och cpu-användning eller distributionsstatus för AKS. Instrumentpaneler bör skräddarsys för att öka driftseffektiviteten och ge lärdomar från felscenarier för att säkerställa att DevOps-teamen har direkt insyn i viktiga mått.

  • Om Azure-instrumentpaneler inte kan användas för att korrekt representera hälsomodellen och nödvändiga affärskrav rekommenderar vi starkt att grafana betraktas som en alternativ visualiseringslösning som ger marknadsledande funktioner och ett omfattande ekosystem med plugin-program med öppen källkod. Utvärdera det hanterade Grafana-förhandsversionserbjudandet för att undvika driftskomplexiteterna i hanteringen av Grafana-infrastrukturen.

  • När du distribuerar grafana med egen värd använder du en geo-distribuerad design med hög tillgänglighet för att säkerställa att kritiska operativa instrumentpaneler kan vara motståndskraftiga mot regionala plattformsfel och sammanhängande felscenarier.

    • Separera konfigurationstillståndet i ett externt datalager, till exempel Azure Database for Postgres eller MySQL, för att säkerställa att Grafana-programnoderna förblir tillståndslösa.

      • Konfigurera databasreplikering mellan distributionsregioner.

    • Distribuera Grafana-noder till App Services i en konfiguration med hög tillgänglighet i en region med hjälp av containerbaserade distributioner.

      • Distribuera App Service instanser över övervägd distributionsregion.

      App Services tillhandahåller en containerplattform med låg friktion, som är idealisk för scenarier i låg skala, till exempel driftsinstrumentpaneler, och isolering av Grafana från AKS ger en tydlig separation av oro mellan den primära programplattformen och driftsrepresentationer för den plattformen. Se området för programplattformsjustering för ytterligare konfigurationsrekommendationer.

    • Använd Azure Storage i en GRS-konfiguration för att vara värd för och hantera anpassade visuella objekt och plugin-program.

    • Distribuera Grafana-komponenter för App Service och databasläsningsreplik till minst två distributionsregioner och överväg att använda en modell där Grafana distribueras till alla övervägda distributionsregioner.

För scenarier som är inriktade på ett >= 99,99 % SLO bör Grafana distribueras inom minst 3 distributionsregioner för att maximera den övergripande tillförlitligheten för viktiga operativa instrumentpaneler.

  • Minimera Log Analytics-frågegränser genom att aggregera frågor till ett enskilt eller litet antal frågor, till exempel genom att använda KQL-operatorn union och ange en lämplig uppdateringsfrekvens på instrumentpanelen.

    • En lämplig maximal uppdateringshastighet beror på antalet och komplexiteten i instrumentpanelsfrågor. analys av implementerade frågor krävs.

  • Om den samtidiga frågegränsen för Log Analytics nås bör du överväga att optimera hämtningsmönstret genom att (tillfälligt) lagra de data som krävs för instrumentpanelen i ett datalager med höga prestanda, till exempel Azure SQL.

Automatiserad incidenthantering

Även om de visuella representationerna av programhälsa ger ovärderliga drifts- och affärsinsikter för att stödja identifiering och diagnos av problem, förlitar den sig på beredskapen och tolkningarna av operativa team, samt effektiviteten av efterföljande mänskligt utlösta svar. För att maximera tillförlitligheten är det därför nödvändigt att implementera omfattande aviseringar för att identifiera proaktivt och svara på problem i nära realtid.

Azure Monitor tillhandahåller ett omfattande aviseringsramverk för att identifiera, kategorisera och svara på operativa signaler via åtgärdsgrupper. Det här avsnittet fokuserar därför på användningen av Azure Monitor-aviseringar för att köra automatiserade åtgärder som svar på aktuella eller potentiella avvikelser från ett felfritt programtillstånd.

Viktigt

Aviseringar och automatiserade åtgärder är avgörande för att effektivt identifiera och snabbt svara på problem när de inträffar, innan större negativ påverkan kan uppstå. Aviseringar ger också en mekanism för att tolka inkommande signaler och svara för att förhindra problem innan de inträffar.

Designöverväganden

  • Aviseringsregler definieras för att utlösas när ett villkor uppfylls för inkommande signaler, som kan innehålla olika datakällor, till exempel mått, loggfrågor eller tillgänglighetstester.

  • Aviseringar kan definieras i Log Analytics eller Azure Monitor för den specifika resursen.

  • Vissa mått kan bara undersökas i Azure Monitor eftersom inte alla diagnostikdatapunkter görs tillgängliga i Log Analytics.

  • Azure Monitor-aviserings-API:et kan användas för att hämta aktiva och historiska aviseringar.

  • Det finns prenumerationsgränser relaterade till aviseringar och åtgärdsgrupper, som måste utformas för:

    • Det finns gränser för antalet konfigurerbara aviseringsregler.
    • Aviserings-API:et har begränsningar som bör övervägas för scenarier med extrem användning.
    • Åtgärdsgrupper har flera hårda gränser för antalet konfigurerbara svar, som måste utformas för.
      • Varje svarstyp har en gräns på 10 åtgärder, förutom e-post, som har en gräns på 1 000 åtgärder.

  • Aviseringar kan integreras i en hälsomodell med flera lager genom att skapa en aviseringsregel för en sparad loggsökningsfråga från modellens "rot"-bedömningsfunktion. Du kan till exempel använda "WebsiteHealthScore" och aviseringar för ett numeriskt värde som representerar tillståndet "Inte felfri".

Designrekommendationer

  • För resurscentrerad aviseringar skapar du aviseringsregler i Azure Monitor för att säkerställa att alla diagnostikdata är tillgängliga för kriterierna för aviseringsregler.

  • Konsolidera automatiserade åtgärder inom ett minimalt antal åtgärdsgrupper, i linje med tjänstteamen för att stödja en DevOps-metod.

  • Svara på signaler om överdriven resursanvändning via automatiserade skalningsåtgärder med hjälp av Azure-inbyggda funktioner för automatisk skalning där det är möjligt. Om inbyggda funktioner för automatisk skalning inte är tillämpliga använder du komponentens hälsopoäng för att modellera signaler och bestämma när du ska svara med automatiserade skalningsåtgärder. Se till att automatiserade skalningsåtgärder definieras enligt en kapacitetsmodell, som kvantifierar skalningsrelationer mellan komponenter, så att skalningssvar omfattar komponenter som behöver skalas i förhållande till andra komponenter.

  • Modellåtgärder för att hantera en prioriterad ordning, som bör bestämmas av inverkan på verksamheten.

  • Använd API:et för Azure Monitor-aviseringar för att samla in historiska aviseringar som ska införlivas i "kall" driftslagring för avancerad analys.

  • För scenarier med kritiska fel, som inte kan uppfyllas med ett automatiserat svar, ser du till att den operativa "Runbook Automation" är på plats för att driva snabb och konsekvent åtgärd när manuell tolkning och utloggning har tillhandahållits. Använda aviseringsmeddelanden för att snabbt identifiera problem som kräver manuell tolkning

  • Skapa kvoter i tekniska sprintar för att driva inkrementella förbättringar i aviseringar för att säkerställa att nya felscenarier som inte tidigare har övervägts kan anpassas helt inom nya automatiserade åtgärder.

  • Utför tester av driftberedskap som en del av CI/CD-processer för att verifiera viktiga aviseringsregler för distributionsuppdateringar.

Förutsägande åtgärder och AI-åtgärder (AIOps)

Maskininlärningsmodeller kan användas för att korrelera och prioritera driftdata, vilket hjälper till att samla in viktiga insikter som rör filtrering av överdrivet aviseringsbrus och förutsäga problem innan de orsakar påverkan, samt för att påskynda incidenthantering när de gör det.

Mer specifikt kan en AIOps-metod användas för kritiska insikter om systemets, användarnas och DevOps-processernas beteende. Dessa insikter kan omfatta att identifiera ett problem som inträffar nu (identifiera), kvantifiera varför problemet uppstår (diagnostisera) eller signalera vad som kommer att hända i framtiden (förutsäga). Sådana insikter kan användas för att driva åtgärder som justerar och optimerar programmet för att minimera aktiva eller potentiella problem, med hjälp av viktiga affärsmått, systemkvalitetsmått och DevOps-produktivitetsmått för att prioritera baserat på affärspåverkan. Utförda åtgärder kan själva integreras i systemet genom en feedbackloop som ytterligare tränar den underliggande modellen för att öka effektiviteten.

Verksamhetskritisk AIOps-metoder Verksamhetskritisk

Det finns flera analystekniker i Azure, till exempel Azure Synapse och Azure Databricks, som kan användas för att skapa och träna analysmodeller för AIOps. Det här avsnittet fokuserar därför på hur dessa tekniker kan placeras i en programdesign för att hantera AIOps och främja förutsägelseåtgärder, med fokus på Azure Synapse som minskar friktionen genom att sammanföra det bästa av Azures datatjänster tillsammans med kraftfulla nya funktioner.

AIOps används för att främja förutsägande åtgärder, tolka och korrelera komplexa operativa signaler som observerats under en längre period för att bättre svara på och förhindra problem innan de inträffar.

Designöverväganden

  • Azure Synapse Analytics erbjuder flera maskininlärningsfunktioner (ML).

    • ML-modeller kan tränas och köras på Synapse Spark-pooler med bibliotek som MLLib, SparkML och MMLSpark samt populära bibliotek med öppen källkod, till exempel Scikit Learn.
    • ML-modeller kan tränas med vanliga datavetenskapsverktyg som PySpark/Python, Scala eller .NET.

  • Synapse Analytics är integrerat med Azure ML via Azure Synapse Notebooks, vilket gör att ML-modeller kan tränas i en Azure ML-arbetsyta med hjälp av automatiserad ML.

  • Synapse Analytics gör det också möjligt för ML-funktioner som använder Azure Cognitive Services att lösa allmänna problem i olika domäner, till exempel avvikelseidentifiering. Cognitive Services kan användas i Azure Synapse, Azure Databricks och via SDK:er och REST-API:er i klientprogram.

  • Azure Synapse integreras internt med Azure Data Factory verktyg för att extrahera, transformera och läsa in (ETL) eller mata in data i orkestreringspipelines.

  • Azure Synapse aktiverar registrering av externa datauppsättningar till data som lagras i Azure Blob Storage eller Azure Data Lake Storage.

    • Registrerade datauppsättningar kan användas i Dataanalysuppgifter för Synapse Spark-pool.

  • Azure Databricks kan integreras i Azure Synapse Analytics-pipelines för ytterligare Spark-funktioner.

    • Synapse orkestrerar läsning av data och skickar dem till ett Databricks-kluster, där de kan transformeras och förberedas för ML-modellträning.

  • Källdata måste vanligtvis förberedas för analys och ML.

    • Synapse erbjuder olika verktyg för att hjälpa till med förberedelse av data, inklusive Apache Spark, Synapse Notebooks och serverlösa SQL-pooler med T-SQL och inbyggda visualiseringar.

  • ML-modeller som har tränats, operationaliserats och distribuerats kan användas för batchbedömning i Synapse.

    • AIOps-scenarier, till exempel körning av regression eller försämringsförutsägelser i CI/ CD-pipelined , kan kräva bedömning i realtid.

  • Det finns prenumerationsgränser för Azure Synapse, vilket bör förstås fullt ut i samband med en AIOps-metodik.

  • För att helt införliva AIOps är det nödvändigt att kontinuerligt mata in observerbarhetsdata i realtid i ML-inferensmodeller i realtid.

    • Funktioner som avvikelseidentifiering bör utvärderas i dataströmmen för observerbarhet.

Designrekommendationer

  • Se till att alla Azure-resurser och programkomponenter är helt instrumenterade så att en fullständig driftdatauppsättning är tillgänglig för AIOps-modellträning.

  • Mata in Log Analytics-driftdata från de globala och regionala Azure Storage-kontona i Azure Synapse för analys.

  • Använd API:et för Azure Monitor-aviseringar för att hämta historiska aviseringar och lagra dem i kall lagring för driftdata som sedan kan användas i ML-modeller. Om Log Analytics-dataexport används lagrar du historiska aviseringsdata på samma Azure Storage-konton som exporterade Log Analytics-data.

  • När inmatade data har förberetts för ML-träning skriver du tillbaka dem till Azure Storage så att de är tillgängliga för ML-modellträning utan att synapse-dataförberedelseberäkningsresurser krävs för att köras.

  • Se till att ML-modellens driftsättning stöder både batch- och realtidsbedömning.

  • När AIOps-modeller skapas implementerar du MLOps och tillämpar DevOps-metoder för att automatisera ML-livscykeln för träning, driftsättning, bedömning och kontinuerlig förbättring. Skapa en iterativ CI/CD-process för AIOps ML-modeller.

  • Utvärdera Azure Cognitive Services för specifika förutsägelsescenarier på grund av deras låga administrations- och integreringskostnader. Överväg avvikelseidentifiering för att snabbt flagga oväntade avvikelser i observerbarhetsdataströmmar.

Nästa steg

Granska överväganden för distribution och testning.

Distribution och testning