Share via

Azure Well-Architected Framework-perspektiv på Log Analytics

  • Artikel

Well-Architected Framework-arbetsbelastningsfunktioner och prestanda måste övervakas på olika sätt och av olika skäl. Azure Monitor Log Analytics-arbetsytor är den primära logg- och måttmottagaren för en stor del av övervakningsdata. Arbetsytor stöder flera funktioner i Azure Monitor, inklusive ad hoc-frågor, visualiseringar och aviseringar. Allmänna övervakningsprinciper finns i Vägledning för övervakning och diagnostik. I vägledningen presenteras allmänna övervakningsprinciper. Den identifierar de olika typerna av data. Den identifierar den analys som krävs som Stöds av Azure Monitor och identifierar även de data som lagras på arbetsytan som möjliggör analysen.

Den här artikeln förutsätter att du förstår systemdesignprinciper. Du behöver också en fungerande kunskap om Log Analytics-arbetsytor och funktioner i Azure Monitor som fyller i driftsarbetsbelastningsdata. Mer information finns i Översikt över Log Analytics-arbetsyta.

Viktigt

Så här använder du den här guiden

Varje avsnitt har en checklista för design som visar arkitekturområden och designstrategier som är lokaliserade till teknikomfånget.

Det finns även rekommendationer om teknikfunktioner eller distributionstopologier som kan hjälpa dig att materialisera dessa strategier. Rekommendationerna representerar inte en fullständig lista över alla konfigurationer som är tillgängliga för Log Analytics-arbetsytor och dess relaterade Azure Monitor-resurser. I stället listar de viktiga rekommendationer som mappats till designperspektiven. Använd rekommendationerna för att skapa ditt konceptbevis, utforma din arbetsbelastningsövervakningsmiljö eller optimera din befintliga lösning för arbetsbelastningsövervakning.

Teknikomfång

Den här guiden fokuserar på de relaterade besluten för följande Azure-resurser.

  • Log Analytics-arbetsytor
  • Arbetsloggdata för arbetsbelastning
  • Diagnostikinställningar för Azure-resurser i din arbetsbelastning

Tillförlitlighet

Syftet med grundpelarna för tillförlitlighet är att tillhandahålla fortsatt funktionalitet genom att skapa tillräcklig motståndskraft och möjlighet att snabbt återställa efter fel.

Designprinciperna för tillförlitlighet ger en övergripande designstrategi som tillämpas för enskilda komponenter, systemflöden och systemet som helhet.

De tillförlitlighetssituationer du bör tänka på för Log Analytics-arbetsytor är:

  • Tillgänglighet för arbetsytan.
  • Skydd av insamlade data i sällsynta fall av ett Azure-datacenter eller regionfel.

Det finns för närvarande ingen standardfunktion för redundans mellan arbetsytor i olika regioner, men det finns strategier att använda om du har särskilda krav för tillgänglighet eller efterlevnad.

Checklista för design för tillförlitlighet

Starta din designstrategi baserat på checklistan för designgranskning för tillförlitlighet och fastställa dess relevans för dina affärskrav samtidigt som du tänker på SKU:er och funktioner för virtuella datorer (VM) och deras beroenden. Utöka strategin till att omfatta fler metoder efter behov.

  • Granska tjänstgränser för Log Analytics-arbetsytor. Avsnittet om tjänstbegränsningar hjälper dig att förstå begränsningar för datainsamling och kvarhållning samt andra aspekter av tjänsten. De här gränserna hjälper dig att avgöra hur du ska utforma din strategi för arbetsbelastningsobservabilitet korrekt. Se till att granska tjänstbegränsningarna för Azure Monitor eftersom många av funktionerna som beskrivs där, till exempel frågor, fungerar hand i hand med Log Analytics-arbetsytor.
  • Planera för återhämtning och återhämtning på arbetsytan. Log Analytics-arbetsytor är regionala, utan inbyggt stöd för redundans eller replikering mellan regioner. Redundansalternativen för tillgänglighetszoner är också begränsade. Därför bör du fastställa tillförlitlighetskraven för dina arbetsytor och strategi för att uppfylla dessa mål. Dina krav kan föreskriva att din arbetsyta måste vara motståndskraftig mot datacenterfel eller regionala fel, eller så kan de föreskriva att du måste kunna återställa dina data till en ny arbetsyta i en redundansregion. Vart och ett av dessa scenarier kräver att ytterligare resurser och processer införs för att lyckas, så du bör noga överväga att balansera dina tillförlitlighetsmål med kostnader och komplexitet.
  • Välj rätt distributionsregioner för att uppfylla dina tillförlitlighetskrav. Distribuera din Log Analytics-arbetsyta och dina domänkontrollanter (datainsamlingsslutpunkter) tillsammans med arbetsbelastningskomponenterna som genererar driftdata. Ditt val av lämplig region där du ska distribuera din arbetsyta och dina domänkontrollanter bör informeras om var du distribuerar din arbetsbelastning. Du kan behöva väga den regionala tillgängligheten för vissa Log Analytics-funktioner, till exempel dedikerade kluster, mot andra faktorer som är mer centrala för arbetsbelastningens krav på tillförlitlighet, kostnad och prestanda.
  • Se till att dina observerbarhetssystem är felfria. Precis som med andra komponenter i din arbetsbelastning ska du se till att dina övervaknings- och loggningssystem fungerar korrekt. Det gör du genom att aktivera funktioner som skickar hälsodatasignaler till dina driftteam. Konfigurera hälsodatasignaler som är specifika för dina Log Analytics-arbetsytor och associerade resurser.

Konfigurationsrekommendationer för tillförlitlighet

Rekommendation Fördelar
Ta inte med dina Log Analytics-arbetsytor i arbetsbelastningens kritiska sökväg. Dina arbetsytor är viktiga för ett fungerande observerbarhetssystem, men funktionerna i din arbetsbelastning bör inte vara beroende av dem. Om du håller dina arbetsytor och associerade funktioner borta från arbetsbelastningens kritiska sökväg minimeras risken för problem som påverkar ditt observerbarhetssystem från att påverka körningen av din arbetsbelastning.
För att stödja hög hållbarhet för arbetsytedata distribuerar du Log Analytics-arbetsytor till en region som stöder dataresiliens. Dataresiliens är endast möjligt genom länkning av arbetsytan till ett dedikerat kluster i samma region. När du använder ett dedikerat kluster kan du sprida de associerade arbetsytorna mellan tillgänglighetszoner, vilket ger skydd mot datacenteravbrott. Om du inte samlar in tillräckligt med data nu för att motivera ett dedikerat kluster stöder det här förebyggande regionala valet framtida tillväxt.
Välj distributionen av arbetsytan baserat på närheten till din arbetsbelastning.

Använd datainsamlingsslutpunkter (DCE) i samma region som Log Analytics-arbetsytan.		 Distribuera din arbetsyta i samma region som instanserna av din arbetsbelastning. Att ha din arbetsyta och domänkontrollanter i samma region som din arbetsbelastning minskar risken för påverkan av avbrott i andra regioner.

Domänkontrollanter används av Azure Monitor-agenten och LOGS Ingestion API för att skicka arbetsbelastningsdriftsdata till en Log Analytics-arbetsyta. Du kan behöva flera domänkontrollanter även om distributionen bara har en enda arbetsyta. Mer information om hur du konfigurerar domänkontrollanter för din miljö finns i Så här konfigurerar du slutpunkter för datainsamling baserat på distributionen.<Br
Om din arbetsbelastning distribueras i en aktiv-aktiv design bör du överväga att använda flera arbetsytor och domänkontrollanter spridda över de regioner där din arbetsbelastning distribueras.

Om du distribuerar arbetsytor i flera regioner blir din miljö mer komplex. Balansera kriterierna som beskrivs i Utforma en Log Analytics-arbetsytearkitektur med dina tillgänglighetskrav.
Om du kräver att arbetsytan ska vara tillgänglig i ett regionfel, eller om du inte samlar in tillräckligt med data för ett dedikerat kluster, konfigurerar du datainsamling för att skicka kritiska data till flera arbetsytor i olika regioner. Den här metoden kallas även för logg multicasting.

Konfigurera till exempel DCR för flera arbetsytor för Azure Monitor-agenten som körs på virtuella datorer. Konfigurera flera diagnostikinställningar för att samla in resursloggar från Azure-resurser och skicka loggarna till flera arbetsytor.
På så sätt är driftdata för arbetsbelastningar tillgängliga på den alternativa arbetsytan om det uppstår ett regionalt fel. Men tänk på att resurser som förlitar sig på data som aviseringar och arbetsböcker inte automatiskt replikeras till de andra regionerna. Överväg att lagra ARM-mallar (Azure Resource Manager) för kritiska aviseringsresurser med konfiguration för den alternativa arbetsytan eller distribuera dem i alla regioner, men inaktivera dem för att förhindra redundanta aviseringar. Båda alternativen stöder snabb aktivering i ett regionalt fel.

Kompromiss: Den här konfigurationen resulterar i dubbla inmatnings- och kvarhållningsavgifter så att du bara använder den för kritiska data.
Om du kräver att data skyddas i ett datacenter eller regionfel konfigurerar du dataexport från arbetsytan för att spara data på en annan plats.

Det här alternativet liknar det tidigare alternativet för multicasting av data till olika arbetsytor. Men det här alternativet kostar mindre eftersom extra data skrivs till lagring.

Använd redundansalternativ för Azure Storage, inklusive geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS), för att replikera dessa data ytterligare till andra regioner.

Dataexport ger inte återhämtning mot incidenter som påverkar den regionala inmatningspipelinen.		 Även om historiska driftloggdata kanske inte är lätt att köra frågor mot i exporterat tillstånd, säkerställer det att data överlever ett långvarigt regionalt avbrott och kan nås och behållas under en längre period.

Om du behöver exportera tabeller som inte stöds av dataexport kan du använda andra metoder för att exportera data, inklusive Logic Apps, för att skydda dina data.

För att den här strategin ska fungera som en fungerande återställningsplan måste du ha processer för att konfigurera om diagnostikinställningar för dina resurser i Azure och för alla agenter som tillhandahåller data. Du måste också planera att manuellt extrahera dina exporterade data till en ny arbetsyta. Precis som med det tidigare beskrivna alternativet måste du också definiera processer för de resurser som förlitar sig på data som aviseringar och arbetsböcker.
För verksamhetskritiska arbetsbelastningar som kräver hög tillgänglighet bör du överväga att implementera en federerad arbetsytemodell som använder flera arbetsytor för att ge hög tillgänglighet om det uppstår ett regionalt fel. Verksamhetskritisk ger vägledning om förebyggande metodtips för att utforma mycket tillförlitliga program i Azure. Designmetoden innehåller en federerad arbetsytemodell med flera Log Analytics-arbetsytor för att leverera hög tillgänglighet om det uppstår flera fel, inklusive fel i en Azure-region.

Den här strategin eliminerar utgående kostnader mellan regioner och förblir i drift med ett regionfel. Men det kräver mer komplexitet som du måste hantera med konfiguration och processer som beskrivs i Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure.
Använd infrastruktur som kod (IaC) för att distribuera och hantera dina arbetsytor och tillhörande funktioner. När du automatiserar så mycket som möjligt av distributionen och dina mekanismer för återhämtning och återställning så praktiskt som möjligt säkerställer det att dessa åtgärder är tillförlitliga. Du sparar kritisk tid i dina driftsprocesser och minimerar risken för mänskliga fel.

Se till att funktioner som sparade loggfrågor också definieras via din IaC för att återställa dem till en ny region om återställning krävs.
Utforma DCR:er med en enda ansvarsprincip för att hålla DCR-regler enkla.

Även om en domänkontrollant kan läsas in med alla indata, regler och mål för källsystemen är det bättre att utforma snävt fokuserade regler som förlitar sig på färre datakällor. Använd sammansättningen av regeltilldelningar för att komma fram till önskat observerbarhetsomfång för det logiska målet.

Minimera även omvandlingen i DCR:erna		 När du använder snävt fokuserade DCR:er minimerar det risken för att en regelfelkonfigurering får en bredare effekt. Den begränsar effekten till endast det omfång för vilket DCR skapades. Mer information finns i Metodtips för att skapa och hantera datainsamlingsregler i Azure Monitor.

Transformeringen kan vara kraftfull och nödvändig i vissa situationer, men det kan vara svårt att testa och felsöka det KQL-arbete (keyword query language) som utförs. När det är möjligt minimerar du risken för dataförlust genom att mata in rådata och hantera transformeringar nedströms vid frågetillfället.
När du anger ett dagligt tak eller en kvarhållningsprincip ska du se till att du upprätthåller dina tillförlitlighetskrav genom att mata in och behålla de loggar som du behöver. Ett dagligt tak stoppar insamlingen av data för en arbetsyta när en angiven mängd har uppnåtts, vilket hjälper dig att behålla kontrollen över inmatningsvolymen. Men använd bara den här funktionen efter noggrann planering. Se till att ditt dagliga tak inte drabbas av regelbundenhet. Om det händer anges ditt tak för restriktivt. Du måste konfigurera om det dagliga taket så att du inte missar kritiska signaler som kommer från din arbetsbelastning.

På samma sätt bör du noggrant och eftertänksamt närma dig sänkningen av din datakvarhållningsprincip för att säkerställa att du inte oavsiktligt förlorar kritiska data.
Använd Log Analytics-arbetsyteinsikter för att spåra inmatningsvolymer, mata in data jämfört med datataket, loggkällor som inte svarar och misslyckade frågor bland andra data. Skapa hälsostatusaviseringar för att proaktivt meddela dig om en arbetsyta blir otillgänglig på grund av ett datacenter eller ett regionalt fel. Den här strategin säkerställer att du kan övervaka hälsotillståndet för dina arbetsytor och proaktivt agera om hälsan riskerar att försämras. Precis som alla andra komponenter i din arbetsbelastning är det viktigt att du är medveten om hälsomått och kan identifiera trender för att förbättra din tillförlitlighet över tid.

Azure Policy

Azure erbjuder inga principer som rör tillförlitlighet för Log Analytics-arbetsytor. Du kan skapa anpassade principer för att skapa efterlevnadsskydd runt dina arbetsytedistributioner, till exempel se till att arbetsytor är kopplade till ett dedikerat kluster.

Även om det inte är direkt relaterat till tillförlitligheten för Log Analytics-arbetsytor finns det Azure-principer för nästan alla tillgängliga tjänster. Principerna säkerställer att diagnostikinställningar är aktiverade för den tjänsten och verifierar att tjänstens loggdata flödar till en Log Analytics-arbetsyta. Alla tjänster i arbetsbelastningsarkitekturen bör skicka sina loggdata till en Log Analytics-arbetsyta för sina egna tillförlitlighetsbehov, och principerna kan hjälpa till att framtvinga dem. På samma sätt finns principer för att säkerställa att agentbaserade plattformar, till exempel virtuella datorer och Kubernetes, har agenten installerad.

Azure Advisor

Azure erbjuder inga Azure Advisor-rekommendationer som rör tillförlitligheten för Log Analytics-arbetsytor.

Säkerhet

Syftet med säkerhetspelare är att tillhandahålla konfidentialitet, integritet och tillgänglighetsgarantier för arbetsbelastningen.

Principerna för säkerhetsdesign ger en övergripande designstrategi för att uppnå dessa mål genom att tillämpa metoder för den tekniska designen kring din övervaknings- och loggningslösning.

Checklista för design för säkerhet

Starta din designstrategi baserat på checklistan för designgranskning för Säkerhet och identifiera säkerhetsrisker och kontroller för att förbättra säkerhetsstatusen. Utöka strategin till att omfatta fler metoder efter behov.

  • Gå igenom avsnittet Azure Monitor-säkerhetsbaslinje och Hantera åtkomst till Log Analytics-arbetsytor . De här avsnitten innehåller vägledning om metodtips för säkerhet.
  • Distribuera dina arbetsytor med segmentering som en hörnstensprincip. Implementera segmentering på nätverk, data och åtkomstnivåer. Segmentering säkerställer att dina arbetsytor isoleras i lämplig grad och skyddas bättre från obehörig åtkomst till högsta möjliga grad, samtidigt som du uppfyller dina affärskrav för tillförlitlighet, kostnadsoptimering, driftseffektivitet och prestandaeffektivitet.
  • Se till att du kan granska läs- och skrivåtgärder för arbetsytan och associerade identiteter. Angripare kan dra nytta av att visa driftloggar. En komprometterad identitet kan leda till logginmatningsattacker. Aktivera granskning av åtgärder som körs från Azure-portalen eller via API-interaktioner och associerade användare. Om du inte har konfigurerats för att granska din arbetsyta kan det innebära att din organisation riskerar att bryta mot efterlevnadskraven.
  • Implementera robusta nätverkskontroller. Hjälper till att skydda nätverksåtkomsten till din arbetsyta och dina loggar via nätverksisolering och brandväggsfunktioner. Otillräckligt konfigurerade nätverkskontroller kan innebära att du riskerar att kommas åt av obehöriga eller skadliga aktörer.
  • Fastställ vilka typer av data som behöver oföränderlighet eller långsiktig kvarhållning. Dina loggdata bör behandlas med samma stränghet som arbetsbelastningsdata i produktionssystem. Inkludera loggdata i dina dataklassificeringsmetoder för att säkerställa att du lagrar känsliga loggdata enligt dess efterlevnadskrav.
  • Skydda vilande loggdata via kryptering. Enbart segmentering skyddar inte helt sekretessen för dina loggdata. Om obehörig rå åtkomst inträffar kan loggdata krypteras i vila förhindra att dåliga aktörer använder dessa data utanför arbetsytan.
  • Skydda känsliga loggdata genom fördunkling. Precis som arbetsbelastningsdata som finns i produktionssystem måste du vidta extra åtgärder för att säkerställa att konfidentialiteten bevaras för känslig information som avsiktligt eller oavsiktligt finns i driftloggar. När du använder fördunklingsmetoder hjälper det dig att dölja känsliga loggdata från obehöriga ögon.

Konfigurationsrekommendationer för säkerhet

Rekommendation Fördelar
Använd kundhanterade nycklar om du behöver en egen krypteringsnyckel för att skydda data och sparade frågor på dina arbetsytor.

Azure Monitor ser till att alla data och sparade frågor krypteras i vila med hjälp av Microsoft-hanterade nycklar (MMK). Om du behöver en egen krypteringsnyckel och samlar in tillräckligt med data för ett dedikerat kluster använder du kundhanterad nyckel. Du kan kryptera data med hjälp av din egen nyckel i Azure Key Vault, för kontroll över nyckellivscykeln och möjlighet att återkalla åtkomsten till dina data.

Om du använder Microsoft Sentinel kontrollerar du att du är bekant med övervägandena i Konfigurera kundhanterad nyckel för Microsoft Sentinel.		 Med den här strategin kan du kryptera data med hjälp av din egen nyckel i Azure Key Vault, för kontroll över nyckellivscykeln och möjlighet att återkalla åtkomsten till dina data.
Konfigurera loggfrågegranskning för att spåra vilka användare som kör frågor.

Konfigurera granskningsloggarna för varje arbetsyta så att de skickas till den lokala arbetsytan eller konsolidera i en dedikerad säkerhetsarbetsyta om du separerar dina drift- och säkerhetsdata. Använd Log Analytics-arbetsyteinsikter för att regelbundet granska dessa data. Överväg att skapa aviseringsregler för loggfrågor för att proaktivt meddela dig om obehöriga användare försöker köra frågor.		 Loggfrågegranskning registrerar information om varje fråga som körs på en arbetsyta. Behandla dessa granskningsdata som säkerhetsdata och skydda LAQueryLogs-tabellen på lämpligt sätt. Den här strategin stärker din säkerhetsstatus genom att hjälpa till att säkerställa att obehörig åtkomst fångas omedelbart om det någonsin händer.
Skydda din arbetsyta med hjälp av mått för privata nätverk och segmentering.

Använd funktionen private link för att begränsa kommunikationen mellan loggkällor och dina arbetsytor till privata nätverk.		 När du använder privat länk kan du också styra vilka virtuella nätverk som kan komma åt en viss arbetsyta, vilket ytterligare stärker säkerheten genom segmentering.
Använd Microsoft Entra ID i stället för API-nycklar för åtkomst till arbetsytans API där det är tillgängligt. Api-nyckelbaserad åtkomst till fråge-API :erna lämnar inte en spårningslogg per klient. Använd tillräckligt begränsad Entra ID-baserad åtkomst så att du kan granska programmatisk åtkomst korrekt.
Konfigurera åtkomst för olika typer av data på arbetsytan som krävs för olika roller i din organisation.

Ange åtkomstkontrollläget för arbetsytan till Använd resurs- eller arbetsytebehörigheter. Med den här åtkomstkontrollen kan resursägare använda resurskontext för att komma åt sina data utan att beviljas uttrycklig åtkomst till arbetsytan.

Använd RBAC på tabellnivå för användare som behöver åtkomst till en uppsättning tabeller över flera resurser.		 Den här inställningen förenklar konfigurationen av arbetsytan och hjälper till att säkerställa att användarna inte kan komma åt driftdata som de inte ska ha.

Tilldela lämplig inbyggd roll för att bevilja arbetsytebehörigheter till administratörer på prenumerations-, resursgrupps- eller arbetsytenivå beroende på deras ansvarsområde.

Användare med tabellbehörigheter har åtkomst till alla data i tabellen oavsett deras resursbehörigheter.

Mer information om de olika alternativen för att bevilja åtkomst till data på arbetsytan finns i Hantera åtkomst till Log Analytics-arbetsytor .
Exportera loggar som kräver långsiktig kvarhållning eller oföränderlighet.

Använd dataexport för att skicka data till ett Azure Storage-konto med oföränderliga principer för att skydda mot datamanipulering. Alla typer av loggar har inte samma relevans för efterlevnad, granskning eller säkerhet, så bestäm vilka datatyper som ska exporteras.		 Du kan samla in granskningsdata på din arbetsyta som omfattas av regler som kräver långsiktig kvarhållning. Data på en Log Analytics-arbetsyta kan inte ändras, men de kan rensas. När du exporterar en kopia av driftdata i kvarhållningssyfte kan du skapa en lösning som uppfyller dina efterlevnadskrav.
Fastställ en strategi för att filtrera eller dölja känsliga data på din arbetsyta.

Du kanske samlar in data som innehåller känslig information. Filtrera poster som inte ska samlas in med hjälp av konfigurationen för den specifika datakällan. Använd en transformering om endast vissa kolumner i data ska tas bort eller döljas.

Om du har standarder som kräver att ursprungliga data är oförändrade kan du använda " h"-literalen i KQL-frågor för att dölja frågeresultat som visas i arbetsböcker.		 Genom att dölja eller filtrera bort känsliga data på arbetsytan ser du till att du bevarar konfidentialiteten för känslig information. I många fall avgör efterlevnadskraven hur du kan hantera känslig information. Den här strategin hjälper dig att uppfylla kraven proaktivt.

Azure Policy

Azure erbjuder principer som rör säkerheten för Log Analytics-arbetsytor för att upprätthålla din önskade säkerhetsstatus. Exempel på sådana principer är:

Azure erbjuder också många principer som hjälper dig att framtvinga konfiguration av privata länkar, till exempel Log Analytics-arbetsytor bör blockera logginmatning och frågor från offentliga nätverk eller till och med konfigurera lösningen via DINE-principer, till exempel Konfigurera Azure Monitor Private Link Omfång för att använda privata DNS-zoner.

Azure Advisor

Azure erbjuder inga Azure Advisor-rekommendationer som rör säkerheten för Log Analytics-arbetsytor.

Kostnadsoptimering

Kostnadsoptimering fokuserar på att identifiera utgiftsmönster, prioritera investeringar inom kritiska områden och optimera i andra för att uppfylla organisationens budget samtidigt som affärskraven uppfylls.

Designprinciperna för kostnadsoptimering ger en övergripande designstrategi för att uppnå dessa affärsmål. De hjälper dig också att göra avvägningar vid behov i den tekniska designen som rör din övervaknings- och loggningslösning.

Mer information om hur dataavgifter beräknas för dina Log Analytics-arbetsytor finns i Kostnadsberäkningar och alternativ för Azure Monitor-loggar.

Designchecklista för kostnadsoptimering

Starta din designstrategi baserat på checklistan för designgranskning för kostnadsoptimering för investeringar och finjustera designen så att arbetsbelastningen överensstämmer med den budget som allokerats för arbetsbelastningen. Din design bör använda rätt Azure-funktioner, övervaka investeringar och hitta möjligheter att optimera över tid.

  • Utföra kostnadsmodelleringsövningar. Dessa exercizes hjälper dig att förstå dina aktuella arbetsytekostnader och prognostisera dina kostnader i förhållande till arbetsytans tillväxt. Analysera dina tillväxttrender i din arbetsbelastning och se till att du förstår planerna för att utöka arbetsbelastningen så att du får en korrekt prognos för framtida driftskostnader.
  • Välj rätt faktureringsmodell. Använd din kostnadsmodell för att fastställa den bästa faktureringsmodellen för ditt scenario. Hur du använder dina arbetsytor för närvarande och hur du planerar att använda dem när din arbetsbelastning utvecklas avgör om en modell med betala per användning eller en åtagandenivå passar bäst för ditt scenario.

    Kom ihåg att du kan välja olika faktureringsmodeller för varje arbetsyta och du kan kombinera kostnader för arbetsytor i vissa fall, så att du kan vara detaljerad i din analys och ditt beslutsfattande.
  • Samla in precis rätt mängd loggdata. Utför regelbundet schemalagd analys av dina diagnostikinställningar på dina resurser, konfiguration av datainsamlingsregler och anpassad programkodloggning för att säkerställa att du inte samlar in onödiga loggdata.
  • Hantera icke-produktionsmiljöer på ett annat sätt än produktion. Granska dina icke-produktionsmiljöer för att se till att du har konfigurerat dina diagnostikinställningar och kvarhållningsprinciper på rätt sätt. Dessa kan ofta vara betydligt mindre robusta än produktion, särskilt för utvecklings-/test- eller sandbox-miljöer.

Konfigurationsrekommendationer för kostnadsoptimering

Rekommendation Fördelar
Konfigurera prisnivån för den mängd data som varje Log Analytics-arbetsyta vanligtvis samlar in. Som standard använder Log Analytics-arbetsytor betala per användning-priser utan minsta datavolym. Om du samlar in tillräckligt med data kan du minska kostnaderna avsevärt genom att använda en åtagandenivå, vilket gör att du kan checka in till ett dagligt minimum av data som samlas in i utbyte mot en lägre hastighet. Om du samlar in tillräckligt med data mellan arbetsytor i en enda region kan du länka dem till ett dedikerat kluster och kombinera deras insamlade volym med hjälp av klusterpriser.

Mer information om åtagandenivåer och vägledning om hur du fastställer vad som passar bäst för din användningsnivå finns i Kostnadsberäkningar och alternativ för Azure Monitor-loggar. Information om hur du visar uppskattade kostnader för din användning på olika prisnivåer finns i Användning och uppskattade kostnader.
Konfigurera datakvarhållning och arkivering. Det finns en avgift för att behålla data på en Log Analytics-arbetsyta utöver standardvärdet på 31 dagar. Det är 90 dagar om Microsoft Sentinel är aktiverat på arbetsytan och 90 dagar för Application Insights-data. Överväg dina särskilda krav för att ha data lättillgängliga för loggfrågor. Du kan avsevärt minska kostnaderna genom att konfigurera arkiverade loggar. Med arkiverade loggar kan du behålla data i upp till sju år och fortfarande komma åt dem ibland. Du kommer åt data med hjälp av sökjobb eller genom att återställa en uppsättning data till arbetsytan.
Om du använder Microsoft Sentinel för att analysera säkerhetsloggar bör du överväga att använda en separat arbetsyta för att lagra loggarna. När du använder en dedikerad arbetsyta för loggdata som din SIEM använder kan det hjälpa dig att kontrollera kostnaderna. De arbetsytor som Microsoft Sentinel använder omfattas av Prissättning för Microsoft Sentinel. Dina säkerhetskrav avgör vilka typer av loggar som krävs för att ingå i SIEM-lösningen. Du kanske kan utesluta driftloggar som debiteras enligt standardpriset för Log Analytics om de finns på en separat arbetsyta.
Konfigurera tabeller som används för felsökning, felsökning och granskning som grundläggande loggar. Tabeller i en Log Analytics-arbetsyta som konfigurerats för grundläggande loggar har en lägre inmatningskostnad i utbyte mot begränsade funktioner och en avgift för loggfrågor. Om du frågar dessa tabeller sällan och inte använder dem för aviseringar kan den här frågekostnaden mer än kompenseras av den minskade inmatningskostnaden.
Begränsa datainsamling från datakällor för arbetsytan. Den främsta faktorn för kostnaden för Azure Monitor är mängden data som du samlar in på Log Analytics-arbetsytan. Se till att du inte samlar in mer data än du behöver för att utvärdera hälsa och prestanda för dina tjänster och program. För varje resurs väljer du rätt kategorier för de diagnostikinställningar som du konfigurerar för att ange den mängd driftdata du behöver. Det hjälper dig att hantera din arbetsbelastning och inte hantera ignorerade data.

Det kan finnas en kompromiss mellan kostnaden och dina övervakningskrav. Du kanske till exempel kan identifiera ett prestandaproblem snabbare med en hög samplingsfrekvens, men du kanske vill ha en lägre samplingsfrekvens för att spara kostnader. De flesta miljöer har flera datakällor med olika typer av insamling, så du måste balansera dina specifika krav med dina kostnadsmål för var och en. Se Kostnadsoptimering i Azure Monitor för rekommendationer om hur du konfigurerar insamling för olika datakällor.
Analysera regelbundet arbetsytans användningsdata för att identifiera trender och avvikelser.

Använd Log Analytics-arbetsyteinsikter för att regelbundet granska mängden data som samlas in på din arbetsyta. Analysera datainsamling ytterligare med hjälp av metoder i Analysera användning på Log Analytics-arbetsytan för att avgöra om det finns andra konfigurationer som kan minska din användning ytterligare.		 Genom att hjälpa dig att förstå mängden data som samlas in av olika källor identifierar den avvikelser och uppåtgående trender i datainsamlingen som kan leda till överkostnader. Det här är viktigt när du lägger till en ny uppsättning datakällor i din arbetsbelastning. Om du till exempel lägger till en ny uppsättning virtuella datorer aktiverar du nya Azure-diagnostikinställningar på en tjänst eller ändrar loggnivåer i ditt program.
Skapa en avisering när datainsamlingen är hög. För att undvika oväntade fakturor bör du meddelas proaktivt när du upplever överdriven användning. Med aviseringen kan du åtgärda eventuella avvikelser innan faktureringsperioden är slut.
Överväg ett dagligt tak som ett förebyggande mått för att säkerställa att du inte överskrider en viss budget. Ett dagligt tak inaktiverar datainsamling på en Log Analytics-arbetsyta resten av dagen efter att den konfigurerade gränsen har nåtts. Använd inte den här metoden som en metod för att minska kostnaderna enligt beskrivningen i När du ska använda ett dagligt tak, utan i stället för att förhindra skenande inmatning på grund av felaktig konfiguration eller missbruk.

Om du anger ett dagligt tak skapar du en avisering när taket nås. Se till att även skapa en aviseringsregel när en viss procentandel nås. Du kan till exempel ange en aviseringsregel för när 90 procents kapacitet nås. Den här aviseringen ger dig möjlighet att undersöka och åtgärda orsaken till ökade data innan taket stänger av kritisk datainsamling från din arbetsbelastning.

Azure Policy

Azure erbjuder inga principer som rör kostnadsoptimering av Log Analytics-arbetsytor. Du kan skapa anpassade principer för att skapa efterlevnadsriktlinjer för dina arbetsytedistributioner, till exempel att se till att dina arbetsytor innehåller rätt kvarhållningsinställningar.

Azure Advisor

Azure Advisor ger rekommendationer för att flytta specifika tabeller på en arbetsyta till den billiga basic-loggdataplanen för tabeller som tar emot relativt hög inmatningsvolym. Förstå begränsningarna med hjälp av grundläggande loggar innan du växlar. Mer information finns i När ska jag använda grundläggande loggar?. Azure Advisor kan också rekommendera att du ändrar prisåtagandenivån för hela arbetsytan baserat på den totala användningsvolymen.

Driftseffektivitet

Operational Excellence fokuserar främst på procedurer för utvecklingsmetoder, observerbarhet och versionshantering.

Designprinciperna för driftseffektivitet ger en övergripande designstrategi för att uppnå dessa mål mot driftskraven för arbetsbelastningen.

Designchecklista för driftseffektivitet

Starta din designstrategi baserat på checklistan för designgranskning för driftseffektivitet för att definiera processer för observerbarhet, testning och distribution som är relaterade till Log Analytics-arbetsytor.

  • Använd infrastruktur som kod (IaC) för alla funktioner som är relaterade till din arbetsbelastnings Log Analytics-arbetsytor. Minimera risken för mänskliga fel som kan uppstå vid manuell administration och användning av logginsamlings-, inmatnings-, lagrings- och frågefunktioner, inklusive sparade frågor och frågepaket, genom att automatisera så många av dessa funktioner som möjligt via kod. Inkludera även aviseringar som rapporterar ändringar av hälsostatus och konfigurationen av diagnostikinställningar för resurser som skickar loggar till dina arbetsytor i din IaC-kod. Inkludera koden med din andra arbetsbelastningsrelaterade kod för att säkerställa att dina säkra distributionsmetoder upprätthålls för hanteringen av dina arbetsytor.
  • Se till att dina arbetsytor är felfria och att du får ett meddelande när problem uppstår. Precis som andra komponenter i din arbetsbelastning kan dina arbetsytor stöta på problem. Problemen kan kosta värdefull tid och resurser att felsöka och lösa och eventuellt lämna ditt team omedvetet om arbetsbelastningens status för produktion. Genom att proaktivt övervaka arbetsytor och åtgärda potentiella problem kan dina driftteam minimera den tid de ägnar åt att felsöka och åtgärda problem.
  • Separera din produktion från icke-produktionsarbetsbelastningar. Undvik onödig komplexitet som kan orsaka extra arbete för ett driftsteam genom att använda olika arbetsytor för din produktionsmiljö än de som används av icke-produktionsmiljöer. Data som kommer kan också leda till förvirring eftersom testaktiviteter kan verka vara händelser i produktion.
  • Föredrar inbyggda verktyg och funktioner framför lösningar som inte kommer från Microsoft Använd inbyggda verktyg för att utöka funktionerna i dina övervaknings- och loggningssystem. Du kan behöva införa ytterligare konfigurationer för att stödja krav som återställning eller datasuveränitet som inte är tillgängliga direkt med Log Analytics-arbetsytor. I dessa fall bör du, när det är praktiskt möjligt, använda inbyggda Azure- eller Microsoft-verktyg för att hålla det antal verktyg som din organisation måste stödja till ett minimum.
  • Behandla dina arbetsytor som statiska snarare än tillfälliga komponenter Precis som andra typer av datalager bör arbetsytor inte beaktas bland de tillfälliga komponenterna i din arbetsbelastning. I Well-Architected Framework prioriteras i allmänhet oföränderlig infrastruktur och möjligheten att snabbt och enkelt ersätta resurser i din arbetsbelastning som en del av dina distributioner. Men förlusten av arbetsytedata kan vara oåterkallelig och oåterkallelig. Därför lämnar du arbetsytor borta från distributionspaket som ersätter infrastrukturen under uppdateringar och utför endast uppgraderingar på plats på arbetsytorna.
  • Se till att driftpersonalen har tränats på Kusto-frågespråk utbilda personalen för att skapa eller ändra frågor vid behov. Om operatörerna inte kan skriva eller ändra frågor kan det bromsa kritisk felsökning eller andra funktioner eftersom operatörer måste förlita sig på att andra team ska kunna utföra det arbetet åt dem.

Konfigurationsrekommendationer för driftseffektivitet

Rekommendation Fördelar
Utforma en arbetsytestrategi som uppfyller dina affärsbehov.

Se Utforma en Log Analytics-arbetsytearkitektur för vägledning om hur du utformar en strategi för dina Log Analytics-arbetsytor. Ta med hur många som ska skapas och var de ska placeras.

Om du behöver din arbetsbelastning för att använda ett centraliserat plattformsteamserbjudande kontrollerar du att du anger all nödvändig driftåtkomst. Skapa även aviseringar för att säkerställa att arbetsbelastningens observerbarhetsbehov uppfylls.		 Ett enskilt eller minst minimalt antal arbetsytor maximerar din arbetsbelastnings driftseffektivitet. Den begränsar fördelningen av drift- och säkerhetsdata, ökar insynen i potentiella problem, gör mönster enklare att identifiera och minimerar dina underhållskrav.

Du kan ha krav för flera arbetsytor, till exempel flera klientorganisationer, eller så kan du behöva arbetsytor i flera regioner för att stödja dina tillgänglighetskrav. Se därför till att du har rätt processer för att hantera den här ökade komplexiteten.
Använd infrastruktur som kod (IaC) för att distribuera och hantera dina arbetsytor och tillhörande funktioner. Använd infrastruktur som kod (IaC) för att definiera information om dina arbetsytor i ARM-mallar, Azure BICEP eller Terraform. Det gör att du kan använda dina befintliga DevOps-processer för att distribuera nya arbetsytor och Azure Policy för att framtvinga deras konfiguration.

Genom att samplacera all IaC-kod med programkoden ser du till att dina säkra distributionsmetoder upprätthålls för alla distributioner.
Använd Log Analytics-arbetsyteinsikter för att spåra hälsotillståndet och prestandan för dina Log Analytics-arbetsytor och skapa meningsfulla och användbara aviseringar för att meddelas proaktivt om driftsproblem.

Log Analytics-arbetsyteinsikter ger en enhetlig vy över användning, prestanda, hälsa, agenter, frågor och ändringslogg för alla dina arbetsytor.

Varje arbetsyta har en åtgärdstabell som loggar viktiga aktiviteter som påverkar arbetsytan.		 Granska den information som Log Analytics-insikter ger regelbundet för att spåra hälsotillståndet och driften för var och en av dina arbetsytor. När du använder den här informationen kan du skapa lättförståeade visualiseringar som instrumentpaneler eller rapporter som åtgärder och intressenter kan använda för att spåra hälsotillståndet för dina arbetsytor.

Skapa aviseringsregler baserat på den här tabellen för att meddelas proaktivt när ett driftproblem inträffar. Du kan använda rekommenderade aviseringar för arbetsytan för att förenkla hur du skapar de mest kritiska aviseringsreglerna.
Öva på kontinuerlig förbättring genom att ofta gå tillbaka till Azures diagnostikinställningar för dina resurser, regler för datainsamling och utförliga programloggar.

Se till att du optimerar din strategi för logginsamling med hjälp av frekventa granskningar av resursinställningarna. Ur driftssynpunkt kan du försöka minska bruset i loggarna genom att fokusera på de loggar som ger användbar information om en resurs hälsostatus.		 Genom att optimera på det här sättet gör du det möjligt för operatörer att undersöka och felsöka problem när de uppstår, eller utföra andra rutin-, improviserade eller akuta uppgifter.

När nya diagnostikkategorier görs tillgängliga för en resurstyp granskar du de typer av loggar som genereras med den här kategorin för att förstå om aktivering av dem kan hjälpa dig att optimera din insamlingsstrategi. En ny kategori kan till exempel vara en delmängd av en större uppsättning aktiviteter som samlas in. Med den nya delmängden kan du minska mängden loggar som kommer in genom att fokusera på de aktiviteter som är viktiga för dina åtgärder att spåra.

Azure Policy och Azure Advisor

Azure erbjuder inga principer eller Azure Advisor-rekommendationer som rör driftseffektiviteten för Log Analytics-arbetsytor.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att upprätthålla användarupplevelsen även när belastningen ökar genom att hantera kapaciteten. Strategin omfattar skalning av resurser, identifiering och optimering av potentiella flaskhalsar och optimering av prestandatoppar.

Designprinciperna för prestandaeffektivitet ger en övergripande designstrategi för att uppnå dessa kapacitetsmål mot den förväntade användningen.

Designchecklista för prestandaeffektivitet

Starta din designstrategi baserat på checklistan för designgranskning för prestandaeffektivitet för att definiera en baslinje för dina Log Analytics-arbetsytor och tillhörande funktioner.

  • Bekanta dig med grunderna för svarstid för loggdatainmatning i Azure Monitor. Det finns flera faktorer som bidrar till svarstiden vid inmatning av loggar till dina arbetsytor. Många av dessa faktorer är inbyggda i Azure Monitor-plattformen. Genom att förstå faktorerna och det normala svarstidsbeteendet kan du ställa in lämpliga förväntningar i dina team för arbetsbelastningsåtgärder.
  • Separera dina icke-produktions- och produktionsarbetsbelastningar. Produktionsspecifika arbetsytor minskar eventuella kostnader som icke-produktionssystem kan medföra. Det minskar arbetsytornas totala fotavtryck, vilket kräver färre resurser för att hantera loggdatabearbetning.
  • Välj rätt distributionsregioner för att uppfylla dina prestandakrav. Distribuera Log Analytics-arbetsytan och datainsamlingens slutpunkter (DCE) nära din arbetsbelastning. Valet av lämplig region där arbetsytan och domänkontrollanterna ska distribueras bör informeras om var du distribuerar arbetsbelastningen. Du kan behöva väga prestandafördelarna med att distribuera dina arbetsytor och domänkontrollanter i samma region som din arbetsbelastning mot dina tillförlitlighetskrav om du redan har distribuerat din arbetsbelastning till en region som inte stöder dessa krav för dina loggdata.

Konfigurationsrekommendationer för prestandaeffektivitet

Rekommendation Fördelar
Konfigurera loggfrågegranskning och använd Log Analytics-arbetsyteinsikter för att identifiera långsamma och ineffektiva frågor.

Loggfrågegranskning lagrar den beräkningstid som krävs för att köra varje fråga och tiden tills resultaten returneras. Log Analytics-arbetsyteinsikter använder dessa data för att lista potentiellt ineffektiva frågor på din arbetsyta. Överväg att skriva om de här frågorna för att förbättra deras prestanda. Se Optimera loggfrågor i Azure Monitor för vägledning om hur du optimerar dina loggfrågor.		 Optimerade frågor returnerar resultat snabbare och använder färre resurser på serverdelen, vilket gör även de processer som förlitar sig på dessa frågor mer effektiva.
Förstå tjänstbegränsningar för Log Analytics-arbetsytor.

I vissa implementeringar med hög trafik kan du stöta på tjänstbegränsningar som påverkar prestanda och din arbetsyta eller arbetsbelastningsdesign. Fråge-API:et begränsar till exempel antalet poster och datavolymer som returneras av en fråga. Logginmatnings-API:et begränsar storleken på varje API-anrop.

En fullständig lista över begränsningar och begränsningar för Azure Monitor- och Log Analytics-arbetsytor som är specifika för själva arbetsytan finns i Begränsningar för Azure Monitor-tjänsten.		 Genom att förstå de gränser som kan påverka arbetsytans prestanda kan du utforma på rätt sätt för att minimera dem. Du kan välja att använda flera arbetsytor för att undvika att nå gränser som är associerade med en enda arbetsyta.

Väg designbesluten för att minska tjänstbegränsningarna mot krav och mål för andra pelare.
Skapa domänkontrollanter som är specifika för datakällans typer i ett eller flera definierade omfång för observerbarhet. Skapa separata domänkontrollanter för prestanda och händelser för att optimera beräkningsanvändningen för serverdelsbearbetning. När du använder separata domänkontrollanter för prestanda och händelser hjälper det till att minska överbelastningen av serverdelsresurser. Genom att ha domänkontrollanter som kombinerar prestandahändelser tvingar den varje associerad virtuell dator att överföra, bearbeta och köra konfigurationer som kanske inte är tillämpliga enligt den installerade programvaran. En överdriven beräkningsresursförbrukning och fel vid bearbetning av en konfiguration kan inträffa och orsaka att Azure Monitor Agent (AMA) slutar svara.

Azure Policy och Azure Advisor

Azure erbjuder inga principer eller Azure Advisor-rekommendationer som rör prestanda för Log Analytics-arbetsytor.

Nästa steg