hvorfor CPU belastning bør ikke (normalt) være en kritisk alarm.

et spørgsmål, der ofte opstår i overvågningen, er, hvordan man definerer alarmniveauer og eskaleringer, og hvilket niveau der skal indstilles forskellige alarmer til – kritisk, fejl eller advarsel.

hvis du antager, at du har fejl og kritiske advarsler indstillet til at underrette teams via personsøger/telefon og kritiske advarsler med en kortere eskaleringstid, er her nogle enkle retningslinjer:

kritiske advarsler skal være til begivenheder, der har øjeblikkelig kundepåvirkende effekt. For eksempel en produktion virtuel IP på en overvåget belastningsbalancer går ned, da den ikke har nogen tilgængelige tjenester til at dirigere trafikken til. Sitet er nede, så Side alle.

Fejlvarsler skal være for begivenheder, der kræver øjeblikkelig opmærksomhed, og som, hvis de ikke er løst, øger sandsynligheden for, at en produktion, der påvirker begivenheden, vil forekomme. For at fortsætte med load balancer – eksemplet skal der udløses en fejl, hvis den virtuelle IP kun har en fungerende backend-server til at dirigere trafik til-der er nu ingen redundans, så en fejl kan tage siden offline.

advarsler, som vi typisk anbefaler kun sendes via e-mail, er til alle andre slags begivenheder. Tabet af en enkelt backend-server fra en virtuel IP, når der er 20 andre servere, der fungerer, garanterer ikke, at nogen bliver vågnet om natten.

når du beslutter, hvilket niveau der skal tildeles alarmer, skal du overveje enhedens primære funktion. For eksempel, i tilfælde af et NetApp-lagringsarray, er enhedens funktion at tjene læse og skrive io-anmodninger. Så den primære ting til overvågning af NetApps bør være tilgængeligheden og ydeevnen (latenstid) af disse læse-og skriveanmodninger. 70 ms pr. skriveanmodning-bør det være en Fejlniveaualarm (i nogle virksomheder kan det være hensigtsmæssigt at konfigurere som en kritisk niveaualarm, men normalt bør en kritisk præstationsalarm kun udløses, hvis slutapplikationsydelsen forringes uacceptabelt.) Men hvis CPU-belastningen på NetApp er 99% i en periode, selvom det lyder alarmerende, vil jeg foreslå, at det kun behandles som en Advarselsniveaualarm. Hvis latens ikke påvirkes, hvorfor vække folk om natten? Send en e-mail-alarm, så problemet kan undersøges, men hvis enhedens funktion ikke forringes, skal du ikke reagere for meget. (Hvis du ønsker det, kan du definere dine advarselsoptrapninger, så sådanne forhold resulterer i sider, hvis de ikke er korrigeret eller ikke anerkendt i mere end 5 timer, siger.)

Alarmoverbelastning er en større fare for de fleste datacentre, end de fleste mennesker er klar over. Tanken er ofte ” hvis en advarsel er god, skal mere være bedre.”Fokuser i stedet på at identificere de primære funktioner i enheder – Indstil fejlniveauadvarsler på disse funktioner, og brug advarsler til at informere dig om forhold, der kan forringe disse funktioner, eller til at hjælpe med fejlfinding. (Hvis latenstiden på en NetApp er høj, og CPU-belastningen også er i alarm, hjælper det naturligvis med at diagnosticere problemet i stedet for at lede efter usædvanlig volumenaktivitet.)

reserver kritiske advarsler for systemets ydeevne og tilgængelighed som helhed.

med logicmonitor – hosted overvågning har alarmdefinitionerne for alle datacenterenheder deres alarmtærskler foruddefineret på ovenstående måde-det er en måde, vi hjælper med at give meningsfuld overvågning på få minutter.