de ce încărcarea procesorului nu ar trebui (de obicei) să fie o alertă critică.

o întrebare care apare adesea în monitorizare este cum să definiți nivelurile de alertă și escaladările și la ce nivel să setați diverse alerte – critice, de eroare sau de avertizare.

presupunând că aveți erori și alerte critice setate pentru a notifica echipele prin pager/telefon și alerte critice cu un timp de escaladare mai scurt, iată câteva instrucțiuni simple:

alertele critice ar trebui să fie pentru evenimente care au efect imediat asupra clientului. De exemplu, un IP Virtual de producție pe un echilibrator de sarcină monitorizat care coboară, deoarece nu are servicii disponibile pentru a direcționa traficul către. Site-ul este în jos, astfel încât pagina toată lumea.

alertele de eroare ar trebui să fie pentru evenimente care necesită atenție imediată și care, dacă sunt nerezolvate, cresc probabilitatea ca un eveniment care afectează producția să aibă loc. Pentru a continua cu exemplul load balancer, ar trebui declanșată o eroare dacă IP – ul Virtual are un singur server backend funcțional pentru a direcționa traficul către-Acum nu există redundanță, astfel încât un eșec poate duce site-ul offline.

avertismentele, pe care le recomandăm de obicei să fie trimise doar prin e-mail, sunt pentru toate celelalte tipuri de evenimente. Pierderea unui singur server backend de la un IP Virtual atunci când există 20 alte servere care funcționează nu garantează nimeni fiind trezit în noapte.

când decideți ce nivel să atribuiți alerte, luați în considerare funcția principală a dispozitivului. De exemplu, în cazul unei matrice de stocare NetApp, funcția dispozitivului este de a servi cererile IO de citire și scriere. Deci, principalul lucru pentru monitorizarea NetApps ar trebui să fie disponibilitatea și performanța (latența) acestor solicitări de citire și scriere. Dacă un volum deservește cererile cu latență ridicată – cum ar fi 70 ms pe cerere de scriere-aceasta ar trebui să fie o alertă de nivel de eroare (în unele întreprinderi, care poate fi adecvată pentru a configura ca alertă de nivel critic, dar de obicei o alertă de performanță critică ar trebui declanșată numai dacă performanța aplicației finale se degradează inacceptabil.) Cu toate acestea, dacă încărcarea procesorului pe NetApp este de 99% pentru o perioadă, chiar dacă sună alarmant, aș sugera să fie tratată doar ca o alertă de nivel de avertizare. Dacă latența nu este afectată, de ce să trezim oamenii noaptea? Trimiteți o alertă prin e-mail, astfel încât problema să poată fi investigată, dar dacă funcția dispozitivului nu este afectată, nu reacționați excesiv. (Dacă doriți, puteți defini escaladările de alertă, astfel încât astfel de condiții să conducă la pagini dacă sunt necorectate sau nerecunoscute mai mult de 5 ore, să zicem.)

supraîncărcarea alertelor este un pericol mai mare pentru majoritatea centrelor de date decât își dau seama majoritatea oamenilor. Gândul este adesea ” dacă o alertă este bună, mai mult trebuie să fie mai bine.”În schimb, concentrați – vă pe identificarea funcțiilor principale ale dispozitivelor-Setați alerte la nivel de eroare cu privire la aceste funcții și utilizați avertismente pentru a vă informa despre condițiile care ar putea afecta funcțiile respective sau pentru a ajuta la depanare. (Dacă latența pe un NetApp este mare, iar încărcarea procesorului este, de asemenea, în alertă, acest lucru ajută în mod evident la diagnosticarea problemei, în loc să caute o activitate neobișnuită a volumului.)

rezervați alerte critice pentru performanța și disponibilitatea sistemului în ansamblu.

cu LogicMonitor hosted monitoring, definițiile de alertă pentru toate dispozitivele centrelor de date au pragurile de alertă predefinite în modul de mai sus – acesta este un mod în care ajutăm la furnizarea unei monitorizări semnificative în câteva minute.