my personal page

Każdy, kto ma pod opieką jakiś serwer lub urządzenie sieciowe lubi wiedzieć, co się z owym sprzętem dzieje. Owszem, można codziennie logować się na każdą maszynę, odczytywać jej parametry życiowe i skrzętnie zapisywać w notesie. Ale chyba nie jest to zbyt dobre rozwiązanie i nawet najbardziej wytrwały administrator po pewnym, zapewne niezbyt długim czasie, da sobie z taką metodą spokój. A brak kontroli nad sprzętem prowadzi w prostej linii do katastrofy. No dobra, mam nadzieję, że do potrzeby monitorowania zasobów nikogo specjalnie przekonywać nie muszę. Ale natychmiast pojawia się seria pytań: co?, jak?, gdzie?, czym? jak często?…

Na początek warto określić, które urządzenia chcemy otoczyć kontrolą. Z dużym prawdopodobieństwem będą to wszystkie serwery (w szczególności te produkcyjne, czyli zarabiające kasę). Równie ważnymi elementami są macierze dyskowe, bez których serwerom raczej trudno byłoby wypełniać ich zadania. W drugim rzędzie routery i inteligentny sprzęt sieciowy (np. zarządzalne przełączniki zainstalowane w centralnych miejscach sieci). Kolejnym elementem, na który czasami warto zwrócić uwagę są urządzenia drukujące (użytkownicy na pewno się ucieszą, jak z wyprzedzeniem zamówimy toner do drukarki i nie będą musieli biegać na inne piętro, żeby wydrukować ważny list dla Klienta). Na samym końcu są stacje robocze użytkowników i wszelki drobny sprzęt, który włączyliśmy do naszej sieci. Nie zawsze (a właściwie to całkiem rzadko) będziemy potrzebowali monitorować wszystko. Czasami okaże się, że w zupełności wystarcza nam wiedza o stanie dwóch serwerów i jednego routera pomimo posiadania całej szafy wypchanej sprzętem.

Jeżeli wykonaliśmy już listę urządzeń, które będziemy monitorować to możemy chwilę odpocząć przed następnym zadaniem, bo będzie ono niezwykle ważne i męczące. Drugim bowiem krokiem do sprawnego systemu monitoringu jest odpowiedzenie sobie na pytanie: co tak naprawdę chcemy monitorować? I – wbrew pozorom – odpowiedź typu „wszystko, co się da” nie jest najlepsza. Zagadnienie monitoringu możemy podzielić na dwa elementy.

• Pierwszym jest okresowe zbieranie informacji i na ich podstawie rysowanie wykresów, dzięki którym będziemy mogli określić długoterminowe trendy oraz z wyprzedzeniem zapobiegać np. wykorzystaniu całej przestrzeni na dyskach macierzy. Dane takie przydają się także przy profilowaniu połączeń sieciowych. Jeżeli wykresów takich będzie bardzo dużo, to będziemy musieli poświęcić sporo czasu, żeby się przez nie wszystkie przekopać. Oczywiście można je poukładać w jakąś przemyślaną hierarchię, ale nie spowoduje to, że wykres obrazujący ilość danych przesyłanych przez interfejs sieciowy drukarki prezesa stanie się w jakikolwiek sposób pożyteczny.

• Drugim zadaniem systemu monitorowania zasobów jest odpytywanie urządzeń o ich stan i – na bieżąco – zgłaszanie wszelkich nieprawidłowości administratorowi. I tutaj możemy wpaść w pułapkę – złotą zasadą jest utrzymywanie prawidłowych wartości wszystkich monitorowanych parametrów (tzw. stan „all green”). Zbyt duża ilość monitorowanych elementów powoduje, że „alarmy” (które mogą być spowodowane np. wyłączeniem przez użytkownika drukarki) staną się codziennością i po pewnym czasie administrator przyzwyczai się do nich na tyle, że nie będzie w stanie z właściwą uwagą zareagować na rzeczywiste problemy. Sam problem możemy rozszerzyć na odpowiedni dobór wartości progowych monitorowanych parametrów, które to wartości powodują zgłoszenie alarmu.

Co więc powinniśmy monitorować? Tutaj niestety nie ma uniwersalnej odpowiedzi, można jedynie nakreślić kilka ogólnych zasad, którymi będziemy się kierować przy konfiguracji naszego super systemu monitorującego.

• Po pierwsze, zawsze warto znać „zajętość systemu”. W przypadku serwerów Linuksowych będzie to parametr „load average” oraz zużycie pamięci (najlepiej z rozdzieleniem na pamięć zużytą przez procesy i na cache). Dla urządzeń sieciowych jak routery i switche oraz dla systemów opartych na systemie Windows oraz dla macierzy dyskowych będzie to najprawdopodobniej obciążenie procesora/ów i (jeżeli to możliwe) wykorzystanie pamięci. Czasami warto dorzucić do tego zestawu ilość procesów uruchomionych w systemie.

• Drugim istotnym elementem jest kontrola interfejsów sieciowych, ale tylko tych, które są dla nas istotne. Zupełnie pozbawione sensu jest monitorowanie interfejsów typu loopback na serwerach oraz portów na switchach w warstwie access, do których podłączone są poszczególne stacje robocze. Wprawdzie zdarzają się przypadki, w których warto posiadać takie informacje, jednak w każdym momencie możemy sobie taką tymczasową sondę skonfigurować, a długoterminowe trendy tego typu są raczej mało użyteczne.

• Kolejną rzeczą jest zajętość dysków w serwerach i macierzach dyskowych. Właśnie tutaj najbardziej przydają się zestawienia obejmujące długie czasy (rzędu miesięcy), za pomocą których możemy przewidzieć konieczność rozbudowy swojej infrastruktury sieciowej. Dzięki wyznaczonym na podstawie takiego zestawu danych trendów możemy z odpowiednim wyprzedzeniem poczynić odpowiednie zakupy i przemigrować nasze pliki na bardziej pojemne rozwiązania, unikając jednocześnie niepochlebnych opinii ze strony użytkowników i nerwowego kupowania przypadkowych dysków, bo nagle odkryliśmy, że na serwerze plików skończyło się miejsce.

• Czwarta grupa dotyczy parametrów specyficznych dla pełnionych przez urządzenia zadań. I tak, dla systemu Linuksowego pełniącego rolę tzw. NATownicy, warto wiedzieć, jak dużo wpisów znajduje się w tablicy conntrack. W przypadku routera „spinającego” sesje BGP, istotnymi informacjami okazują się ilość prefiksów, które dostajemy od poszczególnych peerów. Warto też znać długość kolejki oczekujących do przetworzenia wiadomości dla serwera pocztowego, ilość zestawionych sesji dla koncentratora VPN, zestawienie pokazujące „jakość” wiadomości dla filtrów antySPAMowych, rodzaje zapytań do bazy danych…

Wymieniać można długo i z każdą chwilą robi się tego więcej. W którym momencie należy powiedzieć „dość”? Spróbujmy do problemu podejść od drugiej strony: dla każdego wymyślonego parametru znajdźmy jakieś zastosowanie. Czy ten konkretny wykres pomoże nam przewidzieć zużycie zasobów? Czy skonfigurowana właśnie sonda ułatwi rozwiązanie jednego ze standardowych problemów, z którymi spotykamy się z naszej pracy? A może dzięki kolorowemu obrazkowi prezes będzie mniej marudził przy podpisywaniu budżetu na kolejny rok? Jeżeli na wszystkie powyższe pytania odpowiedzieliśmy negatywnie i nie jesteśmy w stanie wykombinować żadnego zastosowania, to może jednak z takiego parametru zrezygnować? Warto monitorować 10% parametrów za dużo, niż za mało. Jednak z drugiej strony lepiej dokładać sondy w miarę potrzeb, niż monitorować setki parametrów niepotrzebnie. Powtórzę to z resztą jeszcze raz: Przy wdrażaniu nowego rozwiązania naprawdę warto dobrze przemyśleć, które dane będziemy mogli wykorzystać do diagnostyki działania infrastruktury i tylko takie zbierać. Z czasem zaprocentuje to mniejszych chaosem i większą przejrzystością całego systemu.

No dobra, skoro udało nam się odpowiedzieć na pytanie „co i o czym chcemy mieć informacje?”, to przyszedł czas na pytanie „czym będziemy zbierali informacje?”. Istnieje wiele, bardzo różniących się od siebie, rozwiązań, które pomogą nam w ukończeniu tego zadania i zanim dokonamy wyboru, warto kilka z nich przetestować. Postaram się poniżej przedstawić króciutki opis rozwiązań najczęściej wykorzystywanych.

• Zacznijmy od rzeczy najprostszych, czyli od pakietu RRDtool, napisanego przez Tobiasa Oetikera. Umożliwia on zbieranie danych z bazie typu round robin i rysować na ich podstawie wykresy. Nic nie stoi na przeszkodzie, abyśmy własnoręcznie napisali skrypty wykorzystujące to narzędzie i dostosowali wszystko do własnych potrzeb. Będzie pięknie i kolorowo. Kiedyś tak nawet robiłem, jednak wymaga to bardzo dużo pracy i – wobec mnogości innych rozwiązań – jest niezbyt atrakcyjne (w szczególności dla rozwiązań standardowych). O genialności RRDtool świadczy fakt, iż spora część dostępnych pakietów do monitorowania jest oparta właśnie o to narzędzie.

• Drugim, trochę bardziej rozbudowanym programem jest MRTG tego samego autora. To narzędzie umożliwia rysowanie wykresów na podstawie danych, które MRTG samo sobie zbierze za pomocą protokołu SNMP. Wystarczy tylko skonfigurować agenty SNMP na maszynach, które chcemy monitorować, utworzyć prosty plik konfiguracyjny dla MRTG i możemy się cieszyć zestawem kolorowych wykresów. Jednak autor pisał ten program z myślą o monitorowaniu głównie (wyłącznie?) routerów, co powoduje, że na dłuższą metę jest to rozwiązanie dość mocno ograniczone i niezbyt wygodne.

• Teraz będzie jedno z moich ulubionych narzędzi: Cacti. Ulubione dlatego, że jest łatwe w instalacji i konfiguracji prostych scenariuszy. Z drugiej strony – w przypadku bardziej rozbudowanych instalacji jest wyjątkowo uciążliwe :-) Ale wracając do samego produktu, Cacti, podobnie jak MRTG, umożliwia rysowanie wykresów na podstawie zebranych danych. Jednak w tym przypadku wykresy mogą być wielokolorowe, z rozbudowanymi opisami i poukładane w funkcjonalne drzewa. Także zbieranie danych nie jest ograniczone wyłącznie do SNMP. W każdym momencie możemy dopisać własny skrypt, który dostarczy kaktusowi odpowiednio obrobionych danych. Warto także wspomnieć, że istnieje bardzo dużo tzw. template’ów, umożliwiających zbieranie danych z wielu, nieraz dość egzotycznych, urządzeń. Jeżeli nie ma gotowego rozwiązania, to nic nie stoi na przeszkodzie, abyśmy sami taki template napisali (i oczywiście udostępnili go innym). Kaktusa używam na co dzień i sprawdza się całkiem nieźle, nawet pomimo swoich niedoskonałości.

• Opisane przed chwilą rozwiązania służą do zbierania danych i tworzenia na ich podstawie wykresów. Ale co z monitoringiem „na bieżąco”? Takim, który będzie na nas wrzeszczał, jak padnie nam router albo któryś z administratorów potknie się o kabel i odłączy połowę użytkowników od sieci? Do takich zadań możemy użyć na przykład Nagiosa. Jest to narzędzie przeznaczone do monitorowania infrastruktury IT, umożliwiające ocenę bieżącego stanu wszystkich podłączonych do niego urządzeń. Napisany w PERLu produkt ma dość toporną, ale nieźle opisaną konfigurację, wobec czego musimy się odrobinę natrudzić, zanim stanie się wygodny i naprawdę użyteczny. Jednak moim zdaniem warto, ponieważ zyskujemy bardzo potężne narzędzie, które pomoże nam w codziennej pracy i bardzo skróci czas poszukiwania źródeł awarii.

• Zabbixa niektórzy określają jako „złoty środek” pomiędzy Cacti a Nagiosem. Ten produkt umożliwia tworzenie statystyk oraz monitoring bieżący w jednym miejscu. Ma jednak zupełnie odmienną od Nagiosa politykę. O ile w tym pierwszym musimy skonfigurować wszystkie testy, które wydają nam się potrzebne, to Zabbix „z pudełka” próbuje monitorować wszystko, co tylko autorom przyszło do głowy, a nasza rola sprowadza się do powyłączania rzeczy zbędnych. Szczerze pisząc, niezbyt mnie to przekonało i na swoim podwórku używam głównie duetu Cacti+Nagios, który – jak do tej pory – sprawdza się świetnie.

Poza wymienionymi powyżej rozwiązaniami istnieją jeszcze dość popularne narzędzia, o których istnieniu wiem, ale ich nie testowałem (kolejność przypadkowa):

• collectd
• AdRem NetCrunch
• Open NMS
• Zenoss

A potężną tabelkę z porównaniem wielu podobnych programów można znaleźć TUTAJ.

I to chyba tyle w tym odrobinę przydługim wstępie do monitorowania. Cała reszta to już instalowanie, konfigurowanie, poprawianie błędów w konfiguracjach oraz… patrzenie na statystyki i uciecha z zielonych wskaźników na naszych ekranach.