Metodtips för skapande och hantering av datainsamlingsregel i Azure Monitor

Regler för datainsamling (DCR) avgör hur du samlar in och bearbetar telemetri som skickas till Azure. Vissa regler för datainsamling skapas och hanteras av Azure Monitor, medan du kan skapa andra för att anpassa datainsamlingen efter dina specifika krav. I den här artikeln beskrivs några metodtips som bör tillämpas när du skapar egna domänkontrollanter.

När du skapar en DCR finns det vissa aspekter som måste beaktas, till exempel:

• Den typ av data som ska samlas in, även kallad datakällans typ (prestanda, händelser)
• De virtuella måldatorer som DCR ska associeras med
• Målet för insamlade data

Med tanke på alla dessa faktorer är avgörande för en bra DCR-organisation. Alla ovanstående punkter påverkar DCR-hanteringsarbetet samt resursförbrukningen för konfigurationsöverföring och bearbetning.

Med tanke på den inbyggda kornigheten, som gör att en viss DCR kan associeras med mer än en virtuell måldator och vice versa, är det viktigt att du håller DCR:erna så enkla som möjligt med färre datakällor vardera. Det är också viktigt att hålla listan över insamlade objekt i varje datakälla lean och orienterad mot observerbarhetsomfånget.

För att klargöra vad ett observerbarhetsomfång kan vara bör du tänka på det som din önskade logiska gräns för att samla in data. Ett möjligt omfång kan till exempel vara en uppsättning virtuella datorer som kör programvara (till exempel "SQL-servrar") som behövs för ett visst program, eller grundläggande operativsystemräknare eller händelser som används av IT-administratörerna. Det går också att skapa liknande omfång som är dedikerade till olika miljöer ("Utveckling", "Test", "Produktion") för att specialisera sig ännu mer.

I själva verket är det inte idealiskt och rekommenderas inte ens att skapa en enda DCR som innehåller alla datakällor, samlingsobjekt och mål för att implementera observerbarheten. I följande tabell finns det flera rekommendationer som kan hjälpa dig att bättre planera skapande och underhåll av DCR:

Kategori	Bästa metod	Förklaring	Påverkansområde
Datainsamling	Definiera observerbarhetsomfånget	Att definiera omfånget för observerbarhet är nyckeln till ett enklare och framgångsrikt dcr-hanterings- och organisationsobservabilitetsomfång. Det hjälper till att klargöra vad samlingen behöver och från vilken virtuell måldator den ska utföras. Som tidigare förklarats kan ett observerbarhetsomfång vara en uppsättning virtuella datorer som kör programvara som är gemensam för ett specifikt program, en uppsättning gemensam information för IT-avdelningen osv. Att till exempel samla in de grundläggande operativsystemets prestandaräknare, till exempel processoranvändning, tillgängligt minne och ledigt diskutrymme, kan ses som ett omfång för din centrala IT-hantering.	Att inte ha ett tydligt definierat omfång ger inte klarhet och tillåter inte en korrekt hantering.
	Skapa domänkontrollanter som är specifika för observerbarhetsomfånget	Att skapa separata domänkontrollanter baserat på observerbarhetsomfånget är nyckeln för enkelt underhåll. Det gör att du enkelt kan associera dcrs till relevanta virtuella måldatorer.	Varför ska vi skapa en enda domänkontrollant som samlar in operativsystemets prestandaräknare plus webbserverräknare och databasräknare tillsammans? Den här metoden tvingar inte bara varje associerad virtuell dator att överföra, bearbeta och köra konfiguration som ligger utanför omfånget, utan kräver också mer arbete när DCR-konfigurationen behöver uppdateras. Tänk på att hantera en mall som innehåller onödiga poster. den här situationen är mindre idealisk och lämnar utrymme för fel.
	Skapa DCR som är specifikt för datakällans typ i de definierade observerbarhetsomfången	Genom att skapa separata domänkontrollanter för prestanda och händelser kan du både hantera konfigurationen och associationen med kornighet baserat på måldatorerna. Om du till exempel skapar en DCR för att samla in både händelser och prestandaräknare kan det leda till en ooptimal metod. Det kan finnas situationer där en viss dator (eller en uppsättning datorer) inte har de händelseloggar eller prestandaräknare som konfigurerats i DCR. I det här fallet tvingas de virtuella datorerna att bearbeta och köra en konfiguration som inte är nödvändig enligt programvaran som är installerad på den.	Om du inte använder olika domänkontrollanter framtvingas 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 i bearbetningskonfigurationen kan inträffa, vilket kan orsaka att Azure Monitor Agent (AMA) inte svarar. Att samla in onödiga data ökar dessutom kostnaderna för datainmatning.
Datamål	Skapa en annan DCR baserat på målet	DCR:er har möjlighet att skicka data till flera olika mål, till exempel Azure Monitor Metrics och Azure Monitor-loggar, samtidigt. Att ha DCR(er) som är specifika för målet är till hjälp vid hantering av data nationella krav eller lagkrav. Eftersom efterlevnaden kan kräva att data endast skickas till tillåtna lagringsplatser som skapats i tillåtna regioner, kan olika domänkontrollanter ge en bättre detaljerad målinriktning	Om du inte separerar domänkontrollanter baserat på datamålet kan det leda till att datahanteringen, sekretessen och åtkomstkraven inte uppfylls och att onödig datainsamling resulterar i oväntade kostnader.

Ovan nämnda principer utgör en grund för att skapa en egen DCR-hanteringsmetod som balanserar underhållsbarhet, enkel återanvändning, kornighet och tjänstbegränsningar. DCR:er behöver också delad styrning för att minimera både skapandet av silor och onödig duplicering av arbete.

Nästa steg

• Läs mer om regler och alternativ för datainsamling för att skapa dem.