waarom CPU-belasting (meestal) geen kritische waarschuwing zou moeten zijn.

bij monitoring rijst vaak de vraag hoe waarschuwingsniveaus en escalaties moeten worden gedefinieerd en op welk niveau verschillende waarschuwingen moeten worden ingesteld op kritiek, fout of waarschuwing.

ervan uitgaande dat er fouten en kritische waarschuwingen zijn ingesteld om teams per pager/telefoon op de hoogte te stellen, en kritische waarschuwingen met een kortere escalatietijd, zijn hier enkele eenvoudige richtlijnen:

kritische waarschuwingen moeten zijn voor gebeurtenissen die een onmiddellijk effect hebben op de klant. Bijvoorbeeld, een productie virtuele IP op een bewaakte load balancer naar beneden, omdat het geen beschikbare diensten om het verkeer te routeren naar. De site is down, dus piep iedereen op.

foutmeldingen moeten betrekking hebben op gebeurtenissen die onmiddellijke aandacht vereisen en die, indien deze niet zijn opgelost, de kans vergroten dat een productie plaatsvindt die een gebeurtenis beïnvloedt. Om verder te gaan met het load balancer – voorbeeld, moet een fout worden geactiveerd als het virtuele IP slechts één werkende backend-server heeft om verkeer naar te leiden-er is nu geen redundantie, dus één storing kan de site offline halen.

waarschuwingen, die we meestal alleen per e-mail verzenden, zijn voor alle andere soorten gebeurtenissen. Het verlies van een enkele backend server van een virtueel IP wanneer er 20 andere servers functioneren garandeert niet dat iemand ‘ s nachts wakker wordt gemaakt.

bij het bepalen van het niveau waarop waarschuwingen worden toegewezen, moet rekening worden gehouden met de primaire functie van het apparaat. Bijvoorbeeld, in het geval van een NetApp storage array, de functie van het apparaat is om te dienen lezen en schrijven IO-Verzoeken. Dus het belangrijkste ding voor het toezicht op NetApps moet de beschikbaarheid en prestaties (latency) van deze lees-en schrijfverzoeken. Als een volume aanvragen met een hoge latency – zoals 70 ms per schrijfaanvraag-onderhoudt, moet dat een waarschuwing op Foutniveau zijn (in sommige bedrijven kan dat passend zijn om te configureren als een waarschuwing op kritiek niveau, maar meestal moet een waarschuwing op kritieke prestaties alleen worden geactiveerd als de prestaties van de eindtoepassing op onaanvaardbare wijze verslechteren.) Echter, als CPU belasting op de NetApp is 99% voor een periode, hoewel het klinkt alarmerend, ik stel voor dat worden behandeld als een waarschuwing niveau waarschuwing alleen. Als de latentie niet wordt beïnvloed, Waarom ‘ s nachts mensen wakker maken? Stuur een e-mailwaarschuwing zodat het probleem kan worden onderzocht, maar als de functie van het apparaat niet wordt aangetast, reageer dan niet te veel. (Als u wilt, kunt u uw waarschuwing escalaties, zodat dergelijke voorwaarden resulteren in pagina ‘ s als ongecorrigeerd of unaccknowledged voor meer dan 5 uur, zeggen.)

Alert Overload is een groter gevaar voor de meeste datacenters dan de meeste mensen zich realiseren. De gedachte is vaak: “als één waarschuwing goed is, moet meer beter zijn.”In plaats daarvan, richten op het identificeren van de primaire functies van apparaten – Stel Foutniveau waarschuwingen op die functies, en gebruik waarschuwingen om u te informeren over omstandigheden die kunnen afbreuk doen aan die functies, of om te helpen bij het oplossen van problemen. (Als de latency op een NetApp hoog is en de CPU-belasting ook alert is, helpt dat uiteraard om het probleem te diagnosticeren, in plaats van op zoek te gaan naar ongebruikelijke volume-activiteit.)

Reserve kritieke waarschuwingen voor systeemprestaties en beschikbaarheid als geheel.

met LogicMonitor hosted monitoring, hebben de waarschuwingsdefinities voor alle datacenter apparaten hun waarschuwingsdrempels vooraf gedefinieerd op de bovenstaande manier – dat is een van de manieren waarop we helpen bij het bieden van zinvolle monitoring in minuten.