Rekommendationer för att utforma och skapa ett övervakningssystem

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

Relaterad guide: Rekommendationer för instrumentering av ett program

Den här guiden beskriver rekommendationerna för att utforma och skapa ett övervakningssystem. För att effektivt övervaka din arbetsbelastning för säkerhet, prestanda och tillförlitlighet behöver du ett omfattande system med en egen stack som utgör grunden för alla övervaknings-, identifierings- och aviseringsfunktioner.

Definitioner

Viktiga designstrategier

Följ dessa grundläggande grundsatser för att implementera en omfattande systemdesign för övervakningssystemet för din arbetsbelastning:

• När det är praktiskt kan du dra nytta av övervakningsverktyg som tillhandahålls av plattformen, vilket vanligtvis kräver mycket lite konfiguration och kan ge djupa insikter om din arbetsbelastning som annars kan vara svår att utföra.

• Samla in loggar och mått från hela arbetsbelastningsstacken. Alla infrastrukturresurser och programfunktioner ska konfigureras för att producera standardiserade, meningsfulla data och att data måste samlas in.

• Lagra insamlade data i en standardiserad, tillförlitlig och säker lagringslösning.

• Bearbeta lagrade data så att de kan hanteras av analys- och visualiseringslösningar.

• Analysera bearbetade data för att korrekt fastställa arbetsbelastningens tillstånd.

• Visualisera arbetsbelastningens tillstånd i meningsfulla instrumentpaneler eller rapporter för arbetsbelastningsteam och andra intressenter.

• Konfigurera åtgärdsbara aviseringar och andra automatiska svar på intelligent definierade tröskelvärden för att meddela arbetsbelastningsteam när problem uppstår.

• Inkludera övervaknings- och aviseringssystem i dina övergripande testmetoder för arbetsbelastningar.

• Se till att övervaknings- och aviseringssystem finns i omfånget för kontinuerlig förbättring. Program- och infrastrukturbeteende i produktion ger kontinuerliga inlärningsmöjligheter. Införliva dessa lektioner i övervaknings- och aviseringsdesign.

• Koppla de övervakningsdata som du samlar in och analyserar tillbaka till systemet och användarflödena för att korrelera hälsotillståndet för flödena med data utöver arbetsbelastningens övergripande hälsa. Genom att analysera dessa data när det gäller flödena kan du anpassa din observerbarhetsstrategi till din hälsomodell.

Du bör automatisera alla funktioner i övervakningssystemet så mycket som möjligt, och alla bör köras kontinuerligt, hela dagen, varje dag.

Den här arbetsflödespipelinen illustrerar övervakningssystemet:

Samla in instrumentationsdata

Du bör konfigurera alla arbetsbelastningskomponenter, oavsett om de är infrastrukturresurser eller programfunktioner, för att samla in telemetri och/eller händelser som loggar och mått.

Loggar är främst användbara för att identifiera och undersöka avvikelser. Vanligtvis skapas loggar av arbetsbelastningskomponenten och skickas sedan till övervakningsplattformen eller hämtas av övervakningsplattformen via automatisering.

Mått är främst användbara för att skapa en hälsomodell och identifiera trender i arbetsbelastningens prestanda och tillförlitlighet. Mått är också användbara för att identifiera trender i dina kunders användningsbeteende. Dessa trender kan hjälpa dig att vägleda beslut om förbättringar ur kundens perspektiv. Vanligtvis definieras mått i övervakningsplattformen, och övervakningsplattformen och andra verktyg avsöker arbetsbelastningen för att samla in mått.

Programdata

För program kan insamlingstjänsten vara ett APM-verktyg (Application Performance Management) som kan köras autonomt från programmet som genererar instrumentationsdata. När APM har aktiverats har du tydlig insyn i viktiga mått, i realtid och historiskt. Använd en lämplig loggningsnivå. Utförlig loggning kan medföra betydande kostnader. Ange loggnivåer enligt miljön. Lägre miljöer behöver inte samma detaljnivå som produktion, till exempel.

Programloggar stöder programlivscykeln från slutpunkt till slutpunkt. Loggning är viktigt för att förstå hur programmet fungerar i olika miljöer, vilka händelser som inträffar och under vilka förhållanden de inträffar.

Vi rekommenderar att du samlar in programloggar och händelser i alla större miljöer. Avgränsa data mellan miljöer så mycket som möjligt genom att använda olika datalager för varje miljö, om det är praktiskt. Använd filter för att säkerställa att icke-kritiska miljöer inte komplicerar tolkningen av produktionsloggar. Slutligen bör motsvarande loggposter i programmet samla in ett korrelations-ID för respektive transaktioner.

Du bör samla in programhändelser i strukturerade datatyper med maskinläsbara datapunkter i stället för ostrukturerade strängtyper. Ett strukturerat format som använder ett välkänt schema kan göra det enklare att parsa och analysera loggar. Dessutom kan strukturerade data enkelt indexeras och sökas igenom, och rapporteringen kan förenklas avsevärt.

Data ska vara i ett agnostiskt format som är oberoende av datorn, operativsystemet eller nätverksprotokollet. Du kan till exempel generera information i ett självbeskrivande format som JSON, MessagePack eller Protobuf i stället för ETL/ETW. Med ett standardformat kan systemet konstruera bearbetningspipelines. Komponenter som läser, transformerar och skickar data i standardformatet kan enkelt integreras.

Infrastrukturdata

Se till att du samlar in både loggar och mått för infrastrukturresurser i din arbetsbelastning. För IaaS-system (infrastruktur som en tjänst) samlar du in operativsystem, programlager och diagnostikloggar utöver mått som rör arbetsbelastningshälsa. För PaaS-resurser (plattform som en tjänst) kan du vara begränsad i din förmåga att samla in loggar som är relaterade till underliggande infrastruktur, men se till att du kan samla in diagnostikloggar utöver mått relaterade till arbetsbelastningshälsa.

Så mycket som möjligt samlar du in loggar från din molnplattform. Du kanske kan samla in aktivitetsloggar för din prenumeration och diagnostikloggar för hanteringsplanet.

Insamlingsstrategier

Undvik att hämta telemetridata manuellt från varje komponent. Flytta data till en central plats och konsolidera dem där. För en lösning med flera regioner rekommenderar vi att du först samlar in, konsoliderar och lagrar data region för region och sedan aggregerar regionala data till ett enda centralt system.

Kompromiss: Tänk på att det finns kostnadskonsekvenser med att ha regionala och centraliserade datalager.

För att optimera användningen av bandbredd prioriterar du baserat på vikten av data. Du kan överföra mindre brådskande data i batchar. Dessa data får dock inte fördröjas på obestämd tid, särskilt om de innehåller tidskänslig information.

Det finns två primära modeller som samlingstjänsten kan använda för att samla in instrumentationsdata:

• Pull-modell: Hämtar aktivt data från de olika loggarna och andra källor för varje instans av programmet.

• Push-modell: Väntar passivt på att data ska skickas från de komponenter som utgör varje instans av programmet.

Övervakningsagenter

Du kan använda övervakningsagenter i pull-modellen. Agenter körs lokalt i en separat process med varje instans av programmet, hämtar regelbundet data och skriver informationen direkt till gemensam lagring som delas av alla instanser av programmet.

Prestandaöverväganden

Ett komplext och mycket skalbart program kan generera enorma mängder data. Mängden data kan enkelt överbelasta I/O-bandbredden som är tillgänglig för en enda central plats. Telemetrilösningen får inte fungera som flaskhals och måste vara skalbar när systemet expanderar. I bästa fall bör lösningen innehålla en viss redundans för att minska riskerna med att förlora viktig övervakningsinformation (t.ex. gransknings- eller faktureringsdata) om en del av systemet misslyckas.

Ett sätt att buffera instrumentationsdata är att använda köer:

I den här arkitekturen publicerar datainsamlingstjänsten data till en kö. En meddelandekö är lämplig eftersom den innehåller "minst en gång" semantik som hjälper till att säkerställa att köade data inte går förlorade när de har publicerats. Du kan implementera tjänsten för lagringsskrivning med hjälp av en separat arbetsroll. Du kan använda mönstret Prioritetskö för att implementera den här arkitekturen.

För skalbarhet kan du köra flera instanser av tjänsten för lagringsskrivning. Om en stor mängd händelser eller ett stort antal datapunkter övervakas kan du använda Azure Event Hubs för att skicka data till en annan beräkningsinstans för bearbetning och lagring.

Konsolideringsstrategier

Data som samlas in från en enda instans av ett program ger en lokaliserad vy över den instansens hälsa och prestanda. För att utvärdera systemets övergripande hälsa måste du konsolidera vissa aspekter av data från de lokala vyerna. Du kan göra det när data har lagrats, men i vissa fall kan du göra det när data samlas in.

Instrumentationsdata kan passera genom en separat datakonsolideringstjänst som kombinerar data och fungerar som en filter- och rensningsprocess. Du kan till exempel amalgamatera instrumentationsdata som innehåller samma korrelationsinformation, till exempel ett aktivitets-ID. (En användare kan starta en affärsåtgärd på en nod och sedan överföras till en annan nod om den första noden misslyckas eller på grund av hur belastningsutjämning har konfigurerats.) Den här processen kan också identifiera och ta bort duplicerade data. (Duplicering kan inträffa om telemetritjänsten använder meddelandeköer för att skicka ut instrumentationsdata till lagring.)

Lagra data för frågor och analyser

När du väljer en lagringslösning bör du tänka på typen av data, hur den används och hur brådskande den är nödvändig.

Lagringstekniker

Överväg en flerspråkig beständighetsmetod, där olika typer av information lagras i tekniker som är mest lämpliga för hur varje typ sannolikt kommer att användas.

Till exempel används Azure Blob Storage och Azure Table Storage på liknande sätt. Men de åtgärder som du kan utföra på dem skiljer sig åt, liksom kornigheten för de data som de har. Om du behöver utföra mer analytiska åtgärder eller kräver sökfunktioner för fullständig text på dina data kan det vara mer användbart att använda datalagring med funktioner som är optimerade för specifika typer av frågor och dataåtkomst. Till exempel:

• Prestandaräknardata kan lagras i en SQL-databas för att aktivera ad hoc-analyser.

• Det kan vara bättre att lagra spårningsloggar i Azure Monitor-loggar eller Azure Data Explorer.

• Du kan lagra säkerhetsinformation i en HDFS-lösning.

Samma instrumentationsdata kan krävas för flera ändamål. Du kan till exempel använda prestandaräknare för att ge en historisk vy över systemprestanda över tid. Genom att kombinera den här informationen med andra användningsdata kan du generera kundens faktureringsinformation. I dessa situationer kan samma data skickas till fler än ett mål, till exempel till en dokumentdatabas som kan vara ett långsiktigt lager för att lagra faktureringsinformation och till ett flerdimensionellt lager för hantering av komplexa prestandaanalyser.

Se till att aktivera funktioner för att skydda data från oavsiktlig borttagning, till exempel resurslås och mjuk borttagning.

Se också till att du skyddar åtkomsten till lagring med hjälp av rollbaserad åtkomstkontroll för att säkerställa att endast personer som behöver komma åt data kan göra det.

Konsolideringstjänst

Du kan implementera en annan tjänst som regelbundet hämtar data från delad lagring, partitioner och filtrerar dem enligt dess syfte och sedan skriver dem till en lämplig uppsättning datalager.

En annan metod är att inkludera den här funktionen i konsoliderings- och rensningsprocessen och skriva data direkt till lagringsplatserna när de hämtas, istället för att spara dem i en mellanliggande delad lagringsplats.

Varje metod har sina för- och nackdelar. Om du implementerar en separat partitioneringstjänst minskar belastningen på konsoliderings- och rensningstjänsten, och det gör att åtminstone en del av de partitionerade data kan återskapas om det behövs (beroende på hur mycket data som behålls i delad lagring). Den här metoden förbrukar dock ytterligare resurser. Dessutom kan det vara en fördröjning mellan mottagandet av instrumentationsdata från varje programinstans och konverteringen av data till tillämplig information.

Frågeöverväganden

Överväg hur snabbt data krävs. Data som genererar aviseringar måste nås snabbt, så de bör lagras i snabb datalagring och indexeras eller struktureras för att optimera de frågor som aviseringssystemet utför. I vissa fall kan det vara nödvändigt för insamlingstjänsten att formatera och spara data lokalt så att en lokal instans av aviseringssystemet snabbt kan skicka meddelanden. Samma data kan skickas till tjänsten för att skriva till lager, som visas i tidigare diagram, och lagras centralt om det krävs av andra orsaker.

Överväganden för datakvarhållning

I vissa fall när data har bearbetats och överförts kan du ta bort de ursprungliga rådata som lagrades lokalt. I andra fall kan det vara nödvändigt eller användbart att spara rådata. Du kanske till exempel vill behålla data som genereras för felsökning i dess råa formulär, men sedan ta bort dem snabbt när eventuella buggar har lösts.

Prestandadata har ofta en längre livslängd så att du kan använda dem för att upptäcka prestandatrender och för kapacitetsplanering. Samlad vy över dessa data lagras vanligtvis online under en begränsad period för snabb åtkomst. Efteråt kan den arkiveras eller tas bort.

Det är användbart att lagra historiska data så att du kan upptäcka långvariga trender. I stället för att spara gamla data i sin helhet kanske du kan minska dataexemplet för att minska dess upplösning och spara lagringskostnader. I stället för att till exempel spara prestandaindikatorer minut för minut kan du konsolidera data som är mer än en månad gamla för att bilda en timme för timme-vy.

Data som samlas in för mätning och fakturering av kunder kan behöva sparas på obestämd tid. Dessutom kan regelkrav kräva att information som samlas in för granskning och säkerhet måste arkiveras och sparas. Dessa data är också känsliga och kan behöva krypteras och skyddas på annat sätt för att förhindra manipulation. Du bör aldrig registrera användarlösenord eller annan information som kan användas för att begå identitetsbedrägerier. Du bör rensa informationen från data innan den lagras.

För att säkerställa att du följer lagar och föreskrifter minimerar du lagringen av identifierbar information. Om du behöver lagra identifierbar information måste du, när du utformar din lösning, ta hänsyn till krav som gör det möjligt för enskilda att begära att deras information tas bort.

Analysera data för att förstå hälsotillståndet för en arbetsbelastning

När du har samlat in data från olika datakällor analyserar du dem för att utvärdera systemets övergripande välbefinnande. För den här analysen har du en tydlig förståelse för:

• Så här strukturerar du data baserat på KPI:er och prestandamått som du har definierat.

• Så här korrelerar du data som samlas in i olika mått och loggfiler. Den här korrelationen är viktig när du spårar en sekvens med händelser och kan hjälpa dig att diagnostisera problem.

I de flesta fall samlas data för varje komponent i arkitekturen in lokalt och kombineras sedan korrekt med data som genereras av andra komponenter.

Ett program med tre nivåer kan till exempel ha:

• En presentationsnivå som gör att en användare kan ansluta till en webbplats.

• En mellannivå som är värd för en uppsättning mikrotjänster som bearbetar affärslogik.

• En databasnivå som lagrar data som är associerade med åtgärden.

Användningsdata för en enskild affärsåtgärd kan sträcka sig över alla tre nivåerna. Den här informationen måste korreleras för att ge en övergripande vy över resursen och bearbetningsanvändningen för åtgärden. Korrelationen kan omfatta viss förbearbetning och filtrering av data på databasnivån. På mellannivån är aggregering och formatering vanliga uppgifter.

Rekommendationer

• Korrelera loggar på programnivå och resursnivå. Utvärdera data på båda nivåerna för att optimera identifieringen av problem och felsökning av dessa problem. Du kan aggregera data i en enda datamottagare eller dra nytta av metoder som frågar efter händelser på båda nivåerna. Vi rekommenderar en enhetlig lösning, till exempel Azure Log Analytics, för att aggregera och fråga efter loggar på programnivå och på resursnivå.

• Definiera tydliga kvarhållningstider för lagring för kall analys. Vi rekommenderar den här metoden för att aktivera historisk analys under en viss period. Det kan också hjälpa dig att kontrollera lagringskostnaderna. Implementera processer som säkerställer att data arkiveras till billigare lagring och aggregerade data för långsiktig trendanalys.

• Analysera långsiktiga trender för att förutsäga driftsproblem. Utvärdera långsiktiga data för att bilda operativa strategier och även för att förutsäga vilka driftsproblem som sannolikt kommer att uppstå och när. Du kan till exempel tänka på att genomsnittliga svarstider långsamt ökar med tiden och närmar sig det maximala målet.

Detaljerad vägledning om dessa rekommendationer finns i Analysera övervakningsdata för molnprogram.

Visualisera hälsorapporter för arbetsbelastningar

Instrumentpaneler

Det vanligaste sättet att visualisera data är att använda instrumentpaneler som kan visa information som en serie diagram eller diagram, eller i något annat visuellt formulär. Dessa objekt kan parametriseras och en analytiker kan välja viktiga parametrar, till exempel tidsperioden, för varje specifik situation.

Justera dina instrumentpaneler med din hälsomodell så att de anger när arbetsbelastningen eller komponenterna i arbetsbelastningen är felfria, degraderade eller inte felfria.

För att ett instrumentpanelssystem ska fungera effektivt måste det vara meningsfullt för arbetsbelastningsteamet. Visualisera information som relaterar till arbetsbelastningens hälsa och som också kan användas. När arbetsbelastningen eller en komponent är degraderad eller inte felfri bör medlemmar i arbetsbelastningsteamet enkelt kunna identifiera var i arbetsbelastningen problemet kommer från och påbörja sina korrigerande åtgärder eller undersökningar. Att inkludera information som inte kan användas eller som inte är relaterad till arbetsbelastningens hälsa kan göra instrumentpanelen onödigt komplex och frustrerande för teammedlemmar som försöker urskilja bakgrundsbrus från åtgärdsbara data.

Du kan ha instrumentpaneler för intressenter eller utvecklare som är anpassade för att endast visa data om den arbetsbelastning som de tycker är relevant. Se till att arbetsbelastningsteamet förstår vilka typer av datapunkter som andra team är intresserade av att se och förhandsgranska instrumentpanelerna innan de delas för att söka efter klarhet. Att tillhandahålla instrumentpaneler om din arbetsbelastning för intressenter är ett bra sätt att hålla dem underrättade om arbetsbelastningens hälsa, men det finns risk för att de blir kontraproduktiva om intressenterna inte tydligt förstår de data de ser.

En bra instrumentpanel visar inte bara information. Det gör det också möjligt för en analytiker att ställa improviserade frågor om den informationen. Vissa system tillhandahåller hanteringsverktyg som en operatör kan använda för att utföra dessa uppgifter och utforska underliggande data. Beroende på vilken lagringsplats som används för att lagra informationen kan det i stället vara möjligt att fråga data direkt eller importera dem till verktyg som Excel för ytterligare analys och rapportering.

Rapportering

Rapportering används till att generera en översiktlig vy av systemet. Den kan innehålla historiska data och aktuell information. Rapporteringskraven delas in i två breda kategorier: driftrapportering och säkerhetsrapportering.

Driftrapportering omfattar vanligtvis följande:

• Aggregera statistik som du kan använda för att förstå resursanvändningen för det övergripande systemet eller angivna undersystem under en angiven tidsperiod.

• Identifiera trender i resursanvändningen för det övergripande systemet eller angivna undersystem under en angiven period.

• Övervakningsfel som har inträffat i hela systemet eller i angivna undersystem under en angiven period.

• Fastställa programmets effektivitet för de distribuerade resurserna och förstå om resursvolymen och deras associerade kostnader kan minskas utan att prestandan påverkas i onödan.

Säkerhetsrapportering spårar kundens användning av systemet. Det kan omfatta:

• Granska användaråtgärder. Den här uppgiften kräver att du registrerar de enskilda begäranden som varje användare slutför, tillsammans med datum och tider. Data bör struktureras så att en administratör snabbt kan rekonstruera den åtgärdssekvens som en användare slutför under en angiven period.

• Spårning av användares resursanvändning. Den här uppgiften kräver att du registrerar hur varje begäran från en användare kommer åt de olika resurser som utgör systemet och hur länge. En administratör kan använda dessa data för att generera en användningsrapport, per användare, under en angiven period, eventuellt för fakturering.

Ofta kan batchprocesser generera rapporter enligt ett definierat schema. Svarstid är normalt inte ett problem. Du bör också ha batchprocesser som kan generera rapporter spontant efter behov. Om du till exempel lagrar data i en relationsdatabas som Azure SQL Database kan du använda ett verktyg som SQL Server Reporting Services för att extrahera och formatera data och presentera dem som en uppsättning rapporter.

Definiera aviseringar för nyckelhändelser

För att säkerställa att systemet förblir felfritt, dynamiskt och säkert anger du aviseringar så att operatörerna kan svara på dem i tid. En avisering kan innehålla tillräckligt med sammanhangsinformation för att hjälpa dem att snabbt komma igång med diagnostikaktiviteter. Aviseringar kan användas för att anropa reparationsfunktioner som autoskalning eller andra självåterställningsmekanismer. Aviseringar kan också möjliggöra kostnadsmedvetenhet genom att ge insyn i budgetar och gränser.

Rekommendationer

• Definiera en process för aviseringssvar som identifierar ansvariga ägare och åtgärder.

• Konfigurera aviseringar för ett väldefinierat omfång (resurstyper och resursgrupper) och justera verbositeten för att minimera bruset.

• Använd en automatiserad aviseringslösning, till exempel Splunk eller Azure Monitor, i stället för att kräva att personer aktivt söker efter problem.

• Använd aviseringar för att operationalisera reparationsprocesser. Skapa till exempel automatiskt biljetter för att spåra problem och lösningar.

• Spåra hälsotillståndet för dina molnplattformstjänster i regioner, kommunikation om avbrott, planerade underhållsaktiviteter och andra hälsorekommendationer.

Tröskelvärden

Aviseringar genereras när tröskelvärden överskrids, vilket identifieras av övervakningssystemet. Se till att de tröskelvärden som du anger i allmänhet ger dig tillräckligt med tid för att implementera nödvändiga ändringar i arbetsbelastningen för att undvika försämring eller avbrott. Ställ till exempel in tröskelvärdet för automatisk skalning för att initiera skalning innan något av de system som körs överbelastas till den grad att användarupplevelsen försämras. Basera tröskelvärdena som du tilldelar på din tidigare erfarenhet av att hantera infrastrukturen och verifiera dem genom de tester som du utför som en del av dina testmetoder.

Detaljerad vägledning om aviseringsanvändningsfall och andra överväganden finns i Utforma en tillförlitlig strategi för övervakning och aviseringar.

Azure-underlättande

• Azure Monitor är en omfattande övervakningslösning för att samla in, analysera och svara på övervakningsdata från molnmiljöer och lokala miljöer.

• Log Analytics är ett verktyg i Azure Portal som du kan använda för att redigera och köra loggfrågor mot data på Log Analytics-arbetsytan.

  Om du använder flera arbetsytor kan du läsa arkitekturguiden för Log Analytics-arbetsytor för bästa praxis.

• Application Insights är ett tillägg till Azure Monitor. Den innehåller APM-funktioner.

• Azure Monitor Insights är avancerade analysverktyg för specifika Azure-tekniker (till exempel virtuella datorer, apptjänster och containrar). De här verktygen ingår i Azure Monitor och Log Analytics.

• Azure Monitor för SAP-lösningar är ett Azure-övervakningsverktyg för SAP-landskap som körs i Azure.

• Azure Policy kan hjälpa dig att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala.

Relaterade länkar

• Instrumentationsguide
• Rekommendationer för att utforma en tillförlitlig strategi för övervakning och avisering
• Rekommendationer för övervakning och hotidentifiering
• Rekommendationer för insamling av prestandadata

Communitylänkar

• Azure Monitor Baseline Alerts (AMBA) är en central lagringsplats för aviseringsdefinitioner som kunder och partner kan använda för att förbättra sin observerbarhetsupplevelse genom att använda Azure Monitor.

Checklista för driftskvalitet

Se den fullständiga uppsättningen rekommendationer.