Blogg

Få kontroll på er eventinsamling i Operations Manager

Det är vanligt förekommande att vi ser båda databaserna i SCOM fyllas upp av massiva mängder av onödig data - något som snabbt kan påverka prestandan negativt.

Låt oss titta lite närmare på vad som händer och vilka åtgärder vi kan genomföra för en renare och mer välmående miljö.

I sommar har jag haft nöjet att arbeta med en större hostingleverantör i norden där vi genomfört en hälsokontroll av en installation med närmare tiotusen övervakade servrar i SCOM.

När en miljö blir så pass stor så ser man direkt hur stor påverkan saker kan få när man konfigurerar den olika men också hur viktiga de allra minsta detaljera kan vara.

Så i denna första serie av insikter så tänkte jag dela med mig lite av min syn på insamling av events till System Center Operations Manager.

HUR FUNGERAR INSAMLINGEN

Datainsamling av events sker i majoritet till både databasen och data warehouse for Operations Manager.

Det går förvisso att ställa in att endera platserna bara skall användas för datalagring men de flesta så kallade Management Packs är konfigurerade att skriva till båda.

I den operationella databasen lagras events som standard i 7 dagar, medans den i långtidslagringen normalt sett stannar i 400 dagar.

Undantaget är dock för just events. Dessa lagras om inget ändrats i 100 dagar, vilket nog är mer än väl för det flesta.

Jag tycker att grundtanken är god och att informationen i viss mån kan användas vid felsökning. Men det är få gånger jag stött på att det faktiskt är fallet, särskilt när det kommer till att söka fram information som är äldre än en månad när det kommer till events.

HANDEN PÅ HJÄRTAT

Vad ska du använda information till? Missförstå mig inte, jag tycker definitivt att vissa saker skall samlas in så länge det finns en klar anledning till det, med ett tydligt syfte.

Om ett event verkligen är viktigt, bör det istället finnas ett larm konfigurerat med rätt prioritet.

Detta är också fallet i de flesta Management Packs, men trots detta så sker det en stor del insamling av events som få nyttjar.

Men är målet att samla in och analysera stora mängder loggar så finns det många verktyg som gör det jobbet klart mycket bättre.

HUR MYCKET PLATS KAN DET EGENTLIGEN TA?

I en miljö där det inte förekommer några fel så är troligtvis era databaser ganska små när det kommer till events.

Problemet är när en eller flera maskiner plötsligt börjar generera mängder med events som SCOM-miljön börjar samla in, detta kan gå fort beroende på hur många servrar det sker på.

Vi har sett fyra fall den senaste tiden där få servrar börjat samla in massiva mängder. I ett av fallen stod events för hela 84% av den totala storleken av Data Warehouse med närmare 800 miljoner insamlade events.

I detta fallet motsvarade det 1,7 TB med bara 30 dagars bibehållande av data, vilket mycket snabbt fyllde upp disk på kort tid.

Det kanske inte är världens största problem att ditt Data Warehouse växer då det enkelt går att utöka lagringen. Men ett större problem är det dock för den operationella databasen om den växer för mycket. Men varför är det då så?

En Operations Manager databas rekommenderas inte att växa över 50GB utnyttjat utrymme, på grund av prestandaskäl.

Trots detta har vi stött på flera fall när den vuxit över 300GB. Och där bara events stått för hela 50GB. Detta får en stor påverkan för operatörer och administratörer som upplever systemet som onödigt långsamt i kombination med att det genererar onödig skrivning till båda databaserna.

Kör ni dessutom en äldre SCOM 2012-installation så kan det också ligga mycket data kvar som aldrig försvinner. Detta var en bugg innan UR7 och mer information finns att läsa här.

VANLIGT FÖREKOMMANDE BOVAR

Ni har säkert identifierat flertalet Management Packs som samlar in events som inte har större värde. Några av de största bovarna vi stött på är bland annat:

  • WINDOWS SERVER OPERATING SYSTEM
    • Collection rule for unexpected service terminations
    • Collection rule for Service or Driver Failed to Start Events
  • SYSTEM CENTER OPERATIONS MANAGER
    • APM event collection Rule Rule
  • WINDOWS SERVER ACTIVE DIRECTORY FEDERATION SERVICES
    • Federation server events collection
  • MICROSOFT DYNAMICS AX
    • Flertalet regler som samlar in events

Det största problemet är kanske inte att just insamlingen sker utan att det i många fall är något man skulle behöva undersöka närmare. Tyvärr saknas det dock ofta rutiner för att kolla om en eller flera maskiner plötsligt genererar ovanligt många events om inget larm finns konfigurerat.

Vi själva använder vårt analysverktyg IT Service Analytics för att snabbt och enkelt lokalisera och åtgärda problemet i kombination med vår hälsokontrollsrapport.

 

ITSA_Event_Report

 

HUR KAN VI DÅ GÅ TILLVÄGA?

Det finns ett par enkla steg för att ta tillbaka kontrollen.

  • Minska insamlingstiden på events i den operationella databasen
  • Minska insamlingstiden på events i Data Warehouse
  • Inaktivera regler för insamling som inte är av relevans
  • Övervaka och för statistik över antalet events som samlas in

SAMMANFATTNING

Är målet att samla in och analysera stora mängder loggar så finns det bättre alternativ att vända sig till. Även fast Operations Manager är ett kraftfullt verktyg som klarar av flera olika delar så finns det ingen anledning att samla in onödig data som ingen tittar på. 

Så sätt en policy kring vilken data som är viktigt att samla in även om dessa inte genererar larm och håll koll på insamlingen. Justera gärna tiden den också sparas så att äldre data kan rensas bort.

Det kommer på sikt innebära att ni får en renare och mer responsiv miljö över åren.

MER INFORMATION

Ämnen: SCOM Operations Manager Data Warehouse Event Collection Tuning IT Service Analytics