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 några aspekter som måste beaktas, till exempel:
- Den typ av data som samlas in, även kallad datakällans typ (prestanda, händelser)
- De virtuella måldatorer som DCR är associerad 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 är också möjligt 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 DCR:er 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. Det 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 DCR:er 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 tvingas 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 domänkontrollanter som är specifika för målet är till hjälp vid hantering av datakrav för nationella data eller lagar. Eftersom efterlevnaden kan kräva att data endast skickas till tillåtna lagringsplatser som skapats i tillåtna regioner, kan olika domänkontrollanter ge bättre målmål för detaljerad information. | Om du inte separerar domänkontrollanter baserat på datamålet kan det leda till inkompatibilitet med datahantering, sekretess och åtkomstkrav. Det kan också leda till onödig datainsamling, vilket orsakar oväntade kostnader. |
De tidigare nämnda principerna 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.