proč by zatížení CPU nemělo být (obvykle) kritickým upozorněním.

jednou z otázek, která často vyvstává při monitorování, je, jak definovat Úrovně výstrahy a eskalace a jakou úroveň nastavit různá upozornění – kritická, chybová nebo varovná.

za předpokladu, že máte chyby a kritická upozornění nastavená tak, aby upozorňovala týmy pagerem / telefonem, a kritická upozornění s kratší dobou eskalace, uvádíme několik jednoduchých pokynů:

kritická upozornění by měla být pro události, které mají okamžitý dopad na zákazníka. Například produkční virtuální IP na monitorovaném vyvažovači zatížení klesá, protože nemá k dispozici žádné služby pro směrování provozu. Stránka je nefunkční, tak pípněte všem.

upozornění na chyby by měla být u událostí, které vyžadují okamžitou pozornost, a které, pokud nejsou vyřešeny, zvyšují pravděpodobnost, že dojde k události ovlivňující produkci. Chcete – li pokračovat v příkladu vyvažovače zatížení, měla by být spuštěna chyba, pokud virtuální IP má pouze jeden funkční backend server pro směrování provozu-nyní neexistuje redundance, takže jedno selhání může Web offline.

varování, která obvykle doporučujeme zasílat pouze e-mailem, jsou určena pro všechny ostatní druhy událostí. Ztráta jednoho backendového serveru z virtuální IP, když existují 20 jiné servery fungující nezaručuje, že by se někdo probudil v noci.

při rozhodování o tom, jakou úroveň přiřadit upozornění, zvažte primární funkci zařízení. Například v případě úložného pole NetApp je funkcí zařízení sloužit čtení a zápisu požadavků IO. Primární věcí pro monitorování NetApps by tedy měla být dostupnost a výkon (latence) těchto požadavků na čtení a zápis. Pokud svazek obsluhuje požadavky s vysokou latencí-například 70 ms na žádost o zápis – mělo by to být upozornění na úrovni chyb (v některých podnicích může být vhodné nakonfigurovat jako upozornění na kritické úrovni, ale obvykle by mělo být spuštěno upozornění na kritický výkon pouze v případě, že se výkon koncové aplikace nepřijatelně zhorší.) Nicméně, pokud zatížení CPU na NetApp je 99% po dobu, i když to zní alarmující, já bych navrhnout, že být zacházeno jako upozornění na úrovni varování pouze. Pokud není ovlivněna latence, proč probudit lidi v noci? Pošlete e-mailové upozornění, aby problém mohl být vyšetřen, ale pokud není narušena funkce zařízení, nereagujte. (Pokud si přejete, můžete definovat eskalace výstrah tak, aby takové podmínky vedly k tomu, že stránky jsou neopravené nebo nepotvrzené déle než 5 hodin, řekněme.

výstražné přetížení představuje pro většinu datových center větší nebezpečí, než si většina lidí uvědomuje. Myšlenka je často ” pokud je jedno varování Dobré, více musí být lepší.”Místo toho se zaměřte na identifikaci primárních funkcí zařízení-nastavte upozornění na úroveň chyb na těchto funkcích a použijte varování, abyste vás informovali o podmínkách,které by mohly tyto funkce narušit, nebo na pomoc při odstraňování problémů. (Pokud je latence na NetApp vysoká a zatížení procesoru je také v pohotovosti, což samozřejmě pomáhá diagnostikovat problém, místo aby hledal neobvyklou aktivitu hlasitosti.)

rezervujte kritická upozornění pro výkon a dostupnost systému jako celku.

s monitorováním hostovaným Logicmonitorem mají definice výstrah pro všechna zařízení datových center své výstražné prahové hodnoty předdefinované výše uvedeným způsobem – to je jeden ze způsobů, jak pomoci zajistit smysluplné monitorování během několika minut.