varför CPU belastning bör inte (vanligtvis) vara en kritisk varning.

en fråga som ofta uppstår vid övervakning är hur man definierar varningsnivåer och eskaleringar och vilken nivå man ska ställa in olika varningar vid – kritisk, fel eller varning.

förutsatt att du har fel och kritiska varningar inställda för att meddela lag med personsökare/telefon och kritiska varningar med kortare eskaleringstid, här är några enkla riktlinjer:

kritiska varningar bör vara för händelser som har omedelbar kundpåverkan. Till exempel, en produktion virtuell IP på en övervakad lastbalanserare går ner, eftersom den inte har några tillgängliga tjänster att dirigera trafiken till. Webbplatsen är nere, så sida alla.

Felvarningar bör vara för händelser som kräver omedelbar uppmärksamhet och som, om de inte löses, ökar sannolikheten för att en produktion som påverkar händelsen kommer att inträffa. För att fortsätta med lastbalansexemplet bör ett fel utlösas om den virtuella IP – enheten bara har en fungerande backend-server för att dirigera trafik till-det finns nu ingen redundans, så ett fel kan ta webbplatsen offline.

varningar, som vi normalt rekommenderar skickas endast via e-post, är för alla andra typer av händelser. Förlusten av en enda backend-server från en virtuell IP när det finns 20 andra servrar som fungerar garanterar inte att någon vaknar på natten.

när du bestämmer vilken nivå som ska tilldela varningar, överväga enhetens primära funktion. Till exempel, i fallet med en NetApp-lagringsmatris, är enhetens funktion att betjäna läs-och skriv Io-förfrågningar. Så det primära för att övervaka NetApps bör vara tillgängligheten och prestanda (latens) för dessa läs-och skrivförfrågningar. Om en volym betjänar förfrågningar med hög latens – till exempel 70 ms per skrivbegäran – bör det vara en Felnivåvarning (i vissa företag kan det vara lämpligt att konfigurera som en kritisk nivåvarning, men vanligtvis bör en kritisk prestandavarning endast utlösas om slutprogrammets prestanda försämras oacceptabelt.) Men om CPU-belastningen på NetApp är 99% under en period, även om det låter alarmerande, föreslår jag att det bara behandlas som en Varningsnivåvarning. Om latensen inte påverkas, varför väcka människor på natten? Skicka ett e-postmeddelande så att problemet kan undersökas, men om enhetens funktion inte försämras, reagera inte över. (Om du vill kan du definiera dina varnings eskaleringar så att sådana förhållanden resulterar i sidor om okorrigerade eller obekräftade i mer än 5 timmar, säg.)

Alert överbelastning är en större fara för de flesta datacenter än de flesta inser. Tanken är ofta ” om en varning är bra, mer måste vara bättre.”Fokusera istället på att identifiera enhetens primära funktioner – Ställ in felnivåvarningar på dessa funktioner och använd varningar för att informera dig om förhållanden som kan försämra funktionerna eller för att hjälpa till vid felsökning. (Om latens på en NetApp är hög och CPU-belastningen också är i alert, hjälper det uppenbarligen att diagnostisera problemet istället för att leta efter ovanlig volymaktivitet.)

reservera kritiska varningar för systemprestanda och tillgänglighet som helhet.

med LogicMonitor hosted monitoring har varningsdefinitionerna för alla datacenterenheter fördefinierade på ovanstående sätt-det är ett sätt vi hjälper till att ge meningsfull övervakning på några minuter.