Rysujemy wykresy, czyli długofalowy monitoring serwerów

Administracja serwerami to nie tylko reakcje na wszelkie awarie, nieprzewidziane zdarzenia w systemie, czy restarty aplikacji. Administracja to przede wszystkim monitorowanie pracy serwerów zarówno podczas normalnych warunków (stałe obciążenie) jak i awarii (bardzo duże obciążenie, problemy z serwerem). Często o problemie dowiadujemy się gdy już wystąpi, a zdecydowanie lepiej byłoby gdybyśmy mogli w jakiś sposób przewidzieć, że w najbliższym okresie czasu coś może się stać, a w szczególności, żebyśmy byli w stanie zapobiegać tym najgłupszym awariom, związanych z brakiem zasobów, czy to miejsca na dysku, czy pamięci.

Możemy z łatwością monitorować parametry serwera i zapisywać wyniki do plików, ale nikt tego nie będzie analizował... dużej ilości danych zapisanych w postaci tekstowej nie potrafimy przetworzyć w sposób niezbędny do przewidzenia problemów, do tego doskonale nadają się wszelkie narzędzia potrafiące generować wykresy (munin, cacti, graphviz).

Generując wykresy z zebranych danych otrzymujemy możliwość analizy w czasie zmian w charakterystyce pracy naszego serwera, w godzinach dużego ruchu zobaczymy większe zużycie pamięci, powoli ubywające wolne miejsce z dysków, lub wykorzystanie pamięci zbliżające się do limitów. Dzięki temu będziemy w stanie przewidywać, co się stanie jeśli ruch zwiększy się 2x, albo czy możemy jeszcze uruchomić kolejny serwer gry Counter Strike.

Wraz z upływem czasu, zbierając kolejne informacje, będziemy w stanie ocenić obecną sytuację z tą sprzed miesiąca i na podstawie wykresu będzie na łatwo ocenić, czy przy normalnej pracy potrzebujemy rozbudowywać storage, pamięć, czy przenosić się na nowy mocniejszy serwer. Powiedziałbym nawet, że nie da się skutecznie administrować serwerami bez łatwego podglądu zmian parametrów pracy serwera. Codzienna obserwacja łatwych w analizie wykresów pozwoli nam reagować jeszcze przed wystąpieniem problemu, bo przyznacie sami, że zatrzymanie się serwera httpd z powodu braku wolnego miejsca na dysku jest idiotyczną awarią.

Po krótce chcę Wam przedstawić narzędzie bardzo szybkie do wdrożenia, konfiguracja zajmuje < 10 minut, a po uruchomieniu będziemy mieli świetne statystyki... Przed Wami - Munin. ;-)

Instalacja Munin’a w Ubuntu
[email protected]:/home/jamzed# apt-get install munin

Munin składa się z dwóch podstawowych aplikacji, munin-node i munin:

  • munin-node - jest to daemon który wystawia dane dla podpiętych usług
  • munin - jest aplikacją która pobiera dane z node'ów
  • munin-cron - proces zbierający dane co 5 minut (dopisany do crontaba /etc/cron.d/munin)

Możemy mieć jeden centralny serwer z muninem i wiele munin-node'ów, z których będziemy pobierać dane. Po uruchomieniu daemon'a już następuje zbieranie danych, to co jest monitorowane określamy poprzez umieszczenie linku symbolicznego lub bezpośrednio skryptu/programu w katalogu /etc/munin/plugins/, standardowo znajdują się już podpięte usługi takie jak pamięć, cpu, interfejsy sieciowe, dyski. Munin dostarcza od razu po instalacji wiele gotowych skryptów, wszystkie znajdują się w katalogu /usr/share/munin/plugins/.

Konfigurujemy praktycznie jedynie htmldir (/var/www/munin), jest to katalog w którym będzie generowana strona z naszymi statystykami, jest to DocumentRoot który podajemy w konfiguracji serwera WWW, poniżej mamy listę podpiętych node'ów z których zbieramy statystyki. Prosta budowa munina pozwala na dopisywania różnych wtyczek samemu, wystarczy po prostu zwracać dane w takiej postaci:

[email protected]:/etc/munin/plugins# ./test
testowa.value 20

Przykładowy kod wtyczki może wyglądać następująco:

Więcej szczegółów dot. pisania własnych pluginów znajdziecie tutaj: http://munin.projects.linpro.no/wiki/HowToWritePlugins.

Aby monitować nowe elementy należy podpiąć taki skrypt (np. ln -s /usr/share/munin/plugins/test /etc/munin/plugins/test), wykonać restart munin-node'a i wykresy powinny już automatycznie rysować się dla naszej nowej usługi. Możemy sprawdzić czy nowa wtyczka zwraca poprawnie dane:

[email protected]:/etc/munin/plugins# telnet 127.0.0.1 4949
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
# munin node at serwer_monitorowany
list
open_inodes test if_err_eth0 irqstats entropy mysql_slowqueries if_eth0 processes mysql_threads df interrupts swap mysql_bytes load cpu df_inode mysql_queries iostat open_files forks memory vmstat
fetch test
testowa.value 32

  • list - zwraca wszystkie podpięte wtyczki
  • fetch $nazwa_wtyczki - pobiera aktualne dane dla niej

Inny sposób to po prostu wykonanie polecenia munin-run:

[email protected]:/etc/munin/plugins# munin-run test
testowa.value 57

Wynik na wykresie prezentuje się następująco:

Możliwości tego co i jak monitorujemy są nieograniczone, a dane prezentowane na wykresach są bardzo łatwe w analizie, więc zachęcam Was wszystkich do korzystania z gotowych narzędzi i monitorowania wszystkiego co się tylko da. ;-)

[poll id="5"]

Zapraszam do dopisywania w komentarzach innych narzędzi których używacie do monitorowania oraz generowania wykresów.

  • http://collectd.org/
    Jedyna "wada" collectd to to że jest to tylko backend (chociaż w contrib/ są 2 proste backendy). Sam soft jest napisany w C ( + api do perla pythona i javy i prosty sposób na pisanie pluginów, wystarczy skrypt zwracający jedną linijke na stdout) i zbiera dane z większą rozdzielczością (domyśnie 10s) niż większośc innych systemów (zwykle co 5 min) tak że można np. obserwowac czy loadbalancer rozdziela ruch równo pomiędzy serwery

  • To prawda, collectd jest bardzo dobrym narzędziem do zbierania statystyk, jedynym minusem chyba jest brak zaimplementowanej własnej obsługi do generowania wykresów, ale z drugiej strony jeśli ktoś bierze się za collectd prawdopodobnie będzie potrafił wykorzystać rrdtool'a, no i dzięki zapisowi danych do baz round-robin może wygenerować dowolne wykresy "szyte na miarę".

  • yZZuF

    Monitoring to nie rysowanie wykresów, a niestety ten artykuł to sugeruje. Wykresy mogą nam pomóc zobrazować dane i statystyki które zbieramy z serwerów i serwisów na nich uruchomionych. Żadne z wyżej wymienionych narzędzi nie poinformuje mnie (samo, bez konieczności patrzenia w wykresy) o tym, że zajętość dysku przekroczyła krytyczny próg, nie poinformują mnie, że jakaś usługa nie działa (poza tym ciężko jest mi sobie wyobrazić wykres dla działania lub nie działania usługi ;-)), nie będę mógł wprowadzić adnotacji, że usługa ma być wyłączona (dodatkowo - na jak długo) itd., itp.
    Oczywiście narzędzia te pozwalają na stworzenie odpowiednich wtyczek itd. ale wymyślanie koła od nowa jest moim zdaniem stratą czasu. Nie lepiej wykorzystać coś co już istnieje?
    Darmowe narzędzia które pozwolą nam na monitorowanie (a nie tylko rysowanie wykresów) naszych systemów i usług to przede wszystkim Zabbix (www.zabbix.com) oraz Nagios (www.nagios.com). W narzędziach tych można ustawiać progi ostrzegawcze, zbierać statystyki oraz trendy, rysować również wykresy, tworzyć scenariusze monitorowania stron www (również tych dynamicznych) itd. Poza tym narzędzia te posiadają jedną bardzo ważną rzecz - konsolę gdzie spływają wszystkie eventy (po wywołaniu tzw. triggera, czyli bardzo upraszczając przekroczenia pewnego z góry ustalonego progu jednego z monitorowanych parametrów) z naszych systemów. Mamy jedno centralne miejsce do obsługi zdarzeń. Jedyną ich wadą jest to, że pokazują swoje zalety przy trochę większych środowiskach niż "dwa/trzy" serwery.

  • @yZZuF w pełni się z Tobą zgadzam, powyżej chciałem poruszyć bardziej kwestię monitoringu długofalowego, np. sprawdzenie przyrostu ruchu, zmian obciążenia w określonym przedziale czasowym, a nie narzędzia monitorującego system on-line i sygnalizującego wystąpienie awarii (np. długie czasy odpowiedzi, brak dostępności usługi).

    Nagios czy Zabbix (open source) to podstawa jeśli chcemy na bieżąco wiedzieć co się dzieje w infrastrukturze, to właśnie konsola z tych narzędzi powinna być w naszej przeglądarce otwarta 24/7 ;-) Obiecujemy wkrótce przedstawić oba te narzędzia, na pewno nie pominiemy tego tematu.

  • e

    yzzuf: munin poinformuje Cię jeśli któraś usługa przekroczyła warning/critical.

  • e

    patryk: zamiast przeglądarki z otwartym nagiosem 24x7 proponuję:
    - osobny komputer (+monitor) z uruchomionym http://www.vanheusden.com/nagcon/
    - https://addons.mozilla.org/pl/firefox/addon/3607

  • macnow

    A ja do monitorowania używam jeszcze Monit'a, bardzo lekkie fajne narzędzie. Monitoruje stan usług na serwerze i jeśli jakakolwiek okaże się niestabilna (przekroczy próg pamięci, przestanie odpowiadać na porcie itp) to Monit automatycznie ją zrestartuje. Bardzo przydatne, bo zanim się zorientuje, że daemon się wykrzaczył, to już najczęściej jest uruchomiony ponownie.

    http://mmonit.com/monit/

  • Takie automatyczne uruchamianie czasami moze przyspozyc duzo wiecej problemow niz brak jednej uslugi (oczywiscie pod warunkiem, ze nie jest ona krytyczna), na mysli mam sytuacje kiedy daemon startowany np. loguje duzo bledow do error_log'a, po kilku godzinach pozostale uslugi tez moga juz lezec z powodu braku miejsca w /var/log/ :-) Ja uzywam do monitorowania stanu pracy uslug i ich automatycznego startu w przypadku kiedy nie dziala, pakiet daemontools http://cr.yp.to/daemontools.html ktory rowniez polecam :-)

  • e

    Co jest grane? Albo jest problem z komentarzami, albo kasujecie komentarze

  • Trafil jako oczekujacy do moderacji, zawieral wiecej niz jeden link, opcja ta zostanie wylaczona. Dziekuje za zgloszenie. :-)

  • op5

    A widzieliście Op5Monitor ? Komercyjna edycja nagiosa które za niewielkie pieniądze niweluje wszystkie nagiosowe kłopoty.

  • Pingback: Cześć, nazywam się Cacti i pochodzę z XX w. « guzik()