Artykuł stanowi zapis sesji pytań i odpowiedzi po trzecim polskim Zabbix MeetUp, który odbył się 8 listopada 2021 roku. Sesję prowadzili pracownicy Działu Monitoringu i Projektów Rozwojowych w Aplitt, z wieloletnim doświadczeniem w pracy z Zabbixem: Robert Szulist i Mateusz Dampc.

Mateusz: Wartość typu sekret tekst jest trzymana jako plaintext w bazie danych samego Zabbixa, więc każdy, kto ma dostęp do bazy Zabbixowej może podejrzeć to hasło. To tylko we frontendzie jest niewidoczne. A jeśli chodzi o wsparcie sekretów w makrach dla passwordstate, key vault bądź KeePass – nie, tylko i wyłącznie HashiCorp secret Engine version 2. Możemy je zaszyfrować SSL i się do tego tak odwoływać.

Robert: Jeszcze co do pierwszego pytania i szyfrowania sekretów w bazie, to niestety, tak jak Mateusz wspomniał, nie ma aktualnie takiej opcji. Natomiast można poprosić swojego administratora baz danych, żeby on to zaszyfrował w ramach całej bazy. Natomiast głównym motywatorem tych sekretów było to, że załóżmy mamy kilku administratorów Zabbixa, 5 osób z różnych działów i jedna osoba nadzoruję konkretną rzecz, a reszta ma dostęp, powiedzmy sobie read-only. Idea była taka, że osoba, która konfiguruje ten monitoring i dostarcza hasło, chce to hasło ukryć przed pozostałymi we frontendzie. Więc żeby było mniej widoczne dla pozostałych, jest to widocznie trochę security by obscurity, ponieważ ktokolwiek ma dostęp do bazy danych i tak to hasło zobaczy. Jednak sam fakt, że o wiele mniej osób zobaczy to hasło no to…

Mateusz: Trzeba się trochę bardziej namęczyć, żeby to zrobić.

Mateusz: Makra same w sobie nie mogą być sumowane, chyba że bezpośrednio w trybie calculated i wykorzystując w tym momencie aggregate checks. Czyli, że sumujemy z konkretnej liczby hostów w danej grupie z pasującym konkretnie znacznikiem. Możemy sumować wartości, które są na danej pozycji. Chyba na takiej zasadzie bym na to odpowiedział.

Robert: Ja bym odpowiedział tak samo. Na makrach nie można wykonać operacji matematycznych, jeżeli o tym mówimy. Natomiast makra można konkatenować w ramach dajmy na to, klucza, więc jeśli w parametrze klucza dwa makra są obok siebie, to Zabbix po prostu te makra rozwinie – będą dostępne jako jeden długi tekst. Mieliśmy taki fajny use case à propos tego, że w starych wersjach Zabbixa makra były dosyć króciutkie, jeśli chodzi o przechowywanie. To było chyba 255 znaków, natomiast tokeny JWT są znacznie dłuższe i nie można było ich przechowywać wprost w bazie. W związku z czym, chłopaki po prostu podzielili to na 6 czy więcej makr i tak konkatenowali, jak w parametrze klucza. Odpowiadając z kolei na szablony Windowsowe, to tutaj tak naprawdę nie jest problemem to, że te makra będą niedostępne, większym wyzwaniem jest to, że Discovery ogranicza nas na tak dobrą sprawę, ponieważ aktualnie kryterium unikalności w Zabbixie jest klucz pozycji. W związku z czym, nie możemy mieć kilku Discovery, które mają ten sam klucz. To skutecznie utrudnia tworzenie iluś tam szablonów, gdzie każdy ma inny zestaw usług. Natomiast żeby to obejść, możemy posłużyć się polem „Alias” w agencie. Możemy „zaliasować” sobie ten klucz do Discovery Service Windowsowych i w ten sposób obejść ograniczenie unikatowości klucza i w tym momencie możemy mieć szablon dla usług iOS, MMSQ etc.

Mateusz: Dodam tylko, że od Zabbixa 5.2 (jeśli się nie mylę), wartości makr mają zwiększoną liczbę znaków, wcześniej było to 256, teraz 2048.

Robert: Tak, wykorzystałem to podczas jednego z wcześniejszego MeetUp’ów, gdzie trzymałem tam Access Token do Kubernetesa. Zachęcam do obejrzenia tamtej prezentacji!

Mateusz: Czyli – mniej więcej coś takiego, jak Robert tu nam dzisiaj zaprezentował. I warto też wspomnieć, że można przejrzeć listę wszystkich wspieranych kluczy natywnych na oficjalnej dokumentacji Zabbixa. Dlatego w tej sytuacji odwołałbym się bezpośrednio do dokumentacji Zabbixa Agent 2.

Robert: Nie robiłem ekstremalnych testów obciążeniowych, powiem szczerze. Natomiast jeżeli chodzi o Agenta 2, to on jest odrobinkę bardziej pazerny na pamięć. To się bierze stąd, że tak jak wspomniałem, jest kolejka sprawdzeń dla samego Agenta, również dla każdego z pluginów osobno. To wymaga większej ilości RAM. Natomiast nie jest to coś, co jest jakieś strasznie makabryczne. Przynajmniej przy aplikacjach, w których przypadku korzystam osobiście. Natomiast może być tak, że ktoś trafi na jakiś skrajny przypadek. Będąc w temacie, pozwolę sobie dopowiedzieć, à propos zasobożerności właśnie, jest jeszcze jedno kryterium wyboru między Agentem 1 i 2– bugi założone w Bug Trackerze Zabbixa. W związku z tym, że baza kodu jest zupełnie inna, to te Agenty będą miały różne problemy, więc może być tak, że któryś będzie w swojej wersji bardziej zasobożerny, a drugi takich problemów mieć nie będzie. Dlatego też starajmy się obserwować.

Robert: Pobawiłem się klastrowaniem w wersji Alpha 5. Weźcie pod uwagę to, że to wersja Alpha, niekoniecznie musi być reprezentantem tego, co będzie w produkcji, natomiast jestem przekona-ny, że jest to w 95% zgodne, tym bardziej że na roadmapie zaznaczone jest jako wykonane. Kla-strowanie jest dosyć ciekawe, ponieważ nie spotkałem się z takim mechanizmem do tej pory. Za-zwyczaj mieliśmy do czynienia z klastrowaniem typu failover. Wtedy ta komunikacja między nodami odbywała się za pomocą sieci. Natomiast tutaj sprawdzenie statusu odbywa się przez bazę danych, więc każdy z nodów na bieżąco mówi o swoim stanie do bazy danych i na podstawie tego, co w tej bazie danych się znajduje, jest elektowany nowy lider w przypadku padnięcia konkretnej usługi. Co też implikuje, wszystkie nody piszą i czytają do tej samej bazy danych. Natomiast tylko jeden z ser-werów, czyli ten Active będzie zbierał dane i je zapisywał. Bardzo ciekawie to jest rozwiązane. Jest spoko zrobione też to, że możemy sobie ustawić, jak czuły ma być zrobiony klaster na failover. Więc mamy zahardcodowane rejestrowanie swojego statusu co 5 sekund, no i jeśli konkretny Active przez pewien czas nie będzie mówił, że działa, no to będzie failover i jakiś inny node, który jest w standby, przyjmie jego funkcję. Domyślnie ta wartość wynosi jedną minutę. Natomiast może być skonfigurowana i może wynosić od 10 sekund do 15 minut. Jeśli ktoś potrzebuje, aby ten proces wystartował trochę później, to jak najbardziej może to zrobić.

Mateusz: Tutaj bardzo prostym i przydatnym rozwiązaniem jest zależność pomiędzy wyzwalaczami. W języku angielskim to będzie trigger dependency. Czyli jak mamy konfigurację danego hosta, danego wyzwalacza, wtedy definiujemy, który wyzwalacz jest zależny od jakiego, np. ping, jeśli nie mamy na niego odpowiedzi, w tym momencie wszystkie inne alerty są zależne od tego – więc się nie pojawią, jeśli pojawi się alarm o pingu. Albo można wyłączyć sobie powiadomienia dźwiękowe, to też jakaś opcja. Ewentualnie możemy wykorzystać usługę w Zabbixie – event correlation, ale jest to bardzo skomplikowana czynność. Dzięki niej może zostać wymuszone zamknięcie problemu w momencie, gdy inny problem wystąpi, np. konkretnym tagiem.

Robert: Korelacja zdarzeń bazuje na tagach, więc jeśli mamy nowe zdarzenie z konkretnymi tagami to na podstawie korelacji, jeśli te tagi pasują, to możemy zamknąć starsze zdarzenie albo nowe, etc. Tutaj występuje pewien problem, ponieważ wyrażenia triggerów są ewoluowane za każdym ra-zem, kiedy jakaś pozycja, która jest użyta w tych wyzwalaczach, zbierze wartość. Może niestety zdarzyć się tak, że najpierw dostajemy wartość o tym, że nie działa usługa, np. MySQL, a dopiero po dwóch sekundach dostaniemy informację, że nie działa ping do hosta. Dzięki czemu informacja o braku działania MySQL będzie starsza. Czemu to jest ważne? Jeśli nasza definicja do korelacji zda-rzeń nie jest dobrze sformułowana, to możemy mieć bajzel z alertami na frontendzie.

Mateusz: Mogą flapować.

Robert: Tak, może być to bardzo nieprzyjemne. A po drugie, jest znany problem z korelacją zdarzeń taki, że jeśli występują blisko siebie, jedno po drugim, to niestety ta korelacja troszeczkę głupieje i niekoniecznie będzie działać, tak jak chcemy.

Mateusz: Tak, preferowałbym bazowanie na trigger dependencie, czyli zależności wyzwalaczy. Możemy się odwołać do innego hosta, jeśli na danym hoście nie działa na nim ping, np. do switcha to możemy sobie tak to właśnie definiować i łączyć.

Robert: Pan dopytuje jeszcze na temat dependency. Jest prawdą, że może najpierw wyskoczyć brak dostępu do MySQL, a potem dopiero brak pinga, natomiast brak pinga jest wyżej w hierarchii, dlatego będzie widoczny, a brak dostępu do MySQL będzie ukryty.

Robert: Problem polega na tym, że to nie jest kwestia silnika bazy danych, ponieważ powinniśmy używać tego, na czym się znamy. Załóżmy, że jest 1% wzrost wydajności pomiędzy Postgres i MySQL, to nie będziemy migrować z jeden bazy na drugą tylko dlatego, że jest 1%, ale nikt tego rozwiązania nie zna. To strzał w stopę. Natomiast przy dużych środowiskach trzeba się skupić na partycjonowaniu. Przy naprawdę dużej bazie danych, mamy z tym doświadczenie, najwęższym gardłem są IOPS-y na storage. Zaraz potem są bolączki z housekeeper’em. Tak naprawdę, jedynym rozwiązaniem jest wyłączenie housekeeper’a. Jak już to zrobimy, to baza danych będzie rosła w nieskończoność, co jest średnio pożądane. Jedynym sensownym rozwiązaniem, aby tego uniknąć, jest partycjonowanie bazy danych. Tu pojawiają się dwie opcje. Po pierwsze: można użyć partycjonowania w MySQL, które działa bardzo fajnie, nie powiem, że nie, a drugą opcją jest na Postgresie użyć TimescaleDB, które jest bardzo ładnie wspierane w Zabbixie, wspiera kompresowanie, etc. Ma swoje własne bolączki, ale tutaj nie będę się nad nimi rozwodzić.

Robert: Zależy. TimescaleDB pozwala na dużo fajnych rzeczy: partycjonowanie, kompresję danych, etc. Też ma własne bolączki, np. podczas update’a trzeba te wszystkie dane odkompresować, ponieważ edycja schemy nie jest wspierana na skompresowanej bazie. Tutaj możemy mieć pewien problem z maintenance. Na czas update’u trzeba dać sobie więcej storage’a, potem to zwinąć… generalnie mogą być problemy.

Mateusz: Natomiast jest zwiększony performance, dane są kompresowane, więc np. jeżeli mamy bazę danych wielkości 250 GB, możemy zredukować je do 40 GB. Tak jak Robert wspomniał, jeżeli wykorzystujemy kompresję danych, to nie możemy zmodyfikować ani usunąć typowo wartości, które są skompresowane, tylko trzeba je odkompresować. Na pewno można to zautomatyzować.

Robert: Wszystko można!

Robert: Jeszcze omówmy bugi. Agent oryginalny jest programem starym i stabilnym. Raz na jakiś czas dodane są różne funkcjonalności, a język C rządzi się swoimi prawami, a język Go swoimi. Zdarza się tak, że ktoś, przypisując część funkcjonalności z C na Golanga, zrobi jakiś błąd. W związku z czym, rozwiązanie, które działa bez problemu na oryginalnym Agencie, będzie powodowało problem na Agencie drugim. Przykładem jest, że niektóre zapytania WMI w Agencie drugim niespecjalnie działały i potrafiły wysycić… nie pamiętam czy to powodował crash samego Agenta, czy to była wina zżerania nierozsądnych ilości zasobów. Tak czy siak, Agent oryginalny był tym problemem nieskalany, mimo to, że również tę funkcjonalność dostarczał. Jeśli planujemy przejść na 2, a wie-my, że będziemy monitorować konkretną rzecz, może lepiej sprawdzić, czy wersja, na którą przechodzimy, będzie w stanie ją dobrze monitorować. Oczywiście pilotaż jest wskazany, ale też warto zrobić rekonesans wcześniej.