my personal page

Administracja jednym serwerem to przyjemność. Administracja setką, to poważna praca. Która na dodatek staje się bardzo uciążliwa, jeżeli systemy są różne, a my nie mamy narzędzia do monitorowania naszego środowiska. Metod podglądania szeroko pojętych zasobów IT jest bardzo dużo. Od prostego w obsłudze MRTG i kilku domowej roboty skryptów, do „kombajnów” umożliwiających obejrzenie każdej śrubki w naszej serwerowni. Zestawienie tego typu narzędzi dostępne jest na przykład tutaj. Ja najczęściej używam duetu Nagios+Cacti. Nie dlatego, że jest najlepszy ze wszystkich, ale dlatego, że te programy znam i ich obsługa jest dla mnie wystarczająca wygodna, aby nie szukać niczego nowego. Tak właściwie to tutaj powinienem się przyznać, że należę do grupy ludzi raczej leniwych i bardzo dawno nie próbowałem używać czegokolwiek innego, więc być może korzystam z narzędzi, które powinny zostać zapomniane i wyparte przez inne – bardziej nowoczesne/nowatorskie – rozwiązania. Dobra, ale ja tak właściwie nie o tym, więc przejdźmy do tematu głównego.

Jeden z serwerów, którymi się opiekuję zaczął mieć problemy wydajnościowe. Tak naprawdę, to ma je „od zawsze”, ale klient nie daje się namówić na zmiany. Zawsze znajdzie jakąś wymówkę i twierdzi, że „niedługo będziemy to wszystko przebudowywać, więc na razie szkoda czasu”. Trwa to już od kilku miesięcy, ale co ja mogę? Jedyne, co mi przyszło do głowy, to zacząć robić statystyki, żeby ów klient mógł sobie obejrzeć (jeden niepozornie wyglądający obrazek potrafi czasami zdziałać cuda) jak bardzo jest źle i dlaczego ja w ogóle marudzę. Obciążenie systemu (load average) oraz wykorzystanie pamięci są wskaźnikami zbyt abstrakcyjnymi dla webmasterów i ich szefów, więc nie tędy droga. Zacząłem więc szukać szablonów do kaktusa, które umożliwią stworzenie dzieł sztuki (mylnie nazywanych wykresami) obrazujących rzeczywiste zaangażowanie serwera przy spełnianiu żądań (często politycznie nazywanych „życzeniami”) klientów.

Zacząłem więc buszować po forum Cacti i natknąłem się na kilka mniej lub bardziej udanych szablonów, jednak żaden z nich mnie jakoś specjalnie nie zachwycił. Owszem, większość z nich działała poprawnie, ale wszystkie sprawiały wrażenie (piszę o moich subiektywnych odczuciach, więc pewnie są to produkty na miarę jakiejś wyrafinowanej nagrody, a ja się zwyczajnie nie znam) oderwanych od całości. Spróbowałem inaczej, wpisałem w googla co ja tak naprawdę chciałbym monitorować i trafiłem na stronę poświęconą projektowi Percona Monitoring Plugins. Okazało się, że był to strzał w dziesiątkę, bo w jednym miejscu znalazłem szablony dla MySQLa, Apache’a oraz kilka fajnych rzeczy dla Linuksa. Wszystko okraszone świetną dokumentacją (jest nawet procedura instalacji typu „krok po kroku” oraz krótki opis, co który wykres obrazuje). Panowie (a być może i panie – nie wiem) z Percony – jak zwykle z resztą – wydali produkt dopracowany, z kompletną i jasną dokumentacją, który bardzo ułatwia pracę i sprawia, że życie zawodowe stało się odrobinę bardziej znośne :-)

Spsób, w jaki działają szablony nie jest jakiś specjalnie odkrywczy, ale bardzo miłe jest to, że wszystkie korzystają z tych samych mechanizmów:

• skrypt PHP, który łączy się bezpośrednie z serwerem MySQL na zdalnej maszynie,
• „SSH-based templates”, czyli inny skrypt PHP, który pobiera dane z monitorowanych maszyn za pomocą połączenia SSH. W dokumentacji jest nawet ładnie opisane, jak wygenerować odpowiedni zestaw kluczy i wszystko razem skofigurować tak, żeby działało.

Po 15 minutach konfiguracji udało mi się uruchomić monitoring najważniejszych elementów systemu, co uważam za bardzo dobry rezultat. Szczególnie, jeżeli weźmiemy pod uwagę stosunek poświęconego czasu do korzyści wynikających z posiadania takich danych, jak „apache requests” czy rozbicie wykonanych przez bazę SELECTów na poszczególne ich typy.

Hmmm, ten wpis wygląda chyba trochę jak średniej jakości case-study z folderu reklamowego, ale to wszystko naprawdę działa tak, jak powinno :-)