Menu

Pomiędzy bitami

Techno, porno i duszno. Blog niezupełnie technologiczny.

Testowanie szybkości kluczy Zabbix agenta

rozieblox

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...

© Pomiędzy bitami
Blox.pl najciekawsze blogi w sieci