2 Zabbix MeetUp Online – zapis sesji Q&A cz.2
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.
Z tego artykułu dowiesz się:
- Kiedy warto korzystać z Zabbix Agenta, a kiedy z Zabbix sendera
- Czy Zabbix może służyć do zbierania logów
- Jak zautomatyzować tworzenie map topologii infrastruktury
- Co zrobić z koniecznością wyświetlania dashboardów 24h
- Housekeeper a trzymanie danych pre item
- Weryfikacja danych zbieranych w trakcie sekundy
Jak można w systemie najlepiej zautomatyzować tworzenie map topologii infrastruktury? Czy da się jakoś wykorzystać LLDP lub CDP?
Mateusz: Jak się domyślam, chodzi o protokół CDP, zastosowany w Cisco. Zabbix sam z siebie nie ma możliwości wytworzenia topologii sieciowej. Oczywiście, można spróbować. Gdybym ja miał takie zadanie, próbowałbym wytworzenia itemów pod discovery z komend SSH, które po prostu wykonałyby polecenie CDP, do CDP i tak jak Robert pokazał podczas swojej prezentacji, z przeparsowaniem tego poprzez JavaScript preprocessing do JSON’a i wykonanie prototypów hostów. Ja zrobiłbym to właśnie w ten sposób. Jak Ty byś to widział?
Robert: Nie wiem, czy nie pokusiłbym się o skanowanie tablicy ARP i złapanie tego do dodawania. To, co Zabbix potrafi robić z topologii, to potrafi zeskanować konkretną podsieć pod kątem, które hosty są up i down. Jest również w stanie się dobić do SNMP i na podstawie tego, jak ruch przechodzi przez które switche, bylibyśmy w stanie zrobić mapę hopek i opierając się o to narysować topologię.
Jak się ma housekeeper do trzymania danych per pozycja, per item?
Mateusz: Tak jak skonfigurujemy odpowiednio w konfiguracji pozycji ustawienia dla danych historycznych oraz trendów, tak takie dane, które będą już przestarzałe w bazie danych, housekeeper będzie usuwał. I to housekeeper jest uruchamiany co godzinę, dlatego może to powodować spadki wydajności. W momencie gdy korzystamy z partycjonowania bazy danych, mamy takie ograniczenie, że ustawiamy konkretne usuwanie konkretnych danych historycznych na sztywną wartość, czyli jeżeli mamy dane np. integer czyli numeryczne, i ustawimy np. 30-dniową retencję danych, to dla wszystkich pozycji typu integer (numeric) zostaną usunięte dane po 30 dniach. A jeżeli chodzi o housekeeper, to on usunie dane, które są przestarzałe, nie spełniają już odpowiedniego znacznika czasowego.
Robert: Generalnie, jeżeli chodzi o nieszczęsne partycjonowanie, jest wielka bolączka, że partycjonują się całe tabele i w pewnym momencie wszystkie hosty, które spełniają dany typ informacji mają ten sam okres retencji danych, więc jest to zasadnicza wada tego podejścia. Natomiast przyspiesza mocno bazę danych i czasami jest to jedyne wyjście i mniejsze zło. Jednak, jeżeli mnie pamięć nie myli, to Zabbix mówi, że partycjonowanie trzeba wykonać na bazach, które są duże, mamy na myśli powyżej 500 GB na dane. Więc generalnie jeżeli mamy poniżej 500 GB jako taki arbitralny pułap to możemy się obudzić bez partycjonowania. I wtedy możemy tak naprawdę mieć retencję różną dla różnych pozycji.
W jaki szybki sposób można zweryfikować, które dane są zbierane w ciągu jednej sekundy?
Mateusz: Proponuję poprzez API. Metoda item.get z odpowiednim filtrem np. update interval 1s pozwoli na wyfiltrowanie wszystkich itemów, które mają taki interwał aktualizacji. Myślę, że to jest najszybszy i najprostszy sposób, żeby to zweryfikować.
Robert: Tak, ale niepełny, ponieważ masz w Zabbixie pozycje typu pułapkowego, więc masz SNMP trapy, Zabbix trapy…
Mateusz: SNMP trapy, Zabbix trapy…
Robert: Tak, to powiedziałem. Jeszcze trzeci był gdzieś tam po drodze (przyp. red.: HTTP agent – przy odpowiedniej konfiguracji oraz agent active). I generalnie, te pozycje nie mają interwałów aktualizacji, więc sprawdzanie tego nie jest podstawą, by wnioskować, ile naprawdę tam tych danych wpada. Zasadniczo pełniejsze rozwiązanie to kwerenda w bazie danych, która sprawdza konkretny stan, po ile tam jest wpisów.
Mateusz: Tak, to jest dużo lepszy sposób w zasadzie…
Robert: Tak, tylko, że tu też jest taki problem, że od Zabbixa 5.0 jest throttling dla metryk, więc jeśli coś nam tam wpadnie w złe okienko, to nawet nie zostanie to zapisane do bazy danych, więc w tym momencie nawet sprawdzenie aktualnej pozycji kwerendy w bazie danych nie jest pełną odpowiedzią, bo trzeba byłoby w tym momencie mieć to plus to spakowane przed throttlingiem. Więc to jest taki, powiedziałbym, śliski temat, bez konkretnej odpowiedzi.
Mateusz: Niestety. Jeżeli chcemy, pytamy o typy agentów typu pulling np. typy pozycji typu pulling, to właśnie można spróbować poprzez API. Niestety, nijak ma się to do pułapek.
Jak się ma wydajność Zabbixa przy użyciu PostgreSQL plus TimescaleDB w porównaniu do partycjonowania MySQL?
Mateusz: Szczerze powiedziawszy – nie wiemy. Nie będziemy tutaj tego ukrywać. Tak jak to przedyskutowaliśmy wewnętrznie, pomiędzy sobą, prawdopodobnie to będzie jeden z takich tematów, który przygotujemy i poruszymy w kolejnym artykule, więc obserwujcie naszego bloga.
Czy Zabbix dostarcza przykładowe parametry optymalizacyjne dla PostgreSQL?
Robert: Jak mamy support u nich – to tak (śmiech).
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.
Kiedy warto stosować Agentów a nie korzystać z Zabbix sendera? Kiedy to my sami decydujemy o ilości przesyłanych danych?
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.
Od której wersji jest możliwość dodania bazy ElasticSearch?
Robert: W zasadzie, bardzo mocno zależy to od naszych potrzeb, ponieważ Agent został zaprojektowany i służy głównie do zbierania danych z hostów, gdzie Agent może ruszyć. Nawet niekoniecznie musi być zainstalowany, wystarczy binarkę odpalić, np. można uruchomić ją z CLI i nie musi chodzić jako daemon, więc w tym momencie, tak naprawdę Agenty są wskazaną opcją, jeśli chodzi o uruchomienie tego. Pytanie czy aktywny, czy pasywny tryb dla pozycji to już jest troszeczkę inna historia. Natomiast Sender został stworzony po to, żeby można było monitorować wnętrze, jakieś rzeczy, gdzie nie ma opcji odpalenia Agenta. Fajnym przykładem jest to, że Sender jest taką rzeczą, którą można wpakować tak naprawdę w skrypty nasze. Załóżmy, że mamy jakiś skrypt, który się dokonuje N czasu i ma tam ileś kroków, więc co każdy krok możemy odpalić Sendera, żeby wysłał informację do Zabbix serwera i wtedy wiemy, czy nasz skrypt działa planowo, czy jest na konkretnym kroku, czy też np. jakiś błąd go po prostu zabił albo, że po prostu nie działa. Więc, gdzie Agent nie może tam Sendera pośle, tak bym to określił. I tak jak już wspominałem, to Sender jest stworzony głównie z myślą monitorowaniu przebiegu skryptu.
Czy Zabbix może nam służyć jako centralny punkt do zbierania logów, jako syslog z opcją ich przeszukiwania czy eksportu?
Mateusz: Nie. Zdecydowanie nie. Duża ilość danych tekstowych, to jest przetwarzanie danych, może to złe określenie, ale to „zaśmiecanie” bazy danych przez co Zabbix będzie działa po prostu wolniej. Nie rekomendujemy tego, lepiej wykorzystać np. ElasticSearch’a, coś w ten deseń, ale Zabbix nie służy jako zbieracz logów.
Robert: Taka ciekawostka – ostatnio sprawdzałem na roadmapie Zabbixa 6.0, że upchną tam też zbieranie logów. Więc aktualnie to jeszcze nie istnieje, ale jak będzie 6.0 to być może tak.
Czy zamiast korzystania z dashboardów na frontendzie Zabbixa, korzystamy z Grafany?
Mateusz: Tak. Im mniej użytkowników tym lepiej.
Skoro Zabbix nie lubi użytkowników trzymających długo sesję, to jak sobie poradzić z koniecznością wyświetlania dashboardów przez 24 godziny na video wall w centrum monitoringu?
Mateusz: Jak już wspomniałem, najlepiej zastosować Grafanę. Ewentualnie wytworzyć użytkownika typu zwykły użytkownik Zabbixa, jako konto serwisowe i po prostu w centrum monitoringu go tak ustawić, aby każdy mógł działać na tym samym użytkowniku.
Robert: Może niekoniecznie każdy na tym samym użytkowniku, ale generalnie jest tak jak mówisz. Na przykład, jeśli ktoś nie musi korzystać z dashboardów Zabbixa, niech korzysta z Grafany. Tylko taka gwiazdeczka, żeby ta Grafana nie była odświeżana co sekundę, bo to też Zabbixa oczywiście zabije.
Mateusz: Bo to też się komunikuje po API albo po bazie danych.
Robert: To nie jest dobry sposób, tak swoją drogą.
Czy Agent pasywny odpytuje o wszystkie itemy naraz czy item by item?
Mateusz: Item by item, pozycja przez pozycję.
Robert: I to jeszcze nie ten kierunek, bo Agent pasywny jest odpytywany przez serwer, a nie że serwer odpytuje. I do tego pytania jeszcze wrócimy przy okazji pytania zadanego ze skryptami zewnętrznymi, bo to też jest powiązanie w miarę ciekawe.
KONIEC CZĘŚCI DRUGIEJ. KOLEJNA CZĘŚĆ SESJI Q&A:
Podziel się treścią: