miért nem (általában) kritikus figyelmeztetés A CPU terhelése.

a megfigyelés során gyakran felmerül az a kérdés, hogy hogyan lehet meghatározni a riasztási szinteket és az eszkalációkat, és milyen szinten kell beállítani a különféle riasztásokat – kritikus, hiba vagy figyelmeztetés.

feltételezve, hogy hibák és kritikus riasztások vannak beállítva a csapatok személyhívó / telefon általi értesítésére, valamint a rövidebb eszkalációs idővel rendelkező kritikus riasztások, íme néhány egyszerű útmutató:

a kritikus riasztásoknak olyan eseményekre kell vonatkozniuk, amelyek azonnali ügyfélhatást gyakorolnak. Például egy megfigyelt terheléselosztó termelési virtuális IP-je lefelé megy, mivel nincs elérhető szolgáltatása a forgalom irányításához. Az oldal nem működik, tehát mindenkit oldalzzon.

a Hibajelzéseknek olyan eseményekre kell vonatkozniuk, amelyek azonnali figyelmet igényelnek, és amelyek megoldatlansága esetén növelik annak valószínűségét, hogy a termelést befolyásoló esemény bekövetkezik. A terheléselosztó példa folytatásához hibát kell kiváltani, ha a virtuális IP – nek csak egy működő háttérkiszolgálója van a forgalom irányításához-most nincs redundancia, így egy hiba offline állapotba hozhatja a webhelyet.

a figyelmeztetések, amelyeket általában csak e-mailben ajánlunk, minden más típusú eseményre vonatkoznak. Egyetlen háttérkiszolgáló elvesztése egy virtuális IP-ről, ha vannak 20 más működő szerverek nem indokolják, hogy bárki felébredjen az éjszakában.

a riasztások hozzárendelésének meghatározásakor vegye figyelembe az eszköz elsődleges funkcióját. Például egy NetApp tároló tömb esetében az eszköz funkciója az IO-kérések olvasása és írása. Tehát a NetApps megfigyelésének elsődleges dolga az olvasási és írási kérelmek elérhetősége és teljesítménye (késleltetése). Ha egy kötet nagy késleltetésű kéréseket szolgál fel – például írási kérésenként 70 ms-t -, akkor ennek Hibaszintű riasztásnak kell lennie (egyes vállalatoknál ez megfelelő lehet kritikus szintű riasztásként konfigurálni, de általában kritikus teljesítményriasztást csak akkor kell kiváltani, ha a végső alkalmazás teljesítménye elfogadhatatlanul romlik.) Azonban, ha a NetApp CPU terhelése 99% egy ideig, annak ellenére, hogy riasztónak hangzik, azt javaslom, hogy csak figyelmeztető szintű riasztásként kezeljék. Ha a késést nem befolyásolja, miért ébreszti fel az embereket éjszaka? Küldjön e-mail értesítést, hogy a probléma kivizsgálható legyen, de ha az eszköz funkciója nem romlik, ne reagáljon túl. (Ha szeretné, meghatározhatja a riasztási eszkalációkat úgy, hogy az ilyen feltételek olyan oldalakat eredményezzenek, amelyek mondjuk 5 óránál hosszabb ideig nem javítottak vagy nem ismertek.)

a riasztási túlterhelés nagyobb veszélyt jelent a legtöbb adatközpontra, mint azt a legtöbb ember észreveszi. A gondolat gyakran: “ha egy figyelmeztetés jó, akkor többnek jobbnak kell lennie.”Ehelyett összpontosítson az eszközök elsődleges funkcióinak azonosítására – állítson be Hibaszintű riasztásokat ezekre a funkciókra, és figyelmeztetésekkel tájékoztassa Önt azokról a körülményekről, amelyek ronthatják ezeket a funkciókat, vagy segítsen a hibaelhárításban. (Ha a NetApp késése magas, és a CPU terhelése is éber, ez nyilvánvalóan segít a probléma diagnosztizálásában, ahelyett, hogy szokatlan volumenaktivitást keresne.)

tartalékolja a kritikus riasztásokat a rendszer teljesítményére és teljes rendelkezésre állására vonatkozóan.

a LogicMonitor hosztolt megfigyelése esetén az összes adatközponti eszköz riasztási definíciói a fenti módon vannak előre definiálva – ez az egyik módja annak, hogy percek alatt értelmes megfigyelést biztosítsunk.