Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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
Att ta hänsyn till 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 domänkontrollant kan associeras med mer än en virtuell måldator och en viss virtuell dator som är associerad med upp till 30 DCR:er, är det viktigt att du håller domänkontrollanterna 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 effektiv och anpassad till observerbarhetens omfång.
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 praxis | 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 behovet av samlingen är 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 DCR:er baserat på omfattning för observerbarhet är nyckeln till 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. | |
| Datalagringsplats | 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 destinationen är till hjälp vid hantering av krav på datasuveränitet eller lagar. Eftersom efterlevnad kan kräva att data endast skickas till tillåtna lagerplatser i tillåtna regioner, möjliggör olika efterlevnadsregioner bättre specificerad målinriktning av destinationer. | Om du inte separerar DCR:er baserat på destinationen för data kan det leda till bristande efterlevnad av krav på datahantering, sekretess och åtkomst. 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.