Tag: zabbix

Opublikowane w

Mój uptime

Już od jakiegoś czasu zastanawiałem się nad włączeniem monitoringu dla rosnącej liczby moich gratów w sieci. Do tej pory korzystałem z premedytacją głównie z gotowych serwisów typu Blox czy Jogger, ale ostatnio coraz więcej rzeczy jest zależnych tylko ode mnie. Niby niekrytyczne, ale… lubię, jak działa. A zdarzyło mi się, że po restarcie serwera nie wszystkie usługi działały – niby drobiazg, nie wstał varnish[1], ale efekty opłakane – statystyki nie działały.

Oczywiście mogłem podpiąć się pod monitoring w firmie (Zabbix), ale mało eleganckie, i ogólnie nie lubię mieszania gratów służbowych z prywatnymi. Mogłem też odpalić coś prostego swojego (nawet ze sprawdzaniem na krzyż, albo i w trójkącie), ale… trochę overkill, podobnie jak stawianie własnego Zabbiksa. Poza tym, na pewno nie miałoby to ładnego frontendu (chyba, że Zabbix). W ogóle pewnie nie miałoby frontendu. 😉

Stwierdziłem, że poszukam, bo na pewno są gotowe serwisy. Wymagania były proste:

  • darmowe
  • obsługa min. 5 hostów w darmowej wersji
  • prosta rejestracja i używanie
  • wsparcie dla IPv6
  • monitoring hostów (ping) oraz stron WWW

Owszem, są gotowe serwisy. Nawet sporo. Na tyle sporo, że miałem problem z decyzją. Prawie się zdecydowałem na monitor.us, ale zapytałem znajomych i… nikt nic nie umiał powiedzieć. Temat umarł śmiercią naturalną.

Przynajmniej na jakiś czas, bo niedawno zobaczyłem ten wpis i… dałem szansę serwisowi Uptime Robot. W sumie polecany na zestawieniu 10 darmowych serwisów do monitoringu stron WWW, więc pewnie go widziałem, ale jakoś nie zwróciłem uwagi. Ma wszystko co wyżej, na tle konkurencji wyróżnia się dużą liczbą sprawdzanych hostów/usług w wariancie darmowym (50) oraz stosunkowo wysoką częstotliwością sprawdzeń (co 5 minut), więc nada się nawet do więcej niż czysto amatorskich/prywatnych zastosowań.

Dashboard wygląda tak:

Uptime Robot dashboard

Kolejna wyróżniająca cecha to bycie darmowym jako podstawa, nie jako doklejka – serwis powstał jako darmowy z założenia, wersja płatna została dorobiona później, dla tych, którzy jednak potrzebują więcej. Wygląda więc, że nie zniknie nagle, nie zacznie proponować nachalnie płatnej wersji czy wymagać klikania linków co miesiąc…

A tak wygląda wykres dla pojedynczego hosta (ten z przerwą):

Uptime Robot wykres dla hosta

Uptime Robot umie powiadamiać o awarii mailem (tak właśnie korzystam, w końcu to prywatne graty) oraz dodatkowo przez IM (Twitter) oraz SMS (z tych metod nie korzystam). Metodę powiadomień ustawia się dla każdego hosta indywidualnie, więc można mieć ważne i ważniejsze, pilne i pilniejsze. Sprawdzać można działanie strony, obecność zadanej treści na stronie, odpowiedź hosta na ping oraz status otwarcia portu. Jak na serwis darmowy – więcej niż wystarczające. Do tego całość jest schludna i prosta. Polecam.

[1] Zachciało mi się usprawnień i optymalizacji… W top wyglądało OK – mysql był, lighttpd był…

Opublikowane w

Testowanie szybkości kluczy Zabbix agenta

Było tak, że jeden z kluczy w Zabbiksie działał wolno. Nawet: bardzo wolno. Ile czasu może się wykonywać proste sprawdzenie wersji programu typu chef-client -v, nawet na umiarkowanie dobitym systemie? Zainteresowani znajdą odpowiedź na końcu wpisu[1], dość powiedzieć, że czasami załączał się timeout po stronie zabbix agent. Problem został rozwiązany w sposób najdoskonalszy, czyli poprzez zrzucanie wartości z crona do pliku, i czytanie jej z pliku, ale niesmak pozostał. Poza niesmakiem, pozostało pytanie które jeszcze klucze są nieoptymalne?

Ponieważ na ten moment Zabbix nie daje możliwości sprawdzenia statystyk czasu zapytań dla poszczególnych kluczy, wykonałem małą protezę w postaci skryptu w Perlu, który odpyta danego hosta o wszystkie klucze kilka(naście) razy i policzy dla nich statystyki. Wklejka poniżej.

 

Skrypt przyjmuje dokładnie jeden parametr – hosta na którym będzie przeprowadzać test. Poza tym, wymaga wszystkich kluczy dla danego hosta, które ma testować, w pliku określonym w zmiennej $file. Na końcu wyświetli łączny czas wykonania zdefiniowanej ilości zapytań dla każdego klucza wyrażony w sekundach oraz sam klucz. Czytaj: pewnie chcesz przepuścić wynik przez sort -n. 😉

Parę rzeczy, które wyszły w trakcie pisania tego skryptu lub których się nauczyłem (w sumie gdyby nie one, to nie powstałby ten wpis):

Pętla sprawdzające N razy wszystkie klucze po kolei jest dokładniejsza od pętli, która sprawdza kolejno wszystkie klucze N razy każdy. Chodzi o rozkład obciążanie na maszynie, w tym drugim przypadku jest większa szansa, że któryś klucz trafi w nietypowe obciążenie maszyny.

Dokumentacja do modułu Time::HiRes jest… taka sobie. Można to zrobić prościej, jak wyżej. Początkowo kombinowałem ze sprintf oraz clock_gettime(CLOCK_REALTIME);

Może zastanawiać, skąd mnożenie przez 1000000. Otóż chodzi o bug z zapisem liczb zmiennoprzecinkowych (kojarzyłem to raczej z ośmiobitowców i dzielenia, nie wiem czy słusznie…):

perl -e '$a=1415907504.646884; $b=1415907504.603042; $d=$a-$b; print $d,$/'

vs.

perl -e '$a=1415907504.646884*1000000; $b=1415907504.603042*1000000; $d=($a-$b)/1000000; print $d,$/'

Że tak zacytuję real programmers use integer. 😉

Na koniec niezła wiadomość: jest szansa, że w przyszłości Zabbix będzie miał coś w stylu MySQLowego slowloga, czyli nie będzie trzeba robić testów na poszczególnych hostach, tylko będzie wbudowane narzędzie do wykrywania wolnych zapytań. Można głosować na ten feature. 😉

Specjalne podziękowania za uwagi i wyjaśnienia dla Tona z #perl @ IRCnet (thanks Ton!).

I wracając do pytania o nieoptymalne klucze z początku wpisu – tylko nieszczęsny chef-client okazał się być czarną owcą. Pozostałe klucze, choć czasem wymagają uruchomienia Perla lub kilku poleceń w Bashu, wykonywały się w zdecydowanie przyzwoitym czasie, grubo poniżej sekundy.

[1] Wykonuje się nawet cbanq cvęganśpvr frxhaq (rot13)! Bo na tyle ustawiony był timeout…

Opublikowane w

Zabbix i monitorowanie ruchu na porcie

Niedawno na kanale IRCowym #zabbix padło pytanie, jak monitorować ruch na porcie. Po upewnieniu się, że chodzi o port protokołu, a nie o interfejs w switchu (co jest zresztą chyba bardziej popularnym znaczeniem, szczególnie w kontekście monitoringu), padły propozycje.

Moja ulubiona ostatnimi czasy metoda, czyli czytanie danych o ruchu z flowów. Poważnie, sflow i nfdump rządzą, a wrapper do Zabbiksa, który łyka parametry i używa nfdump jest trywialny do napisania, lekki i działa znakomicie, a wyciąganie dowolnych danych o ruchu jest bardzo wygodne. No ale do tego trzeba mieć zboczenie sieciowe i/lub sprzęt obsługujący flowy, ew. uruchomić zrzucanie flowów na maszynie z Linuksem, co może być zbędnym jej obciążeniem i ogólnie strzelaniem z armaty do muchy.

Prostszym rozwiązaniem jest odczyt danych bezpośrednio z iptables. Przypuśćmy, że chcemy monitorować w Zabbiksie, ile ruchu trafia do serwera na porcie 80, a ile na 443. W tym celu tworzymy reguły, które będą dopuszczały, a jednocześnie zliczały ruch na danym porcie:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Zakładam, że trafią w odpowiednie miejsce w łańcuchu tak, że ruch będzie przez nie przechodził. Do wyświetlania wartości posłuży iptables -L -n -v. Jak widać, w pierwszej kolumnie jest ilość pakietów, w kolejnej ilość bajtów. W /etc/zabbix/zabbix_agentd.conf dodajemy linię:

UserParameter=traffic.incoming.dstport[*], iptables -L -n -v | grep "dpt:$1" | \
sed 's/K/000/;s/M/000000/;s/G/00000000/' | awk '{print $$2}'

Kolejno: grep po parametrze wywołanym z Zabbiksa, w tym przypadku za parametr posłuży numer portu (czyli czytamy dwie wartości: traffic.incoming.dstport[80] oraz traffic.incoming.dstport[443]), zamiana (zgrubna, bo kilo to 1000, nie 1024) K, M i G na cyfry i wyłuskanie w awk drugiej kolumny, czyli ilości bajtów. Widoczny podwojony $ – bez tego zabbix_agent potraktuje $2 jako drugi parametr przekazany z serwera.

I to by było tyle w temacie. Oczywiście można w prosty sposób rozbudować. Gdyby były jakieś błędy/uwagi/sugestie to walcie śmiało – pisałem na sucho, ja tego typu dane biorę z flowów…