Zabbix - daje radę

Trudne początki

Zaczęło się pozornie kiepsko. Może nie było by specjalnie o czym pisać. Ale tego co monitoruję nazbierało się sporo, dlatego myślę że warto to pokazać. Z oczywistych przyczyn musiałem poddać dane anonimizacji. Większość z tych rzeczy udało się spreparować podczas rozwijania aplikacji Kamsoft.

To było dość dawno... Oczywiście sobie nie przypomnę kiedy, ale sporo czasu już minęło.

Pogadanka u szefa jak to zwykle. Podobno ktoś tam używa Zabbix. I podobno monitoruje system. W czasach gdy ja miałem opanowane robienie wykresów RRD z poziomu Cacti, gdzie wcale nie trzeba było bazy i jedyną zajętość jaką generowało Cacti to były pliki RRD. Zadawałem sobie pytanie po co to w ogóle taka kobyła. Dodam że zacząłem się cieszyć moją nowinką skryptową perl-a i RRD. Udało mi się zrobić właśnie nowy wykres do Cacti który potrafił na wykresie zobrazować różne rodzaje requestów do naszego systemu w skali czasu. Ilość requestów znaczyłem kolorami. Oś X to czas. Oś Y to typy Requestów (ze względu na rodzaj operacji) było tego z 1000. Oj było na co popatrzeć. Widać było coś na kształt (tylko przykład) nie mam oryginalnego wykresu. Był wielki i życie zweryfikowało jego użyteczność - poszedł do kosza. Mało co z tego dało się niestety wywnioskować. Widmo dość losowe. A trzeba było znaleźć przyczynę i źródło wycieku pamięci. Oj niestety w Javie też tak się da.

Jakoś zawsze miałem sentyment do skryptów, których nie trzeba kompilować i na potrzeby uruchomienia jednego zadania wszystko działa od razu bez całej tej kompilacji (ech ta Java) nawet przy dużych projektach. Wiadomo że nie wszystko złoto co się świeci - teraz to wiem.

Szukanie przyczyny to był jakiś katalizator do poszukiwań jakiegoś narzędzia do diagnostyki takich problemów. Wtedy nasz system był znacznie mniejszy. Raptem 2 workery Tomcat-a. Ale mimo to przychodziły takie momenty, że to klękało. Wtedy zaczynało się szukanie i nerwówka.

Zabbix-a zainstalowałem ale mnie nie przekonał.
Jedyne czego zazdrościłem wtedy to scrollowania czasu. Teraz uważam że to chyba najgorsze co ma Zabbix. Na ten czas nie byłem tego w stanie ogarnąć. Wyglądało jakby to samo potrafiło znajdować to co ma diagnozować. Znalazło Linux-y i tyle. Wtedy w Cacti potrafiłem znacznie więcej.

Odstawiłem to na półkę i zostałem przy Cacti.

Szef wie co chce i dąży do celu, jak się na coś zaweźmie. Tak jak to bywa w większej firmie - temat dostał ktoś inny. Oj wcale się nie zdziwiłem. Marketing-owo podobno poszedł krok dalej. Ale jak popatrzyłem to, stanął tam gdzie ja. 

Prostsze będzie lepsze

Było by dobrze z Cacti - ale tylko u mnie. Na innych instalacjach już nie było tak kolorowo. Monitorowałem swój system (testowy) a produkcja była już poza moim zasięgiem. Jeden miał tak inny inaczej. Nasz system zaczął się rozrastać i nawet na testowym systemie zaczęło się robić ciasno i wolno. Przed oczami przewinął mi się wtedy wykres diagnostyki dysku z Linux-a (iostat). Niby tylko tak prosty xml do importu do zabbix. Jak sobie pomyślałem, że trzeba by to od zera dziargać w perl-u coś dla Cacti trochę mnie lenistwo ogarnęło. To był jakiś przełom w Zabbix. Wykresy się pojawiły w Zabbix. To była dobra wróżba. To się da sprzedać dla innych administratorów. I tak właśnie zostały pogrzebane moje argumenty lekkości. Nadal ciągle próbuję znaleźć równowagę pomiędzy kodowaniem w jakimś sensownym języku a definiowaniem w xml-u. Kto robił grubsze skrypty w ant wie co to znaczy.

Jeden z pierwszych wykresów Zabbix iostat który mnie przekonał o tym że to się da używać.

Hosty

To jest właśnie ciekawe, że skomplikowanie powoduje uproszczenie. Takie wrażenie na mnie wywarła wizja hostów. Takim hostem może być np Tomcat, ESB, Agent. I to jest właśnie pomylenie. Naturalnie bym tak nie pomyślał. Wielu którzy się zetknęli z Zabbix tak pomyśli. Pewnie da się to przerobić tak aby host który obrazuje System (np Linux) posiadał dodatkowe itemy odpowiedzialne za monitorowanie poszczególnych usług. Tomcat przecież można uważać jako usługę. Pewnie podpinając go przez JMX tak by było. Lepiej tego nie robić tak. Moje doświadczenia z JMX są negatywne jeżeli chodzi o komunikację po sieci. JMX potrzebuje dużego zakresów portów, a to czasem nie jest proste do osiągnięcia.

Duży system i wirtualizacja

Tu się pojawił dopiero skok. Łatwo było kogoś przekonać: wiesz tu jest wirtualka. Sciągasz i masz. Ale zanim się to zaczęło sam u siebie tak zrobiłem. Przeniosłem się z docelowej maszyny na wirtualki. Ciekawe zdarzenie miałem miejsce śledzić. Coś na wirtualkach zaczeło zjadać procki na operacjach IO. Rzut oka na główna maszynę, która hostuje VMware i co okazuje się, że na głównej też coś zjada tak proca.
Okazało się że kolega kopiował obraz - niestety na wirtualkach to się odbija jak cień na całym systemie.
Można się nieźle pomylić jak się nie ma obrazu całości a tylko fragment. A już chciałem badać moje aplikacje...

Co by tu jeszcze zmonitorować?

Lepiej nie przesadzać z monitorowaniem to jakoś zawsze wiedziałem. 

Potrafię jednak wpiąć się w różne ciekawe miejsca. 

W najbliższym czasie spróbuje pokazać inne obrazki.

Obrazki to nie jest jedyna dobra rzecz tego systemu. Dobrze zestrojony może alertować o tym że coś się złego święci. Nie należy jednak tego traktować jako złoty środek. Zwykle już jest ciepło jak Zabbix się odzywa. 

Na dziś można rysować ze wszystkiego co daje dostęp przez JMX, SNMP korzystając z normalnego agent-a. Przez traper dowolne skrypty wsadowe.

Źródła

Kod i skrypty można pobrać z https://code.google.com/p/zabbix-extension/.

Linux

Monitorowanie systemu linux w podstawowym zakresie działa całkiem dobrze. Zabbix Agent dla systemu linux exportuje podstawowe intem-y i działają one całkiem dobrze. 

Tego tematu nie zamierzam tu poruszać. Skupię się więc na tych rzeczach, które są nietypowe. 

Większość statystyk które chcemy możemy znaleźć jako opis na stronie zabbix-a, ale akturat takiej nie znalazłem. 

Dużo danych można dodać do systemu przez dodanie dodatkowych UserParams do zabbix agenta.

Zazwyczaj sprowadza się to do podania skryptu który należy uruchomić aby zwrócił określone dane na ż żądanie dostarczenia przez agenta jakiegoś item-a. 

Takie rozwiązanie jest dobre, ale tylko wtedy gdy pobranie gdy skrypt wykonuje się szybko, lub itemy pytane są wyjątkowo rzadko.

Przy odpytywaniu np 1 na minutę kilku, lub kilkunastu itemów zaczniemy mieć problemy.

Dlatego większość optymalizacji które się pojawią sprowadzają się do cachowania pewnych danych, a potem zwracania ich z tego cache na żądanie. 

Netstat

Jednym z takich przykładów jest napisany dla wprawki w perlu netstat.

Statystyka okazała się całkiem przydatna do sprawdzenia i tuningu konfiguracji Apache httpd.

Przykład statystyki netstat dla serwera z uruchomionym Apache httpd. Widać różnicę po zmianie.
Przy poprzedniej konfiguracji nie wyrabiały routery.

Rozszerzenie składa się z:

• skryptu w pythonie które pobierają dane z netstat-a i cachują w pliku
• skryptu w pythonie który pobiera item-a z cache (plik)
• wpisu do cron-a który uruchamia co minute aktualizację cache
• aktualizacji UserParams dla zabbix agent-a
• definicji itemów wykresów dla zabbix

Tomcat

Główne obrazki którymi się ludzie cieszą to pamięć i requesty. Wiadomo to się przydaje. To oczywiście też mam w swoim repertuarze.

Trochę nietypowe połączenie. Korelacja czasu przetwarzania i liczba requestów to ważny wskaźnik
w systemie o w miarę stałej wartości czasu odpowiedzi. 

Osobiście nie badam zbyt często. To obciąża system. Wartości które dobrałem to kompromis. Tu są liczniki do badania, więc nic nie ginie, może zostać tylko scałkowane (efekt filtra dolnoprzepustowego). Nie chcę w tym wypadku bawić się w wyciąganie wniosków z tego co jest namalowane. Okazuje się, że aby coś sensownego zobaczyć trzeba przejrzeć kilka punktów.

Liczba sesji jest ważna ponieważ to alokuje pamięć serwera.

Gdy nie zdążysz zareagować na wyciek pamięci wszystkie statystyki idą do piachu. Wiesz tylko że to się zaczęło mniej więcej o godzinie X.

Alokacja pamięci powyżej zadeklarowanej kończy się ogólna klęską. Wykresy też przestają wtedy działać.

Gdy brakowało informacji z bazy danych, jedną z możliwości sprawdzania liczby połączeń do bazy była analiza póli połączeń. Tu też mogą się pojawić problemy jak coś się nie pozamyka (szczególnie z winy developera).

Jedna z pól połączeń do bazy

Apache httpd

Pierwszy punkt styku klienta i aplikacji webowej to serwer WWW. Oczywiście można sobie wyobrazić różne rozwiązania z balancingiem niemniej jednak, to choć stare to jest nadal dość powszechne.

Kody odpowiedzi na minutę. Dość ważne z punktu widzenia detekcji
błędów raportowanych do klientów (szczególnie 503)

Typy requestów na minutę

Balancing przekazuje sterowanie do workerów, można to traktować jak kolejkę.
Na tym wykresie ładnie będzie widać jak coś zwolni przetwarzanie.

WSO2 - ESB

Przez magistralę przelatuje mnóstwo danych. Czasem dzieją się tam dziwne rzeczy. Niektóre można zaobserwować na liczbie połączeń, oraz na wyłączaniu serwisów. Wiadomo jak tu coś klęknie to klapa na max-a.

Jeden z parametrów ESB

Liczba połączeń do ESB (przychodzące i wychodzące)

iSeries DB2

Po uruchomieniu interface SNMP wydawało się że to jest właśnie dobre miejsce do badania parametrów DB2. Baza informacji SNMP była wystarczająca, CPU, Pamięć, trochę zamotane netstat którego nie wiedziałem jak ugryźć. Moje poszukiwania po interface SNMP nie przyniosły oczekiwanego rezultatu.

CPU niby nic szczególnego ale bez tego jak bez ręki

Liczba procesów jest ważna ponieważ jest to związane z liczbą połączeń do bazy.
Niestety połączenia to nie jedyne procesy i trochę trudno na podstawie tego powiedzieć co.

Z analizy puli pamięci ciężko coś wnioskować. Może kiedyś z tego zrobię jakiś doktorat, ale na dziś jest ta informacja jest nieużyta.
Po dłuższej zabawie w pythonie wyłuskałem z SNMP te wiadomości nestat które są dla mnie coś warte i pokazują liczbę połączeń z określonych maszyn.

Połączenia do iSeries DB2 z 4 maszyn klastra. Gdy wszystko jest ok to obciążenie się rozkłada równo.

Warto widzieć ile połączeń jest ogólnie. Jak wiadomo różne sterowniki pracują na różnych portach. Dobrze by mieć jeszcze jakiś rozdział na określone porty.

Tak jak powiedziałem - chciałem coś więcej. Jedno z miejsc gdzie takie statystyki znalazłem jako pudełkowe to był Mysql. Właśnie ta statystyka mnie zainspirowała do tego, aby do bazy iSeries DB2 spróbować poszukać podobnego rozwiązania. Na razie nie znalazłem tego jako gotowy kawałek, jednak znalazłem narzędzia w iSeries, które pomogły coś takiego uzyskać. Znaczenie więcej dostaje się z tabelek systemowych. Oto przykłady:

Otwarcie i zamknięcie obiektów

Statystyka operacji zmiany ze względu na rodzaj

Rodzaje operacji odczytu

Każdy z tych wykresów był kluczowy podczas analizy optymalności pracy aplikacji, szczególnie pod dużym obciążeniem. Patrząc na system jako czarna skrzynka, te parametry to kluczowe wyznaczniki złożoności operacji. Można to skorelować z operacjami logicznymi systemu. Z odczytów możemy odczytać czy zapytania są wykonane optymalnie. Zbyt duże wartości odczytów w najbardziej trywialnym przypadku może oznaczać brak index-ów. Można być też przyczyną nieoptymalnej implementacji procedur na bazie.
Trochę więcej można się dowiedzieć analizując w krótkich okresach czasu wybrane obiekty.
Na temat samych procesów można też się co nieco dowiedzieć.

Typy job-ów z iSeries

Wielkość kolejki komunikatów dla zadań określonego typu.

Openfire

Po dłuższym okresie użytkowania aplikacji Openfire, okazało się że serwer na którym jest uruchomiona miewa mocne zadyszki i na maszynie wirtualnej powoduje zamięszanie. To był więc opiszę więc moją przygodę z openfire .jeden z motywów aby podłączyć tę aplikację do monitorowania wydajności. Okazało się że sam monitor jmx java niewiele mówi, a mechanizmy, które są dostępne nie pokazują tego co chciałem. Na tyle dużo się tego zrobiło że postanowiłem z tego zrobić oddzielny rozdział pod tytułem Zabbix - Openfire monitoring

Raporty z aplikacji

Po jakimś czasie znalazłem nietypowe zastosowanie dla Zabbix. Czasem dobrze widzieć w tym samym miejscu rzeczy z systemu oraz z aplikacji. Ja wybrałem raporty przez JMX dlatego że dla mnie stworzenie interface komunikacji z Java było wyjątkowo proste. Na pierwszy ogień poszedł system autoryzacji.

Tokeny związane z autoryzacja w ciągu dnia.

Statusy operacji autentykacji (Operacji na minutę. Odpowiednio Z - zalogowanie, W - wylogowanie, T - blokada tymczasowa, P - hasło wygasło, O - błędne konto/hasło, E - blokada konta) 

Co ciekawe przy zasilaniu takimi danymi nawet na Zabbix da się wykryć próby łamania haseł. Mając te dane historycznie można łatwo to wyśledzić w postaci obrazków. Użyteczne a niewielkim kosztem.