dlaczego obciążenie procesora nie powinno (zazwyczaj) być alarmem krytycznym.

jedno pytanie, które często pojawia się w monitorowaniu, to sposób definiowania poziomów alarmowych i eskalacji oraz poziom ustawiania różnych alarmów – krytycznych, błędów lub ostrzeżeń.

zakładając, że masz ustawione błędy i alerty krytyczne, aby powiadamiać zespoły za pomocą pagera / telefonu, a także alerty krytyczne o krótszym czasie eskalacji, oto kilka prostych wskazówek:

alerty krytyczne powinny dotyczyć zdarzeń, które mają natychmiastowy wpływ na klienta. Na przykład, produkcyjny wirtualny adres IP monitorowanego Load balancera spada, ponieważ nie ma dostępnych usług, do których można przekierować ruch. Strona nie działa, więc wezwij wszystkich.

ostrzeżenia o błędach powinny dotyczyć zdarzeń, które wymagają natychmiastowej uwagi i które, jeśli są nierozwiązane, zwiększają prawdopodobieństwo wystąpienia zdarzenia mającego wpływ na produkcję. Aby kontynuować przykład load balancer, błąd powinien zostać wywołany, jeśli wirtualny adres IP ma tylko jeden działający serwer backendowy do kierowania ruchu – obecnie nie ma nadmiarowości, więc jedna awaria może wyłączyć witrynę w trybie offline.

ostrzeżenia, które zazwyczaj zalecamy wysyłać tylko e-mailem, dotyczą wszystkich innych rodzajów zdarzeń. Utrata pojedynczego serwera backendowego z wirtualnego adresu IP, gdy działa 20 innych serwerów, nie gwarantuje, że ktoś zostanie obudzony w nocy.

decydując, jaki poziom przypisać alerty, należy wziąć pod uwagę podstawową funkcję urządzenia. Na przykład w przypadku macierzy pamięci masowej NetApp funkcją urządzenia jest obsługa odczytu i zapisu żądań IO. Tak więc podstawową rzeczą do monitorowania NetApps powinna być dostępność i wydajność (opóźnienie) tych żądań odczytu i zapisu. Jeśli wolumin obsługuje żądania z dużym opóźnieniem – na przykład 70 ms na żądanie zapisu-powinien to być alert poziomu błędu (w niektórych przedsiębiorstwach może to być odpowiednie do skonfigurowania jako alert poziomu krytycznego, ale zazwyczaj Alert wydajności krytycznej powinien być uruchamiany tylko wtedy, gdy wydajność aplikacji końcowej ulega niedopuszczalnemu pogorszeniu.) Jednak, jeśli obciążenie procesora na NetApp wynosi 99% przez pewien okres, mimo że brzmi to alarmująco, sugeruję, aby być traktowanym tylko jako ostrzeżenie poziomu alertu. Jeśli opóźnienie nie ma wpływu, po co budzić ludzi w nocy? Wyślij alert e-mail, aby problem mógł zostać zbadany, ale jeśli funkcja urządzenia nie jest zaburzona, nie reaguj nadmiernie. (Jeśli chcesz, możesz zdefiniować eskalację alertów tak, aby takie warunki skutkowały stronami, jeśli nie zostały skorygowane lub nie potwierdzono ich przez więcej niż 5 godzin, powiedzmy.)

przeciążenie alarmu jest większym zagrożeniem dla większości centrów danych, niż większość ludzi zdaje sobie sprawę. Myśl jest często ” jeśli jeden alarm jest dobry, więcej musi być lepsze.”Zamiast tego skup się na identyfikowaniu podstawowych funkcji urządzeń-Ustaw alerty o poziomie błędów w tych funkcjach i używaj ostrzeżeń, aby informować Cię o warunkach, które mogą zaszkodzić tym funkcjom lub pomagać w rozwiązywaniu problemów. (Jeśli opóźnienie na NetApp jest wysokie, a obciążenie procesora jest również w alarmie, to oczywiście pomaga zdiagnozować problem, zamiast szukać nietypowej aktywności głośności.)

Rezerwuj alerty krytyczne dla wydajności i dostępności systemu jako całości.

dzięki monitorowaniu hostowanemu LogicMonitor definicje alertów dla wszystkich urządzeń data center mają wstępnie zdefiniowane progi alertów w powyższy sposób – to jeden ze sposobów, w jaki pomagamy zapewnić sensowne monitorowanie w ciągu kilku minut.