Artykuł stanowi zapis sesji pytań i odpowiedzi po pierwszym polskim Zabbix Meetup, który odbył się 9 listopada 2020r. Sesję prowadzili pracownicy Działu Monitoringu i Projektów Rozwojowych w Aplitt: Robert Szulist i Mateusz Dampc.

Robert Szulist: Frontend odpowiada za trzy rzeczy: wizualizację danych, konfigurację środowiska Zabbix oraz dostęp do API, więc generalnie – nie ma API bez frontendu.
Najtrudniejszą sprawą będzie dostęp do dużych ilości danych. Jeżeli posiadamy jakieś dashboardy, które wyświetlają np. wszystkie pozycje hosta, to będzie to działało po prostu wolno i należy takie dashboardy albo wyciąć, albo podzielić na mniejsze.

W kontekście API – warto więcej rzeczy robić w jednym zapytaniu niż w kilku mniejszych, ponieważ każdy handshake „ubija” nam serwer. W przypadku konfiguracji środowiska: w momencie, kiedy mamy np. szablon, który chcemy podpiąć do jakiejś liczby hostów to ogranicza nas to, ile pamięci ma nasz subserwer, gdyż pamięć ta może się już skończyć i podpięcie szablonu się po prostu nie uda. Warto więc wykonywać takie operacje dzieląc to na porcje.

Mateusz: Myślę, że odpowiedni hardware, odpowiednia konfiguracja potrafią załatwić sprawę.

Robert: Nie tylko to. Musisz wziąć pod uwagę zalogowanych użytkowników. Jeżeli masz jegomościa, który robi sobie jakiś skrypt, który puka do API, loguje użytkownika, którego później nie wylogowuje, to w tym momencie rośnie tabela sessions, a to zawsze ma negatywny wpływ. Podobnie, jak masz te trzy podstawowe dashboardy Zabbixa – więc jeżeli wiemy, że mamy użytkowników, którzy mają tendencję do tworzenia jakiś monstrualnych dashboardów albo dziwnych raportów itp. to lepiej ich odesłać do Grafany albo gdzieś na boku odwijać bazę danych, bo to będzie skuteczniejsze.

Mateusz: Tak, zdecydowanie. Tak jak wspominałem podczas swojej prezentacji, jeśli korzystamy z API, pamiętajmy o wylogowaniu użytkowników, aby nie zapychać tabeli sessions. Podsumowując, jeżeli chodzi o optymalizację frontendu to pamiętajmy właśnie o tym.

Robert: A, jeszcze jedna informacja! W temacie tych użytkowników – poza tymi rekomendacjami, o których mówiłeś, to, warto to podkreślić, jest max.15 użytkowników zalogowanych do frontendu. Więcej zalogowanych użytkowników może już być problematyczne.

Mateusz: To jest bardzo dobre spostrzeżenie. To należy zaznaczyć – maksimum to 15 użytkowników. Jeśli nie mamy tej możliwości, jeżeli mamy bardzo dużą infrastrukturę, gdzie mamy np. bardzo dużo osób, które korzystają z dashboardów Zabbixa, warto byłoby zastanowić się nad tym, aby tych użytkowników zastosować w Grafanie albo w jakimś innym narzędziu (chociaż Grafana jest najbardziej popularna) i żeby po prostu to tam były przechowywane te dane.

Mateusz Dampc: Nie. Zabbix wspiera dwa serwery www – Apache oraz NGINX. NGINX jest trochę bardziej skomplikowany, chociaż to wszystko może być kwestią przyzwyczajenia. Jednak NGINX daje możliwość 2,5 razy większych osiągów niż Apache, stąd jest taka rekomendacja, aby częściej korzystać właśnie z tego serwera www.

Robert: A ja się nie zgodzę. Zgodzę się z tym, żeby używać NGINXa, bo to jest oficjalna albo półoficjalna rekomendacja samego Zabbixa, natomiast frontend pójdzie dosłownie na wszystkim, co wspiera najnowszego php’a. Pójdzie Ci to na LightHTTP, bądź nawet IIS’ie, czy to na NGINX jest czy na Apache

Mateusz: Tak, zdecydowanie tak. Bardziej miałem tutaj na myśli aktualne paczki, które Zabbix sam wspiera.

Robert: A tak, instalowane statycznie są tylko dla NGINX i dla Apache

Mateusz: Tak, taki miałem zamiar, ale dziękuję, że rozwiałeś wątpliwości innych Państwa.

Mateusz: Owszem, wszystkie bazy danych bazujące na MySQL są jak najbardziej wspierane.

Robert: Jak mamy support u nich – to tak ;).

Mateusz: Cóż, Robert chyba odpowiedział tutaj dość dobitnie.

Robert: Niestety, taka wiedza kosztuje, zwłaszcza optymalizacyjna, chociaż nie jestem przekonany czy w dokumentacji nie ma słowa lub dwóch. O MySQL na pewno jest coś tam wspomniane, natomiast PostgreSQL nie używamy, nie zdarzył nam się jeszcze Klient z Postgresem.

Mateusz: Właśnie, więc tutaj chcielibyśmy zaznaczyć, że niestety, na razie nie mamy jeszcze doświadczenia, chociaż, jak najbardziej, będziemy się w to zagłębiać. Postaramy się – może w następnym artykule o Zabbixie, bądź na następnym spotkaniu.

Robert: Generalnie backend Zabbixa obsługuje aktualnie MySQL’a oraz jego wszystkie forki, Oracle i PostgreSQL oraz TimeScaleDB. Do wersji 5.0 wspierany był również IBM DB2, jednak to była jakaś niszowa pula użytkowników, więc ten pomysł został zarzucony. I to są te bazy, które są wspierane jako backend dla Zabbix Serwera, dla Zabbix Proxy jest wszystko to samo plus jeszcze jest SQLite – to jeżeli chodzi o to, z czego korzystają daemony. Natomiast jeżeli chodzi o zbieranie danych, to Zabbix jest w stanie natywnie zebrać dane wszystkiego, do czego jest tylko sterownik ODBC.

Mateusz: W zasadzie ElasticSearch pojawiło się pierwszy raz w wersji Zabbix 4.0 LTS. Od tej wersji jest taka natywna możliwość wykorzystania tej bazy, lecz jest to wersja eksperymentalna. Ani Zabbix, ani my osobiście nie rekomendujemy tego sposobu, ale potrafi on przyspieszyć pracę Zabbixa.

Robert: To, co jest bardzo ważne – tak jak wspomniałeś – jest to eksperymentalna opcja, a po drugie oprócz Elastica i tak potrzebujemy relacyjnej bazy danych na potrzeby trzymanej konfiguracji. Toteż o ile dane wpłynęły nam elegancko do Elastica, o tyle konfiguracja i tak będzie trzymana w bazie relacyjnej. Więc technicznie można powiedzieć, że mamy dwie bazy danych.

Mateusz: Tak, więc musimy z tym uważać. Backupy trzymać w osobnej bazie? Nie rekomendujemy tego. Ale może to przyspieszyć oczywiście naszą pracę.

https://aplitt.pl/zabbix-meetup-online-zapis-sesji-qa-cz-2/

https://aplitt.pl/zabbix-meetup-online-zapis-sesji-qa-cz-3/