Metodtips för tillförlitlighet i Azure Monitor
I molnet bekräftar vi att fel inträffar. Målet är att minimera effekten av en enda komponent som havererar snarare än att förhindra fel helt och hållet. Använd följande information för att övervaka dina virtuella datorer och deras klientarbetsbelastningar för fel.
I den här artikeln beskrivs tillförlitlighet för Azure Monitor som en del av Azure Well-Architected Framework. Azures välstrukturerade ramverk består av en uppsättning vägledande principer som kan användas för att förbättra kvaliteten på en arbetsbelastning. Ramverket består av fem grundpelare för arkitekturkvalitet:
- Tillförlitlighet
- Säkerhet
- Kostnadsoptimering
- Driftseffektivitet
- Prestandaeffektivitet
Azure Monitor-loggar
Log Analytics-arbetsytor ger hög tillförlitlighet. Inmatningspipelinen, som skickar insamlade data till Log Analytics-arbetsytan, verifierar att Log Analytics-arbetsytan bearbetar varje loggpost innan den tar bort posten från röret. Om inmatningspipelinen inte är tillgänglig försöker agenterna som skickar databufferten och försöker skicka loggarna igen i många timmar.
Funktioner för Azure Monitor-loggar som förbättrar motståndskraften
Azure Monitor-loggar erbjuder flera funktioner som förbättrar arbetsytornas motståndskraft mot olika typer av problem. Du kan använda dessa funktioner individuellt eller i kombination, beroende på dina behov.
Den här videon ger en översikt över tillgängliga alternativ för tillförlitlighet och motståndskraft för Log Analytics-arbetsytor:
Skydd i regionen med hjälp av tillgänglighetszoner
Varje Azure-region som stöder tillgänglighetszoner har en uppsättning datacenter som är utrustade med oberoende infrastruktur för ström, kylning och nätverk.
Tillgänglighetszoner för Azure Monitor-loggar är redundanta, vilket innebär att Microsoft sprider tjänstbegäranden och replikerar data över olika zoner i regioner som stöds. Om en incident påverkar en zon använder Microsoft en annan tillgänglighetszon i regionen i stället automatiskt. Du behöver inte vidta några åtgärder eftersom det är sömlöst att växla mellan zoner.
I de flesta regioner stöder Tillgänglighetszoner för Azure Monitor-loggar dataresiliens, vilket innebär att dina lagrade data skyddas mot dataförluster relaterade till zonfel, men tjänståtgärder kan fortfarande påverkas av regionala incidenter. Om tjänsten inte kan köra frågor kan du inte visa loggarna förrän problemet har lösts.
En delmängd av tillgänglighetszonerna som stöder dataresiliens stöder också tjänstresiliens, vilket innebär att Azure Monitor Logs-tjänståtgärder – till exempel logginmatning, frågor och aviseringar – kan fortsätta i händelse av ett zonfel.
Tillgänglighetszoner skyddar mot infrastrukturrelaterade incidenter, till exempel lagringsfel. De skyddar inte mot problem på programnivå, till exempel felaktiga koddistributioner eller certifikatfel som påverkar hela regionen.
Säkerhetskopiering av data från specifika tabeller med kontinuerlig export
Du kan kontinuerligt exportera data som skickas till specifika tabeller på Din Log Analytics-arbetsyta till Azure Storage-konton.
Lagringskontot som du exporterar data till måste finnas i samma region som din Log Analytics-arbetsyta. För att skydda och ha åtkomst till dina inmatade loggar använder du ett geo-redundant lagringskonto, även om arbetsyteregionen är nere, enligt beskrivningen i Konfigurationsrekommendationer.
Exportmekanismen ger inte skydd mot incidenter som påverkar inmatningspipelinen eller själva exportprocessen.
Kommentar
Du kan komma åt data i ett lagringskonto från Azure Monitor-loggar med hjälp av operatorn externaldata. Exporterade data lagras dock i femminutersblobar och det kan vara besvärligt att analysera data som sträcker sig över flera blobar. Att exportera data till ett lagringskonto är därför en bra mekanism för säkerhetskopiering av data, men att ha säkerhetskopierade data i ett lagringskonto är inte idealiskt om du behöver det för analys i Azure Monitor-loggar. Du kan köra frågor mot stora volymer blobdata med hjälp av Azure Data Explorer, Azure Data Factory eller något annat verktyg för lagringsåtkomst.
Skydd mot gränsöverskridande dataskydd och tjänståterhämtning med hjälp av replikering av arbetsytor (förhandsversion)
Replikering av arbetsytor (förhandsversion) är den mest omfattande återhämtningslösningen eftersom den replikerar Log Analytics-arbetsytan och inkommande loggar till en annan region.
Replikering av arbetsytor skyddar både loggarna och tjänståtgärderna och gör att du kan fortsätta övervaka dina system i händelse av infrastruktur- eller programrelaterade regionomfattande incidenter.
Till skillnad från tillgänglighetszoner, som Microsoft hanterar från slutpunkt till slutpunkt, måste du övervaka den primära arbetsytans hälsa och bestämma när du ska växla över till arbetsytan i den sekundära regionen och tillbaka.
Checklista för design
- Aktivera replikering av arbetsytor för att säkerställa service och dataresiliens för regionomfattande incidenter.
- För att säkerställa skydd i regionen mot datacenterfel skapar du din arbetsyta i en region som stöder tillgänglighetszoner.
- För korsregional säkerhetskopiering av data i specifika tabeller använder du funktionen för kontinuerlig export för att skicka data till ett geo-replikerat lagringskonto.
- Övervaka hälsotillståndet för dina Log Analytics-arbetsytor.
Konfigurationsrekommendationer
| Rekommendation | Förmån |
|---|---|
| Aktivera replikering av arbetsytor för att säkerställa största möjliga motståndskraft. | Motståndskraft mellan regioner för arbetsytedata och tjänståtgärder. Replikering av arbetsytor (förhandsversion) säkerställer hög tillgänglighet genom att skapa en sekundär instans av arbetsytan i en annan region och mata in loggarna på båda arbetsytorna. Vid behov växlar du till den sekundära arbetsytan tills problemen som påverkar den primära arbetsytan har lösts. Du kan fortsätta att mata in loggar, köra frågor mot data, använda instrumentpaneler, aviseringar och Sentinel på den sekundära arbetsytan. Du har också åtkomst till loggar som matas in innan regionväxeln. Det här är en betald funktion, så fundera på om du vill replikera alla dina inkommande loggar eller bara vissa dataströmmar. |
| Om möjligt skapar du din arbetsyta i en region som har stöd för Azure Monitor-tjänstresiliens. | Motståndskraft i regionen för arbetsytedata och tjänståtgärder i händelse av datacenterproblem. Tillgänglighetszoner som stöder tjänstresiliens stöder också dataresiliens. Det innebär att även om ett helt datacenter blir otillgängligt gör redundansen mellan zoner att Azure Monitor-tjänståtgärder, till exempel inmatning och frågor, kan fortsätta att fungera och att dina inmatade loggar förblir tillgängliga. Tillgänglighetszoner ger skydd i regionen, men skyddar inte mot problem som påverkar hela regionen. Information om vilka regioner som stöder dataresiliens finns i Förbättra data- och tjänstresiliens i Azure Monitor-loggar med tillgänglighetszoner. |
| Skapa din arbetsyta i en region som stöder dataresiliens. | Skydd i regionen mot förlust av loggarna på din arbetsyta i händelse av datacenterproblem. Att skapa din arbetsyta i en region som stöder dataresiliens innebär att även om hela datacentret blir otillgängligt är dina inmatade loggar säkra. Om tjänsten inte kan köra frågor kan du inte visa loggarna förrän problemet har lösts. Information om vilka regioner som stöder dataresiliens finns i Förbättra data- och tjänstresiliens i Azure Monitor-loggar med tillgänglighetszoner. |
| Konfigurera dataexport från specifika tabeller till ett lagringskonto som replikeras mellan regioner. | Underhålla en säkerhetskopia av dina loggdata i en annan region. Med funktionen för dataexport i Azure Monitor kan du kontinuerligt exportera data som skickas till specifika tabeller till Azure Storage där de kan behållas under längre perioder. Använd ett geo-redundant lagringskonto (GRS) eller ett geo-zonredundant lagringskonto (GZRS) för att skydda dina data även om en hel region blir otillgänglig. Om du vill göra dina data läsbara från de andra regionerna konfigurerar du ditt lagringskonto för läsåtkomst till den sekundära regionen. Mer information finns i Azure Storage-redundans i en sekundär region och Azure Storage läsbehörighet till data i den sekundära regionen. För tabeller som inte stöder kontinuerlig dataexport kan du använda andra metoder för att exportera data, inklusive Logic Apps, för att skydda dina data. Detta är främst en lösning för att uppfylla efterlevnaden för datakvarhållning eftersom data kan vara svåra att analysera och återställa till arbetsytan. Dataexport är känslig för regionala incidenter eftersom den förlitar sig på stabiliteten i Azure Monitor-inmatningspipelinen i din region. Det ger inte återhämtning mot incidenter som påverkar den regionala inmatningspipelinen. |
| Övervaka hälsotillståndet för dina Log Analytics-arbetsytor. | Använd Log Analytics-arbetsyteinsikter för att spåra misslyckade frågor och skapa hälsostatusaviseringar för att proaktivt meddela dig om en arbetsyta blir otillgänglig på grund av ett datacenter eller ett regionalt fel. |
Jämföra motståndskraftsfunktioner i Azure Monitor-loggar
| Funktion | Serviceresiliens | Säkerhetskopiering av data | Hög tillgänglighet | Skyddsområde | Ställ in | Kostnad |
|---|---|---|---|---|---|---|
| Replikering av arbetsyta | ✅ | ✅ | ✅ | Skydd mellan regioner mot regionomfattande incidenter | Aktivera replikering av arbetsytan och relaterade regler för datainsamling. Växla mellan regioner efter behov. | Baserat på antalet replikerade GB:er och region. |
| Tillgänglighetszoner | ✅ I regioner som stöds |
✅ | ✅ | Skydd i regionen mot datacenterproblem | Aktiveras automatiskt i regioner som stöds. | Ingen kostnad |
| Kontinuerlig dataexport | ✅ | Skydd mot dataförlust på grund av ett regionalt fel 1 | Aktivera per tabell. | Kostnad för dataexport + Lagringsblob eller Händelsehubbar |
1 Dataexport ger skydd mellan regioner om du exporterar loggar till ett geo-replikerat lagringskonto. I händelse av en incident säkerhetskopieras tidigare exporterade data och är lättillgängliga. Ytterligare export kan dock misslyckas, beroende på incidentens art.
Aviseringar
Azure Monitor-aviseringar ger hög tillförlitlighet utan designbeslut. Villkor där en tillfällig förlust av aviseringsdata kan inträffa minimeras ofta av funktioner i andra Azure Monitor-komponenter.
Checklista för design
- Konfigurera aviseringsregler för tjänsthälsa.
- Konfigurera aviseringsregler för resurshälsa.
- Undvik tjänstbegränsningar för aviseringsregler som skapar storskaliga meddelanden.
Konfigurationsrekommendationer
| Rekommendation | Förmån |
|---|---|
| Konfigurera aviseringsregler för tjänsthälsa. | Tjänststatus aviseringar skickar meddelanden om avbrott, avbrott i tjänsten, planerat underhåll och säkerhetsrekommendationer. Se Skapa eller redigera en aviseringsregel. |
| Konfigurera aviseringsregler för resurshälsa. | Resource Health-aviseringar kan meddela dig nästan i realtid när dessa resurser har ändrat sin hälsostatus. Se Skapa eller redigera en aviseringsregel. |
| Undvik tjänstbegränsningar för aviseringsregler som skapar storskaliga meddelanden. | Om du har aviseringsregler som skickar ett stort antal meddelanden kan du nå tjänstgränserna för den tjänst som du använder för att skicka e-post eller SMS-meddelanden. Konfigurera programmatiska åtgärder eller välj en alternativ meddelandemetod eller leverantör för att hantera storskaliga meddelanden. Se Tjänstbegränsningar för meddelanden. |
Virtuella datorer
Checklista för design
- Skapa tillgänglighetsaviseringsregler för virtuella Azure-datorer.
- Skapa agentens pulsslagsaviseringsregel för att verifiera agentens hälsa.
- Konfigurera datainsamling och aviseringar för övervakning av tillförlitlighet för klientarbetsflöden.
Konfigurationsrekommendationer
| Rekommendation | beskrivning |
|---|---|
| Skapa tillgänglighetsaviseringsregler för virtuella Azure-datorer. | Använd tillgänglighetsmåttet (förhandsversion) för att spåra när en virtuell Azure-dator körs. Du kan snabbt aktivera en tillgänglighetsaviseringsregel för en enskild dator med hjälp av rekommenderade aviseringar, men en enda aviseringsregel som riktar sig till en resursgrupp eller prenumeration möjliggör tillgänglighetsaviseringar för alla virtuella datorer i det omfånget för en viss region. Det här är enklare att hantera än att skapa en aviseringsregel för varje virtuell dator och ser till att alla nya virtuella datorer som skapas i omfånget övervakas automatiskt. Den här aviseringsregeln kräver inte att Azure Monitor-agenten installeras på den virtuella datorn, men den är inte tillgänglig för virtuella datorer utanför Azure. |
| Skapa agentens pulsslagsaviseringsregel för att verifiera agentens hälsa. | Azure Monitor-agenten skickar ett pulsslag till Log Analytics-arbetsytan varje minut. Använd en aviseringsregel för loggsökning med hjälp av agentens pulsslag som ska aviseras när en agent slutar skicka pulsslag, vilket är en indikator på att den virtuella datorn är nere eller att agenten inte är felfri och att klientarbetsbelastningar inte övervakas. Den här aviseringsregeln kräver att Azure Monitor-agenten är installerad på den virtuella datorn och gäller för både virtuella Azure- och icke-Azure-datorer. |
| Konfigurera datainsamling och aviseringar för övervakning av tillförlitlighet för klientarbetsflöden. | Använd informationen på Övervaka virtuella datorer med Övervaka virtuella datorer med Azure Monitor: Samla in data för att konfigurera insamling av klienthändelser som anger potentiella problem med dina klientarbetsbelastningar. Använd informationen på Övervaka virtuella datorer med Övervaka virtuella datorer med Azure Monitor: Aviseringar för att skapa aviseringsregler som proaktivt meddelas om eventuella driftproblem med dina klientarbetsbelastningar. |
Containers
Checklista för design
- Aktivera skrapning av Prometheus-mått för klustret.
- Aktivera Container Insights för insamling av loggar och prestandadata från klustret.
- Skapa diagnostikinställningar för att samla in kontrollplansloggar för AKS-kluster.
- Aktivera rekommenderade Prometheus-aviseringar.
- Se till att Log Analytics-arbetsytan har stöd för containerinsikter.
Konfigurationsrekommendationer
| Rekommendation | Förmån |
|---|---|
| Aktivera skrapning av Prometheus-mått för klustret. | Aktivera Prometheus i klustret med Azure Monitor-hanterad tjänst för Prometheus om du inte redan har en Prometheus-miljö. Använd Azure Managed Grafana för att analysera de Prometheus-data som samlas in. Se Anpassa skrapning av Prometheus-mått i Azure Monitor-hanterad tjänst för Prometheus för att samla in ytterligare mått utöver standardkonfigurationen. |
| Aktivera Container Insights för insamling av loggar och prestandadata från klustret. | Containerinsikter samlar in stdout-/stderr-loggar, prestandamått och Kubernetes-händelser från varje nod i klustret. Den innehåller instrumentpaneler och rapporter för analys av dessa data, inklusive tillgängligheten för dina noder och andra komponenter. Använd Log Analytics för att identifiera eventuella tillgänglighetsfel i dina insamlade loggar. |
| Skapa diagnostikinställningar för att samla in kontrollplansloggar för AKS-kluster. | AKS implementerar kontrollplansloggar som resursloggar i Azure Monitor. Skapa en diagnostikinställning för att skicka loggarna till Log Analytics-arbetsytan så att du kan använda loggfrågor för att identifiera fel och problem som påverkar tillgängligheten. |
| Aktivera rekommenderade Prometheus-aviseringar. | Aviseringar i Azure Monitor meddelar dig proaktivt när problem identifieras. Börja med en uppsättning rekommenderade Prometheus-aviseringsregler som identifierar de vanligaste tillgänglighets- och prestandaproblemen med klustret. Potentiellt lägga till loggsökningsaviseringar med hjälp av data som samlas in av Container Insights. |
| Se till att Log Analytics-arbetsytan har stöd för containerinsikter. | Containerinsikter förlitar sig på en Log Analytics-arbetsyta. Se Metodtips för Azure Monitor-loggar för rekommendationer för att säkerställa arbetsytans tillförlitlighet. |