Dela via

Metodtips för Azure Monitor-loggar

Den här artikeln innehåller metodtips för arkitektur för Azure Monitor-loggar. Vägledningen baseras på de fem grundpelarna för arkitekturkvalitet som beskrivs i Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet avser möjligheten för ett system att återställa från fel och fortsätta att fungera. Målet är att minimera effekterna av en enskild komponent som misslyckas. Använd följande information för att minimera fel på dina Log Analytics-arbetsytor och för att skydda de data som de samlar in.

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 buffrar agenterna datan och försöker skicka loggarna igen i flera timmar.

Funktioner för Azure Monitor-loggar som förbättrar resiliensen

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.

Anmärkning

Du kan komma åt data i ett lagringskonto från Azure Monitor Logs 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 genom att använda 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

Replikering av arbetsytor ä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 helt och hållet, måste du övervaka hälsan hos din primära arbetsyta och bestämma när du ska byta 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. Tvärregional resiliens för arbetsplatsdata och tjänsteverksamheter.

Replikering av arbetsytor säkerställer hög tillgänglighet genom att skapa en sekundär instans av din arbetsyta i en annan region och att loggarna matas in i 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 importera loggar, analysera data, använda instrumentpaneler, varningar och Sentinel i din sekundära arbetsyta. 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. Regionell motståndskraft för arbetsytedata och tjänstdrift vid 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 regelefterlevnad för datalagring eftersom det kan vara svårt att analysera datan och återställa den 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 motståndskraft mot incidenter som påverkar den regionala inmatningskedjan.
Ö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

Egenskap Tjänsteresiliens Säkerhetskopiering av data Hög tillgänglighet Skyddsområde Inställningar 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 för varje 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.

Säkerhet

Säkerhet är en av de viktigaste aspekterna i alla arkitekturer. Azure Monitor tillhandahåller funktioner för att använda både principen om lägsta behörighet och skydd på djupet. Använd följande information för att maximera säkerheten för dina Log Analytics-arbetsytor och se till att endast behöriga användare får åtkomst till insamlade data.

Bevilja åtkomst till data på arbetsytan baserat på behov

  1. Ange åtkomstkontrollläget för arbetsytan till Använd resurs- eller arbetsytebehörighet för att tillåta resursägare att använda resurskontext för att komma åt sina data utan att beviljas explicit åtkomst till arbetsytan. Detta förenklar konfigurationen av arbetsytan och hjälper till att säkerställa att användarna bara har åtkomst till de data de behöver.
    Instruktioner: Hantera åtkomst till Log Analytics-arbetsytor
  2. Tilldela lämplig inbyggd roll för att bevilja arbetsytebehörigheter till administratörer på prenumerations-, resursgrupps- eller arbetsytenivå beroende på deras ansvarsområde.
    Instruktioner: Hantera åtkomst till Log Analytics-arbetsytor
  3. Tillämpa RBAC på tabellnivå för användare som behöver åtkomst till en uppsättning tabeller över flera resurser. Användare med tabellbehörigheter har åtkomst till alla data i tabellen oavsett deras resursbehörigheter.
    Instruktioner: Hantera åtkomst till Log Analytics-arbetsytor

Skydda loggdata under överföring

Om du använder agenter, anslutningsappar eller Logs-API:er för att fråga efter eller skicka data till din arbetsyta använder du TLS (Transport Layer Security) 1.2 eller senare för att säkerställa säkerheten för dina data under överföring. Äldre versioner av TLS och Secure Sockets Layer (SSL) har sårbarheter och även om de fortfarande kan fungera för att tillåta bakåtkompatibilitet rekommenderas de inte, och branschen har snabbt övergått till att överge stödet för dessa äldre protokoll.

PCI Security Standards Council fastställde en tidsfrist till den 30 juni 2018 för att inaktivera äldre versioner av TLS/SSL och uppgradera till säkrare protokoll. När Azure har upphört med äldre stöd kan klienter som inte kommunicerar helt via TLS 1.2 eller senare inte skicka eller fråga efter data till Azure Monitor-loggar.

Konfigurera inte uttryckligen dina agenter, dataanslutningsprogram eller API-program så att de endast använder TLS 1.2 om det inte behövs. Vi rekommenderar att de automatiskt identifierar, förhandlar och drar nytta av framtida säkerhetsstandarder. Annars kan du missa den extra säkerheten för de nyare standarderna och eventuellt uppleva problem om TLS 1.2 någonsin är inaktuell till förmån för dessa nyare standarder.

Viktigt!

I enlighet med azure wide legacy TLS-tillbakadragningen blockeras TLS 1.0/1.1-protokollet helt för Azure Monitor-loggar enligt datumen i följande tabell. För att tillhandahålla förstklassig kryptering använder Azure Monitor-loggarna redan TLS 1.2/1.3 som valfria krypteringsmekanismer.

Ikraftträdandedatum Fråga EFTER API-slutpunkter TLS-protokollversion
den 1 juli 2025 Loggar Fråga API-slutpunkter TLS 1.2 eller senare
den 1 mars 2026 Loggar inmatnings-API-slutpunkter TLS 1.2 eller senare

Rekommenderad åtgärd

Kontrollera att dina resurser som interagerar med Logs API-slutpunkter inte har några beroenden för TLS 1.0- eller 1.1-protokoll för att undvika eventuella avbrott i tjänsten.

Klienter som har konfigurerats för att arbeta med äldre servrar kan till exempel fortfarande använda TLS 1.0/1.1-protokoll för att starta ett TLS-handskakning. När klienten ansluter till Azure Monitor-loggar före TLS 1.2-tillämpningsdatumet tillåter Logs API-slutpunkten fortfarande den inledande TLS 1.0/1.1-anslutningen för klientens hälsning, men instruerar klienten att använda TLS 1.2 eller senare. Klienten kan sedan upprätta anslutningen på TLS 1.2/1.3, eller så avbryts anslutningen. Efter TLS 1.2-tillämpningsdatumet släpper Logs API-slutpunkten all trafik som inte är TLS 1.2 eller senare.

Allmänna frågor om det äldre TLS-problemet eller hur du testar chiffersviter som stöds finns i Lösa TLS-problem och Azure Resource Manager TLS-support.

Konfigurera loggfrågegranskning

  1. Konfigurera loggfrågegranskning för att registrera information om varje fråga som körs på en arbetsyta.
    Instruktioner: Revidera frågor i Azure Monitor-loggar
  2. Behandla loggfrågegranskningsdata som säkerhetsdata och säker åtkomst till LAQueryLogs-tabellen på lämpligt sätt.
    Instruktioner: Konfigurera åtkomst till data på arbetsytan baserat på behov.
  3. Om du separerar dina drift- och säkerhetsdata skickar du granskningsloggarna för varje arbetsyta till den lokala arbetsytan eller konsoliderar i en dedikerad säkerhetsarbetsyta.
    Instruktioner: Konfigurera åtkomst till data på arbetsytan baserat på behov.
  4. Använd Log Analytics-arbetsyteinsikter för att granska granskningsdata för loggfrågor med jämna mellanrum.
    Instruktioner: Log Analytics-arbetsyteinsikter.
  5. Skapa aviseringsregler för loggsökning för att meddela dig om obehöriga användare försöker köra frågor.
    Instruktioner: Aviseringsregler för loggsökning.

Säkerställa oföränderlighet för granskningsdata

Azure Monitor är en tilläggsbaserad dataplattform, men den innehåller bestämmelser för att ta bort data i efterlevnadssyfte. Så här skyddar du dina granskningsdata:

  1. Ange ett lås på Log Analytics-arbetsytan för att blockera alla aktiviteter som kan ta bort data, inklusive rensning, tabellborttagning och ändringar av datakvarhållning på tabell- eller arbetsyta. Tänk dock på att det här låset kan tas bort.
    Instruktioner: Lås dina resurser för att skydda infrastrukturen

  2. Om du behöver en helt manipulationssäker lösning rekommenderar vi att du exporterar dina data till en oföränderlig lagringslösning:

    1. Fastställ de specifika datatyper som ska exporteras. Alla loggtyper har inte samma relevans för efterlevnad, granskning eller säkerhet.
    2. Använd dataexport för att skicka data till ett Azure Storage-konto.
      Instruktioner: Dataexport för Log Analytics-arbetsyta i Azure Monitor
    3. Ange oföränderlighetsprinciper för att skydda mot datamanipulering.
      Instruktioner: Konfigurera oföränderlighetsprinciper för blobversioner

Filtrera eller dölja känsliga data på din arbetsyta

Om dina loggdata innehåller känslig information:

  1. Filtrera poster som inte ska samlas in med hjälp av konfigurationen för den specifika datakällan.
  2. Använd en transformering om endast vissa kolumner i data ska tas bort eller döljas.
    Instruktioner: Transformationer i Azure Monitor
  3. Om du har standarder som kräver att ursprungliga data är oförändrade använder du "h"-literalen i KQL-frågor för att dölja frågeresultat som visas i arbetsböcker.
    Instruktioner: Fördunklade strängliteraler

Rensa känsliga data som har samlats in av misstag

  1. Kontrollera regelbundet om det finns privata data som av misstag kan samlas in på din arbetsyta.
  2. Använd datarensning för att ta bort oönskade data. Observera att data i tabeller med Auxiliary plan för närvarande inte kan rensas.
    Instruktioner: Hantera personliga data i Azure Monitor-loggar och Application Insights

Azure Monitor krypterar alla vilande data och sparade frågor med hjälp av Microsoft-hanterade nycklar (MMK). Om du samlar in tillräckligt med data för ett dedikerat kluster länkar du din arbetsyta till ett dedikerat kluster för förbättrade säkerhetsfunktioner, inklusive:

  • Kundhanterade nycklar för större flexibilitet och nyckellivscykelkontroll. Om du använder Microsoft Sentinel kontrollerar du att du är bekant med övervägandena i Konfigurera kundhanterad nyckel för Microsoft Sentinel.
  • Customer Lockbox för Microsoft Azure för att granska och godkänna eller avvisa begäranden om åtkomst till kunddata. Customer Lockbox används när en Microsoft-tekniker behöver komma åt kunddata, oavsett om det är ett svar på ett kundinitierat supportärende eller ett problem som microsoft har identifierat. Låsbox kan för närvarande inte tillämpas på tabeller med Auxiliary plan.

Instruktioner: Skapa och hantera ett dedikerat kluster i Azure Monitor-loggar

Microsoft skyddar anslutningar till offentliga slutpunkter med kryptering från slutpunkt till slutpunkt. Om du behöver en privat slutpunkt använder du azure private link för att tillåta resurser att ansluta till din Log Analytics-arbetsyta via auktoriserade privata nätverk. Du kan också använda Privatlänk för att tvinga inmatning av arbetsytsdata via ExpressRoute eller en VPN.

Instruktioner: Utforma din Azure Private Link-konfiguration

Kostnadsoptimering

Kostnadsoptimering syftar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Du kan avsevärt minska kostnaderna för Azure Monitor genom att förstå dina olika konfigurationsalternativ och möjligheter att minska mängden data som samlas in. Se Kostnader och användning i Azure Monitor för att förstå de olika sätt som Azure Monitor debiterar och hur du visar din månadsfaktura.

Anmärkning

Se Optimera kostnader i Azure Monitor för kostnadsoptimeringsrekommendationer för alla funktioner i Azure Monitor.

Checklista för design

  • Ta reda på om du vill kombinera dina driftdata och säkerhetsdata på samma Log Analytics-arbetsyta.
  • Konfigurera prisnivån för mängden data som varje Log Analytics-arbetsyta vanligtvis samlar in.
  • Konfigurera datakvarhållning och arkivering.
  • Konfigurera tabeller som används för felsökning, problemlösning och granskning som basloggar.
  • Begränsa datainsamling från datakällor för arbetsytan.
  • Analysera regelbundet insamlade data för att identifiera trender och avvikelser.
  • Skapa en avisering när datainsamlingen är hög.
  • Överväg ett dagligt tak som ett förebyggande mått för att säkerställa att du inte överskrider en viss budget.
  • Konfigurera aviseringar om Kostnadsrekommendationer för Azure Advisor för Log Analytics-arbetsytor.

Konfigurationsrekommendationer

Rekommendation Förmån
Ta reda på om du vill kombinera dina driftdata och säkerhetsdata på samma Log Analytics-arbetsyta. Eftersom alla data på en Log Analytics-arbetsyta omfattas av Microsoft Sentinel-priser om Sentinel är aktiverat kan det finnas kostnadskonsekvenser för att kombinera dessa data. Mer information om hur du fattar det här beslutet för din miljö att balansera den med kriterier i andra pelare finns i Utforma en Log Analytics-arbetsytestrategi .
Konfigurera prisnivån för mängden 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 avsevärt minska kostnaden med hjälp av 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 ränta. 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.

Se Kostnadsberäkningar och alternativ för Azure Monitor-loggar för mer information om åtagandenivåer och vägledning för att avgöra vilken som passar bäst för din användningsnivå. Se Användning och uppskattade kostnader för att visa uppskattade kostnader för din användning på olika prisnivåer.
Konfigurera interaktiv och långsiktig datakvarhållning. Det kostar att behålla data på en Log Analytics-arbetsyta utöver standardvärdet 31 dagar (90 dagar om Sentinel är aktiverat på arbetsytan och 90 dagar för Application Insights-data). Överväg dina särskilda krav för att ha data som är lättillgängliga för loggfrågor. Du kan minska kostnaderna avsevärt genom att konfigurera långsiktig kvarhållning, vilket gör att du kan behålla data i upp till tolv år och fortfarande komma åt dem ibland med hjälp av sökjobb eller återställa en uppsättning data till arbetsytan.
Konfigurera tabeller som används för felsökning, problemlösning och granskning som basloggar. 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 gör förfrågningar på dessa tabeller sällan och inte använder dem för notiser, kan den här frågekostnaden mer än uppvägas av den minskade kostnaden för datainmatning.
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, så du bör se till att du inte samlar in fler data som du behöver för att utvärdera hälsotillståndet och prestandan för dina tjänster och program. Mer information om hur du fattar det här beslutet för din miljö som balanserar den med kriterier i andra pelare finns i Utforma en Log Analytics-arbetsytearkitektur .

Kompromiss: Det kan finnas en kompromiss mellan kostnaden och dina övervakningskrav. Du kanske till exempel kan identifiera ett prestandaproblem snabbare med en hög exempelfrekvens, men du kanske vill ha en lägre exempelfrekvens för att spara kostnader. De flesta miljöer har flera datakällor med olika typer av samling, 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 insamlade data 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. Förutom att hjälpa dig att förstå mängden data som samlas in av olika källor kommer den att identifiera avvikelser och uppåtgående trender i datainsamling som kan leda till överkostnader. Analysera datainsamling ytterligare med hjälp av metoder i Analysera användning i Log Analytics-arbetsytan för att avgöra om det finns ytterligare konfiguration som kan minska din användning ytterligare. Detta är särskilt viktigt när du lägger till en ny uppsättning datakällor, till exempel en ny uppsättning virtuella datorer eller registrerar en ny tjänst.
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 meddelandet kan du åtgärda eventuella avvikelser före faktureringsperiodens 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. Detta bör inte användas som en metod för att minska kostnaderna enligt beskrivningen i När du ska använda ett dagligt tak.

Om du anger ett dagligt tak ska du, förutom att skapa en avisering när taket nås, även skapa en aviseringsregel som ska meddelas när en viss procentandel har nåtts (till exempel 90 %). Detta ger dig möjlighet att undersöka och åtgärda orsaken till de ökade data innan taket stänger av datainsamlingen.
Konfigurera aviseringar om Kostnadsrekommendationer för Azure Advisor för Log Analytics-arbetsytor. Azure Advisor-rekommendationer för Log Analytics-arbetsytor varnar dig proaktivt när det finns en möjlighet att optimera dina kostnader. Skapa Azure Advisor-aviseringar för dessa kostnadsrekommendationer:
  • Överväg att konfigurera den kostnadseffektiva basic-loggplanen för valda tabeller – Vi har identifierat inmatning på mer än 1 GB per månad till tabeller som är berättigade till den lågkostnadsbaserade grundläggande loggdataplanen. Med den grundläggande loggplanen får du frågefunktioner för felsökning till en lägre kostnad.
  • Överväg att ändra prisnivå – Baserat på din aktuella användningsvolym undersöker du hur du ändrar prisnivån (åtagande) för att få rabatt och minska kostnaderna.
  • Överväg att ta bort oanvända återställda tabeller – Du har en eller flera tabeller med återställda data aktiva på din arbetsyta. Om du inte längre använder återställde data tar du bort tabellen för att undvika onödiga avgifter.
  • Datainmatningsavvikelse identifierades – Vi har identifierat en mycket högre inmatningshastighet under den senaste veckan, baserat på din inmatning under de tre föregående veckorna. Notera den här ändringen och den förväntade ändringen av dina kostnader.
Du kan också visa automatiskt genererade rekommendationer genom att välja Översiktsrekommendationer> eller Advisor-rekommendationer från resursmenyn för Log Analytics-arbetsytan.

Driftskvalitet

Driftskvalitet avser de driftsprocesser som krävs för att hålla en tjänst igång på ett tillförlitligt sätt i produktionen. Använd följande information för att minimera driftkraven för att stödja Log Analytics-arbetsytor.

Checklista för design

  • Utforma en arbetsytearkitektur med det minimala antalet arbetsytor som uppfyller dina affärsbehov.
  • Använd Infrastruktur som kod (IaC) när du hanterar flera arbetsytor.
  • Använd Log Analytics-arbetsyteinsikter för att spåra hälsotillstånd och prestanda för dina Log Analytics-arbetsytor.
  • Skapa aviseringsregler för att meddelas proaktivt om driftsproblem på arbetsytan.
  • Se till att du har en väldefinierad driftsprocess för datasegregering.

Konfigurationsrekommendationer

Rekommendation Förmån
Utforma en arbetsytestrategi för att uppfylla dina affärskrav. Se Designa en Log Analytics-arbetsytearkitektur för vägledning om hur du utformar en strategi för dina Log Analytics-arbetsytor, inklusive hur många som ska skapas och var de ska placeras.

Ett enskilt eller minst minimalt antal arbetsytor maximerar din driftseffektivitet eftersom det begränsar fördelningen av dina drifts- och säkerhetsdata, ökar din insyn i potentiella problem, gör mönster enklare att identifiera och minimera dina underhållsbehov.

Du kan ha krav för flera arbetsytor, till exempel flera klienter, eller så kan du behöva arbetsytor i flera regioner för att stödja dina tillgänglighetskrav. I dessa fall bör du se till att du har rätt processer för att hantera den här ökade komplexiteten.
Använd Infrastruktur som kod (IaC) när du hanterar flera arbetsytor. Använd Infrastruktur som kod (IaC) för att definiera information om dina arbetsytor i ARM, BICEP eller Terraform. På så sätt kan du använda dina befintliga DevOps-processer för att distribuera nya arbetsytor och Azure Policy för att framtvinga deras konfiguration.
Använd Log Analytics-arbetsyteinsikter för att spåra hälsotillstånd och prestanda för dina Log Analytics-arbetsytor. Log Analytics-arbetsyteinsikter ger en enhetlig vy över användning, prestanda, hälsa, agenter, frågor och ändringsloggar för alla dina arbetsytor. Granska den här informationen regelbundet för att spåra hälsotillståndet och driften för var och en av dina arbetsytor.
Skapa aviseringsregler för att meddelas proaktivt om driftsproblem på arbetsytan. Varje arbetsyta har en åtgärdstabell som loggar viktiga aktiviteter som påverkar arbetsytan. 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 skapandet av de mest kritiska aviseringsreglerna.
Se till att du har en väldefinierad driftsprocess för datasegregering. Du kan ha olika krav för olika typer av data som lagras på din arbetsyta. Se till att du tydligt förstår sådana krav som datakvarhållning och säkerhet när du utformar din arbetsytestrategi och konfigurerar inställningar som behörigheter och långsiktig kvarhållning. Du bör också ha en tydligt definierad process för att ibland rensa data med personlig information som samlas in av misstag.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att skala för att uppfylla användarnas krav på ett effektivt sätt. Använd följande information för att säkerställa att dina Log Analytics-arbetsytor och loggfrågor har konfigurerats för maximal prestanda.

Checklista för design

  • Konfigurera granskning av loggfrågor och använd Log Analytics-arbetsyteinsikter för att identifiera långsamma och ineffektiva frågor.

Konfigurationsrekommendationer

Rekommendation Förmån
Konfigurera granskning av loggfrågor 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 dessa frågor för att förbättra deras prestanda. Mer information om hur du optimerar dina loggfrågor finns i Optimera loggfrågor i Azure Monitor.

Nästa steg