Poziomy monitoringu

Monitoring IT to systematyczny pomiar oraz obserwacja środowiska informatycznego, dająca obraz funkcjonowania infrastruktury, systemów oraz aplikacji. Monitorowane parametry dotyczą fizycznie lub logicznie wydzielonego środowiska.

Monitoring reaktywny

Umożliwia kontrolę stanu środowiska IT w czasie rzeczywistym. W momencie wystąpienia awarii, system monitoringu jest w stanie wskazać jej źródło oraz automatycznie poinformować wybranym kanałem wskazane wcześniej osoby. Dzięki temu, możliwe jest natychmiastowe podjęcie działań mających na celu minimalizację strat wynikających z nieprawidłowego funkcjonowania danego systemu lub urządzenia.

Monitoring proaktywny

Na podstawie zgromadzonych danych i ich korelacji, system monitoringu jest w stanie prognozować zachowanie konkretnych komponentów. Dzięki możliwości wyznaczania trendów, umożliwia działania mające na celu eliminację niepożądanych zdarzeń w przyszłości. 

Jak określić, co należy monitorować?

Aby określić, jakie parametry powinniśmy monitorować, należy odpowiedzieć sobie na następujące pytania:

• Do jakich zasobów mamy dostęp bezpośredni a do jakich jest to dostęp rozproszony?
• Jakie aplikacje oraz systemy wymagają monitoringu i jak często?
• Monitorowanie jakich parametrów wynika bezpośrednio z  umowy podpisanej z klientem oraz poziomów SLA (Service Level Agreement)? 

SLA jest to umowa utrzymania i systematycznego poprawiania ustalonego między klientem a usługodawcą poziomu jakości usług poprzez stały cykl, obejmujący:

• uzgodnienia
• monitorowanie usługi
• raportowanie
• przegląd osiąganych wyników

Pierwszym krokiem wdrożenia SLA jest stworzenie katalogu świadczonych usług. Usługi łączone są w grupy, te w kolejne, aż w końcu powstaje kompletny produkt – definicja usługi. Na bazie zdefiniowanej usługi precyzuje się parametry usługi umieszczone w umowie SLA.

Jeśli wymagane jest, by nasza aplikacja była dostępna 24h/7 (tak jak aplikacja LIDO, której zadaniem jest wspomaganie linii lotniczych podczas codziennych operacji (której długi czas byłam administratorem baz danych w mojej firmie), należy zapewnić monitoring bardzo częsty - pomiary powinny być dokonywane co 5 min, czasem nawet częściej - co 2 min. Czas reakcji na awarię również powinien być bardzo szybki - max. 15 min, zaś czas rozwiązania problemu nie większy niż 30min.

Trzeba również dobrze przemyśleć, co i w jaki sposób monitorować. Z parametrów systemowych zalecam:

• monitoring zużycia dysków
• monitoring zużycia pamięci
• liczbę procesów na maszynie
• zużycie procesora
• użycie sieci
• ilość procesów "zombie"

Z parametrów bazodanowych:

• czas połączenia z bazą danych (dostępność bazy danych)
• czas wykonania specyficznego zapytania
• zużycie dysków (szczególnie ważne są : lokacje zawierające pliki sortowania, logu transakcyjnego, backupy, snapshoty dzienne czy też pliki żurnali)
• w przypadku mysql - parametry dotyczące utylizacji indeksów
• w przypadku Oracle - zużycie dysku przez przestrzenie tabel

 
Z parametrów aplikacyjnych:

• dostępność serwerów webowych (HTTP, Tomcat, Wildfly, nodejs)
• dostępność aplikacji webowej 

W każdym przypadku monitoring wygląda trochę inaczej i jest specyficzny dla danej aplikacji, serwera. Do zadań programisty, testera oraz administratora należy określenie potrzebnych metryk oraz określenie działań naprawczych i czasu reakcji na zgłoszone przez system problemy.

Należy również tak zaprojektować serwer monitorujący, by periodyczne zbieranie metryk nie spowodowało znaczącego spadku wydajności aplikacji monitorowanej. Dobrze jest zebrać metryki w grupy, które są sprawdzane podczas jednego żądania wysyłanego przez serwer monitorujący. Istotne jest również, by wykonanie skryptu zbierającego metryki, było jak najszybsze.

Przy użyciu systemu monitorującego Nagios, który jest moim ulubionym i który rekomenduję, można to zrobić implementując plugin: check_multi. Więcej informacji o tym pluginie można znaleźć tutaj. Zbiera on wybrane metryki i łączy je w grupy. Następnie uruchamiany jest jeden proces na monitorowanym serwerze, który przy użyciu wątków sprawdza metryki w sposób równoległy. Sprawia to, że sprawdzenie kilkunastu metryk jest bardzo szybkie (np. 5s). Wszystkie wyniki, z każdego skryptu monitorującego, są zbierane razem, pakowane i wysyłane po sieci do serwera monitorującego.

Każdy pomiar oprócz danych "pomiarowych" powinien również zbierać dane statystyczne, na podstawie, których następnie rysowane są wykresy oraz tworzone raporty dostępności serwera, czy też aplikacji. Na podstawie tych danych statystycznych można również przy użyciu funkcji statystycznych, takich jak kowariancja lub predykcja statystyczna, określić kiedy i z jakim prawdopodobieństwem awaria się powtórzy. Można również poprzez analizę wykresów zużycia pamięci, przestrzeni dyskowej ocenić czy należy zwiększyć ilość zasobów na serwerze.

Dane z systemów monitoringu do analizy mogą być prezentowane na wiele różnych sposobów, np. przy użyciu: PNP4Nagios, Grafana, Plesk, SPLUNK.

Opis, jak zorganizować oraz zainstalować system monitorujący Nagios, można znaleźć na moim blogu: wynalazkowo.com.