Molnövervakningsguide: Aviseringar

I flera år har IT-organisationer haft svårt att motverka den varningsutmattning som skapats av de övervakningsverktyg som distribueras i företaget. Många system genererar en stor mängd aviseringar som ofta anses vara betydelselösa, medan andra aviseringar är relevanta men antingen förbises eller ignoreras. Därför har IT- och utvecklaråtgärderna haft svårt att uppfylla den servicenivåkvalitet som har utlovats till interna eller externa kunder. För att säkerställa tillförlitlighet är det viktigt att förstå tillståndet för din infrastruktur och dina program. För att minimera tjänstförsämring och avbrott, eller för att minska effekten av eller minska antalet incidenter, måste du snabbt identifiera orsaker.

Lyckad aviseringsstrategi

Du kan inte åtgärda att det du inte vet är brutet.

Aviseringar om det som är viktigt. Den bygger på att samla in och mäta rätt mått och loggar. Du behöver också ett övervakningsverktyg som kan lagra, aggregera, visualisera, analysera och initiera ett automatiserat svar när villkoren är uppfyllda. Du kan bara förbättra observerbarheten för dina tjänster och program om du förstår dess sammansättning fullt ut. Du mappar sammansättningen till en detaljerad övervakningskonfiguration som ska tillämpas av övervakningsplattformen. Den här konfigurationen innehåller de förutsägbara fel tillstånden (symptom, inte orsaken till felet) som är meningsfulla att varna för.

Överväg följande principer för att avgöra om ett symtom är en lämplig kandidat för avisering:

  • Spelar det någon roll? Är problemet symtomatiskt för ett verkligt problem eller problem som påverkar programmets övergripande hälsa? Bryr du dig till exempel om cpu-användningen är hög på resursen? Eller att en viss SQL-fråga som körs på en SQL Database-instans på den resursen förbrukar hög CPU-användning under en längre tid? Eftersom cpu-användningsvillkoret är ett verkligt problem bör du avisering om det. Men du behöver inte meddela teamet eftersom det inte hjälper att peka på vad som orsakar villkoret från början. Aviseringar och aviseringar om användningsproblemet med SQL-frågeprocessen är både relevant och kan åtgärdas.
  • Är det brådskande? Är problemet verkligt och behöver det brådskande åtgärder? I så fall bör det ansvariga teamet meddelas omedelbart.
  • Påverkas dina kunder? Påverkas användare av tjänsten eller programmet på grund av problemet?
  • Påverkas andra beroende system? Finns det aviseringar från beroenden som är relaterade till varandra och som eventuellt kan korreleras för att undvika att meddela olika team att alla arbetar med samma problem?

Ställ dessa frågor när du först utvecklar en övervakningskonfiguration. Testa och validera antagandena i en icke-produktionsmiljö och distribuera sedan till produktion. Övervakningskonfigurationer härleds från kända fellägen, testresultat av simulerade fel och erfarenheter från olika medlemmar i teamet.

När övervakningskonfigurationen har släppts kan du lära dig mycket om vad som fungerar och inte. Överväg hög aviseringsvolym, problem som inte uppmärksammas av övervakning men som märkts av slutanvändarna och vilka åtgärder som är bäst att vidta som en del av den här utvärderingen. Identifiera ändringar som ska implementeras för att förbättra tjänstleveransen som en del av en pågående process för kontinuerlig övervakning av förbättringar. Det handlar inte bara om att utvärdera aviseringsbruset eller missade aviseringar, utan även hur effektivt du övervakar arbetsbelastningen. Det handlar om effektiviteten i dina aviseringsprinciper, processer och den övergripande kulturen för att avgöra om du förbättrar.

Både System Center Operations Manager och Azure Monitor aviseringar baserat på statiska eller till och med dynamiska tröskelvärden och åtgärder som konfigureras ovanpå dem. Exempel på detta är aviseringar för e-post, SMS och röstsamtal för enkla meddelanden. Båda dessa tjänster stöder även Hantering av IT-tjänster (ITSM)-integrering (ITSM) för att automatisera skapandet av incidentposter och eskalera till rätt supportteam eller något annat aviseringshanteringssystem som använder en webhook.

När det är möjligt kan du använda någon av flera tjänster för att automatisera återställningsåtgärder. Dessa omfattar System Center Orchestrator, Azure Automation, Azure Logic Apps eller autoskalning när det gäller elastiska arbetsbelastningar. Att meddela de ansvariga teamen är den vanligaste aviseringsåtgärden, men det kan också vara lämpligt att automatisera korrigerande åtgärder. Den här automatiseringen kan effektivisera hela incidenthanteringsprocessen. Automatisering av dessa återställningsuppgifter kan också minska risken för mänskliga fel.

Azure Monitor aviseringar

Om du endast använder Azure Monitor följer du dessa riktlinjer när du överväger hastighet, kostnad och lagringsvolym.

Beroende på vilken funktion och konfiguration du använder kan du lagra övervakningsdata i någon av sex databaser:

  • Azure Monitor måttdatabas: En tidsseriedatabas används främst för Azure Monitor plattformsmått, men har även Application Insights måttdata speglade i den. Informationen som matas in i den här databasen har de snabbaste aviseringstiderna.

  • Application Insights resurs: En databas som lagrar Application Insights telemetri i loggformulär.

  • Azure Monitor Log Analytics-arbetsyta: Det primära arkivet för Azure-loggdata. Andra verktyg kan dirigera data till den och kan analyseras i Azure Monitor Loggar. På grund av inmatning och indexering har loggaviseringsfrågor högre svarstid. Den här svarstiden är vanligtvis 5–10 minuter, men kan vara högre under vissa omständigheter.

  • Aktivitetslogg: Används för alla aktivitetslogg- och tjänsthälsohändelser. Dedikerade aviseringar är möjliga. Innehåller händelser på prenumerationsnivå som inträffar på objekt i din prenumeration, som visas utifrån dessa objekt. Ett exempel kan vara när en princip anges eller när en resurs används eller tas bort.

  • Azure Storage: Lagring för generell användning som stöds av Azure Diagnostics och andra övervakningsverktyg. Det är ett kostnadseffektivt alternativ för långsiktig kvarhållning av övervakning av telemetri. Aviseringar stöds inte från data som lagras i den här tjänsten.

  • Event Hubs: Används vanligtvis för att strömma data till lokala eller andra partners övervakningsverktyg eller ITSM-verktyg.

Azure Monitor har fyra typer av aviseringar, som var och en är något knuten till lagringsplatsen som data lagras i:

  • Måttavisering:Aviseringar om måttdata i Azure Monitor. Aviseringar inträffar när ett övervakat värde passerar ett användardefinierat tröskelvärde och sedan igen när det återgår till "normalt" tillstånd.

  • Avisering om loggfråga:Tillgänglig för att varna om loggdata från Application Insights eller Azure Monitor Loggar. Den kan också avisering baserat på frågor mellan arbetsytor.

  • Aktivitetsloggavisering:Aviseringar för objekt i aktivitetsloggen, med undantag för Azure Service Health data.

  • Azure Service Health avisering:En särskild typ av avisering som endast används för Azure Service Health problem som kommer från aktivitetsloggen, till exempel avbrott och kommande planerat underhåll. Observera att den här typen av avisering konfigureras via Azure Service Health, en tillhörande tjänst för Azure Monitor.

Aktivera aviseringar via partnerverktyg

Om du använder en extern aviseringslösning dirigerar du så mycket du kan genom Azure Event Hubs, vilket är den snabbaste vägen ut Azure Monitor. Du måste betala för inmatning till Event Hubs. Om kostnaden är ett problem och hastigheten inte är det kan du använda Azure Storage ett billigare alternativ. Se bara till att dina övervakningsverktyg eller ITSM-verktyg kan Azure Storage för att extrahera data.

Azure Monitor har stöd för integrering med andra övervakningsplattformar och ITSM-programvara som ServiceNow. Du kan använda Azure-aviseringar och fortfarande utlösa åtgärder utanför Azure, enligt vad som krävs av din incidenthantering eller DevOps-process. Om du vill varna i Azure Monitor och automatisera svaret kan du initiera automatiserade åtgärder med hjälp av Azure Functions, Azure Logic Apps eller Azure Automation, baserat på ditt scenario och dina krav.

Specialiserade Azure-övervakningserbjudanden

Hanteringslösningar lagrar vanligtvis sina data Azure Monitor loggar. Två undantag är Azure Monitor for VMs och Azure Monitor för containrar. I följande tabell beskrivs aviseringsupplevelsen baserat på den specifika datatypen och var den lagras.

Lösning Datatyp Aviseringsbeteende
Azure Monitor för containrar Beräknade genomsnittliga prestandadata från noder och poddar skrivs till måttdatabasen. Skapa måttaviseringar om du vill få aviseringar baserat på variation av uppmätt användningsprestanda, aggregerade över tid.
Beräknade prestandadata som använder percentiler från noder, kontrollanter, containrar och poddar skrivs till arbetsytan. Containerloggar och inventeringsinformation skrivs också till arbetsytan. Skapa loggafrågeaviseringar om du vill få aviseringar baserat på variationen av uppmätt användning från kluster och containrar. Logga frågeaviseringar kan också konfigureras baserat på antal poddfaser och antal statusnoder.
Azure Monitor för virtuella datorer Hälsokriterier är mått som lagras i måttdatabasen. Aviseringar genereras när hälsotillståndet ändras från felfritt till inte felfritt. Den här aviseringen stöder endast åtgärdsgrupper som är konfigurerade för att skicka SMS eller e-postmeddelanden.
Loggdata för map- och gästoperativsystemets prestanda skrivs till Log Analytics-arbetsytan. Skapa loggfrågasaviseringar.

Snabbaste hastighet, drivet av kostnad

Svarstiden är ett av de viktigaste besluten som orsakar aviseringar och en snabb lösning av problem som påverkar din tjänst. Om du behöver aviseringar i nära realtid under fem minuter bör du först utvärdera om du har eller kan få aviseringar om din telemetri där den lagras som standard. I allmänhet är den här strategin också det billigaste alternativet, eftersom det verktyg som du använder redan skickar sina data till den platsen.

Det finns dock några viktiga fotnoter till den här regeln.

Gästoperativsystemtelemetri har flera sökvägar för att komma in i systemet.

  • Det snabbaste sättet att varna om dessa data är att importera dem som anpassade mått. Gör detta med hjälp av Azure Diagnostics och sedan använda en måttavisering. Anpassade mått är dock för närvarande i förhandsversion och är dyrare än andra alternativ.

  • Den billigaste, men med viss inmatningssvarstid, är att skicka den till en Log Analytics-arbetsyta. Att köra Log Analytics-agenten på den virtuella datorn är det bästa sättet att hämta alla mått för gästoperativsystemet och logga data till arbetsytan.

  • Du kan skicka den för lagring som ett mått och en Azure Monitor genom att köra både Azure Diagnostics-tillägget och Log Analytics-agenten på samma virtuella dator. Du kan sedan avisering snabbare, men även använda gästoperativsystemets data som en del av mer komplexa frågor när du kombinerar dem med annan telemetri.

Importera data från en lokal plats: Om du försöker köra frågor mot och övervaka datorer som körs i Azure och lokalt kan du använda Log Analytics-agenten för att samla in information om gästoperativsystemet. Du kan sedan använda en funktion som kallas loggar till mått för att samla in och lagra som mått i Azure Monitor. Den här metoden kringgår en del av inmatningsprocessen till Azure Monitor Loggar och data är därför tillgängliga tidigare.

Minimera aviseringar

Om du använder en lösning som Azure Monitor for VMs och hittar de standardhälsokriterier som övervakar prestandaanvändningen som är godtagbara ska du inte skapa överlappande mått eller logga frågeaviseringar baserat på samma prestandaräknare.

Om du inte använder Azure Monitor for VMs kan du göra det enklare att skapa aviseringar och hantera meddelanden genom att utforska följande funktioner:

Anteckning

Dessa funktioner gäller endast för måttaviseringar, aviseringar baserat på data som skickas till Azure Monitor måttdatabasen. Funktionerna gäller inte för de andra typerna av aviseringar. Som tidigare nämnts är det primära målet för måttaviseringar hastighet. Om det inte är något viktigt att få en avisering på mindre än fem minuter kan du använda en loggfrågasavisering i stället.

  • Dynamiska tröskelvärden:Dynamiska tröskelvärden tittar på resursens aktivitet under en tidsperiod och skapar övre och lägre tröskelvärden för "normalt beteende". När måttet som övervakas ligger utanför dessa tröskelvärden får du en avisering.

  • Multisignalaviseringar:Du kan skapa en måttavisering som använder en kombination av två olika indata från två olika resurstyper. Om du till exempel vill skicka en avisering när CPU-användningen av en virtuell dator är över 90 procent och antalet meddelanden i en viss Azure Service Bus-kö som matar den virtuella datorn överskrider en viss mängd, kan du göra det utan att skapa en loggfråga. Den här funktionen fungerar bara för två signaler. Om du har en mer komplex fråga kan du mata in dina måttdata i Log Analytics-arbetsytan och använda en loggfråga.

  • Aviseringar med flera resurser:Azure Monitor tillåter en enskild måttaviseringsregel som gäller för alla VM-resurser. Den här funktionen kan spara tid eftersom du inte behöver skapa enskilda aviseringar för varje virtuell dator. Priserna för den här typen av avisering är desamma. Oavsett om du skapar 50 aviseringar för övervakning av CPU-användning för 50 virtuella datorer eller en avisering som övervakar CPU-användningen för alla 50 virtuella datorer kostar det samma belopp. Du kan även använda dessa typer av aviseringar i kombination med dynamiska tröskelvärden.

Tillsammans kan dessa funktioner spara tid genom att minimera aviseringsmeddelanden och hanteringen av de underliggande aviseringarna.

Begränsningar för aviseringar

Se till att notera gränserna för antalet aviseringar som du kan skapa. Vissa gränser (men inte alla) kan ökas genom att du anropar supporten.

Bästa frågeupplevelse

Om du letar efter trender för alla dina data är det klokt att importera alla dina data till Azure Monitor Logs, såvida de inte redan finns i Application Insights. Du kan skapa frågor på båda arbetsytorna, så du behöver inte flytta data mellan dem. Du kan också importera aktivitetsloggen och Azure Service Health data till Log Analytics-arbetsytan. Du betalar för den här inmatningen och lagringen, men du får alla dina data på ett och samma ställe för analys och frågor. Den här metoden ger dig också möjlighet att skapa komplexa frågevillkor och avisering om dem.