Czym jest Zabbix? Podstawy konfiguracji

Monitoring infrastruktury IT jest w dzisiejszych czasach dużym wyzwaniem. Od takich oczywistości, jak dostępność serwerów czy infrastruktury sieciowej, a kończąc na  poziomie naładowania UPS lub czy drzwi są otwarte w szafach rackowych. Mnogość urządzeń i sposobów ich monitorowania często prowadzi do sytuacji, że wdrażamy kilka niezależnych rozwiązań monitoringu, co po pewnym czasie jest bardzo kłopotliwe. Rozwiązaniem takiego stanu rzeczy jest oczywiście Zabbix.

Artykuł omawia absolutne początki z tym oprogramowaniem – od wyjaśnienia, czym jest zabbix, do wstępnego planowania zasobów na jego potrzeby. Zaczynamy!

O zabbixie słów kilka

Zabbix to rozwiązanie (nie bójmy się tego powiedzieć) klasy enterprise obsługi problemów z monitoringiem. Służy do zbierania, analizowania i wizualizacji danych. Oprogramowanie potrafi również wykryć wszelkie anomalie w naszej infrastrukturze i powiadomić o tym odpowiednio użytkownika.

Twórca zabbixa, Alexei Vladishev, stworzył pierwszy zarys aplikacji, gdy w 1998 potrzebował narzędzie do monitoringu w firmie, gdzie pracował. Na początku były to proste skrypty napisane w perlu, jednak twórca szybko zmienił język programowania na C. Dodatkowo napisał front-end w języku PHP i w roku 2004 wypuścił pierwszą stabilną wersję – 1.0. Twórca w jednym z wywiadów opowiada również skąd się wzięła nazwa – wymyślał losowe słowa i sprawdzał w wyszukiwarce, czy są już zarezerwowane. Niestety słowo “Zabbix” nie kryje żadnego większego znaczenia.

Rysunek 1. Zabbix 1.1.6 Alpha6 – GUI źródło: wikimedia.org.

W 2005 roku Alexei założył firmę Zabbix SIA, która, oprócz tworzenia nowych wersji oprogramowania, zajmuje się też wsparciem komercyjnym oraz szkoleniami.  

Dlaczego akurat zabbix?

Jest to bardzo często zadawane pytanie przez nowych użytkowników. Powodów jest co najmniej kilka:

• Jest darmowe! – Zabbix jest dystrybuowany na licencji GPLv2 – kod oprogramowania jest ogólnie dostępny i może on być wykorzystywany do rozwiązań komercyjnych.
• Ogrom metod monitorowania – oprócz monitorowania hostów za pomocą natywnych agentów, możemy wykorzystać różne protokoły, m. in. SNMP, SSH, TELNET, IPMI, JPX, HTTP/HTTPS itp. Dorzucając do tego możliwość uruchamiania skryptów – “sky is the limit!”.
• Stabilne oprogramowanie –  czasy młodości zabbix ma już dawno za sobą. Dodatkowo Zabbix posiada wersje LTS (Long Time Support) która idealnie nadaje się na środowisko produkcyjne.
• Dobre community – twórcy stworzyli stronę, na której ludzie mogą udostępniać swoje metody monitoringu (głównie za pomocą gotowych szablonów i skryptów). Dodatkowo twórcy udostępniają bardzo bogatą dokumentację. Jeżeli masz problem z angielskim, zawsze możesz zmienić język na polski, jednakże trzeba brać pod uwagę fakt, że tłumaczenie wykonano dla dość starej wersji – 2.2, przez co dużo rzeczy może być nieaktualnych.
• Agregacja i wizualizacja danych – zabbix dobrze spisuje się jako narzędzie do zbierania danych o naszym środowisku, aby potem móc to przedstawiać w formie wykresów czy map. Jeżeli jednak to nam nie wystarcza, możemy podpiąć inne rozwiązania do wizualizacji, np. grafana.

Rysunek 2. Przykład mapy źródło: secretwafflelabs.com.

Podstawowa teoria

By móc dobrze zaplanować potrzeby naszego środowiska monitoringu, musimy znać podstawowe pojęcia związane z zabbixem. Na początku zacznijmy od tzw. “trójpodziału władzy”:

• zabbix-server – jest to centrum oprogramowania zabbix; właśnie ten proces odpowiada za odbiór danych, wykrywaniu anomalii, wysyłaniu powiadomień do użytkowników itp.,
• Baza danych – miejsce, gdzie zabbix-server zapisuje wszystkie odebrane dane oraz wszelką konfigurację dostępną z poziomu interfejsu użytkownika,
• Front-end – strona WWW, gdzie użytkownik może skonfigurować wszelkie sprawdzenia oraz zwizualizować dane zapisane w bazie danych.

Schemat połączeń przedstawia Rysunek nr 3. Warto wspomnieć, że połączenie pomiędzy front-endem a zabbix-serverem jest wykorzystywane sporadycznie np. przy wyświetlaniu aktualnego stanu usługi zabbix-server czy przy wyświetlaniu aktualnego stanu kolejki sprawdzeń. Na schemacie wszystkie 3 usługi są uruchomione na tym samym hoście, jednak nic nie stoi na przeszkodzie, by każdą z nich uruchomić na osobnych serwerach.

Rysunek 3. Schemat połączeń.

Innymi ważnymi podczas planowania definicjami są:

• NVPS (new values per second) – jest to średnia liczba nowych wartości na sekundę, jakie otrzymuje zabbix,
• Historia – pojedynczy wynik jednego sprawdzenia (nieważne czy jest to liczba, czy tekst) jest zapisywany jako historia,
• Trend – by zaoszczędzić miejsca na dysku zabbix agreguje dane historyczne, zapisując z godziny wartości minimalne, średnie, maksymalne oraz ilość wartości w tej godzinie; oczywiście zabbix trzyma trend tylko z wartości liczbowych,
• Zdarzenie – głównym źródłem zdarzeń są zmiany statusu problemu (wyzwalacza); każda zmiana PROBLEM<->OK generuje zdarzenie, które przechowuje informację kiedy ona wystąpiła, czy jest potwierdzona itd.

Planowanie środowiska

Przy planowaniu środowiska zabbix musimy znać odpowiedzi na kilka pytań:

Jaka wersję zabbix powinienem wybrać?

Na to pytanie są tylko dwie poprawne odpowiedzi:

• Najnowsza – projekt zabbix jest aktywnie rozwijany, przez co przy kolejnych wersjach twórcy przedstawiają nam wiele nowych funkcjonalności; m.in. dzięki temu również zabbix jest szybszy poprzez ciągłą optymalizację kodu; w chwili pisania artykułu jest to wersja 3.4.4,
• Long Term Support (LTS) – jeżeli planujesz swoje środowisko zabbix jako bardzo krytyczne oraz stabilne, powinieneś pomyśleć o wersji LTS; w czasie publikacji artykułu jest to wersja 3.0.13.

Wszelkie dodatkowe informacje odnośnie wersjonowania można znaleźć na oficjalnej stronie.

Jaką bazę danych powinienem wybrać?

Twórcy zabbixa promują bazę MySQL wraz z silnikiem InnoDB (oczywiście nic nie stoi na przeszkodzie, by wykorzystać MariaDB), przez co ten typ bazy jest najlepiej udokumentowany, jak i również posiada wiele wskazówek na optymalizację (co w kwestii zabbixa jest bardzo ważne). Jednakże można zastosować również bazę PostgreSQL czy Oracle.

Jaki front-end powinienem wybrać?
W większości przypadków wystarczy proponowane przez twórców Apache. Możemy również wybrać nginx lub Lighttpd, jednak należy brać pod uwagę że, tak samo jak w przypadku bazy PostgreSQL czy Oracle, nie są to przypadki tak dobrze udokumentowane.

Czy myśleć o rozdzieleniu usług na 3 serwery?

Nie – rozdzielenie usług jest jedną z ostateczności jeżeli chodzi o brak wydajności. Bazę danych warto rozdzielić, gdzie przy dużej ilości danych baza działa coraz wolniej (mimo prób jej optymalizacji!). Wtedy można pomyśleć o osobnym serwerze z szybkimi dyskami SSD (stare przysłowie mówi – “źle zoptymalizowana baza danych nawet na SSD będzie mulić”).

Jeżeli planujemy ponad 100 użytkowników, z czego w najbardziej krytycznym momencie będzie ponad połowa zalogowana, można pomyśleć również nad osobnym serwerem dla GUI.

Jaki system operacyjny wybrać?

Linux. Są gotowe paczki (repo) dla systemów z rodziny RedHat (RHEL, CentOS, Fedora) oraz Debian i Ubuntu, ale nic nie stoi na przeszkodzie, by samemu na innym systemie skompilować Zabbixa ze źródeł. Zabbix wspiera również inne systemy UNIX np. FreeBSD. Niestety, ale zabbix-server nie zainstalujemy na Windowsie (ale agenta do monitorowania pracy tego serwera już tak!).

Jakie zasoby dobrać do serwera?

Jest to najczęstsze pytanie podczas planowania środowiska. Spójrzmy najpierw na część tabelki zaproponowaną przez twórców:

Tabela 1. Część rekomendacji zaproponowanej przez twórców źródło: zabbix.com.

Według powyższej tabeli głównym czynnikiem decydującym o wielkości środowiska zabbix to ilość monitorowanych hostów. Nie jest to efektywne podejście do planowania środowiska zabbix, ponieważ host hostowi nie równy. Przykładowo w konfiguracji jednego hosta możemy tylko sprawdzać co 30 minut, czy żyje (ICMP ping), natomiast inny host to produkcyjna baza danych, gdzie musimy zbierać mnóstwo statystyk o jego działaniu, najlepiej co 5-10 sekund. Dlatego lepszym pomysłem jest planowanie po wartości NVPS.

Warto przy planowaniu oszacować, jaka będzie wartość nowych wartości na sekundę. Przykładowo, przy 300 sprawdzeniach z interwałem 1 minuty otrzymamy – 300/60 = 5nvps.

Odświeżona tabelka powinna wyglądać następująco:

Tabela 2. Rekomendacje uwzględniające parametr NVPS.

Ile miejsca potrzebuje na środowisko zabbix?

Przy planowaniu miejsca na dysku należy pamiętać, że głównie musimy brać pod uwagę bazę danych ze względu na agregację danych. Reszta plików (zabbix-server i GUI w php) ważą bardzo mało (około 10-20 MB w zależności od wersji i systemu operacyjnego).

Przy obliczaniu przewidywanego miejsca bierze się wartości liczbowe (wartości tekstowe są teoretycznie nie do zaprognozowania, ponieważ ciągi znaków mogą być różnej długości i zajmować różną ilość bajtów). Przy liczeniu estymowanego miejsca bierze się największe tabele:

• Historia – zajmuje około 90 bajtów per wpis i wielkość liczy się od wartości NVPS; wzór na przyrost tabeli historycznej na dzień w zależności od nowych wartości na sekundę wygląda następująco (w nawiasach kwadratowych wyjaśniono, co znaczą dane wartości):
  
  H [MB/dzień] = NVPS*90[bajtów]*24[godziny]*3600[sekundy]/1024[zamiana na KB]/1024[zamiana na MB] = NVPS*7.5
• Trend – zajmuje bardzo podobną ilość miejsca (90 bajtów), jednak liczy się go od ilości wartości (nie od NVPS!) i łatwiej jest go wyliczyć na cały rok:
  
  T [MB/rok] = Ilość wartości*90[bajtów]*24[godziny]*365[dni]/1024[zamiana na KB]/1024[zamiana na MB] = Ilość wartości *0,75
• Zdarzenia – każdy alarm wygeneruje zdarzenie, które zajmie w bazie danych około 170 bajtów; Przy obliczaniu ilości miejsca oblicza się najgorszy scenariusz, czyli jedno zdarzenie na jedną sekundę (w praktyce w małych środowiskach jest to niemożliwe, jednak warto zakładać najgorszy scenariusz):
  
  Z [MB/dzień] =1[zdarzenie]*170[bajtów]*24[godziny]*3600[sekundy]/1024[zamiana na KB]/1024[zamiana na MB] = 14

Ogólne estymowane miejsce można obliczyć za pomocą wzoru:

Miejsce = H*t_H+T*t_T</+Z*tZ

Gdzie:

t_H – ilość dni w których chcemy trzymać historię,
t_T – ilość lat w których chcemy trzymać trend,
t_Z – ilość dni w których chcemy trzymać informację o zdarzeniach.

Warto nadmienić że baza będzie rosła z czasem – zawsze można założyć mniejszy dysk, a po pewnym czasie zwiększyć przestrzeń dla bazy. Dodatkowo należy przypomnieć, żeby nie trzymać się kurczowo wyżej wymienionych wzorów – jest to tylko podpowiedź, ile nasza baza danych może ważyć i przy ostatecznych obliczeniach zawsze przyjmuj nadwyżkę miejsca (około 20-30% powinno być ok).

Przykładowy plan środowiska

Warto wyżej wymienione porady pokazać na przykładzie. Załóżmy, że posiadamy środowisko przedstawione na rysunku nr 4.

Rysunek 4. Przykładowe środowisko.

Potrzebujemy zrobić analizę całego naszego środowiska krok po kroku. Na początku musimy wiedzieć, ile przewidujemy wartości oraz jak często będziemy je sprawdzać (by obliczyć NVPS):

• Serwer Apache – główna strona naszej firmy; serwer pracuje na dystrybucji Debian, więc podepniemy domyślne sprawdzenia dla systemów z rodziny Linux, takich jak CPU,dyski, RAM i karty sieciowe (przyjmujemy średnio około 50 wartości i 1 NVPS – wartość ta jest zależna od ilości podmontowanych systemów plików oraz kart sieciowych); dodatkowo chcemy intensywnie sprawdzać sam proces apache, pobierając dane np. ilości zapytań na sekundę, aktywne procesy apache itp. Zakładamy około 60 sprawdzeń po 30 sekund, co daje nam 60 sprawdzeń w ciągu minuty, więc 2 nową wartość w ciągu sekundy; łącznie daje nam 80 wartości i 3NVPS,
• Serwer PostgreSQL – główna baza danych firmy również postawiona na systemie Debian; oprócz standardowych sprawdzeń dla Linuxa (50 wartości i 1 NVPS) zakładamy dość szczegółowe (dodatkowe sprawdzenia dla każdej bazy, bardzo szczegółowe informacje na tabelach itp.) i częste sprawdzenia samej bazy (30 sekund): około 300 sprawdzeń da nam 10 NVPS; łącznie 350 sprawdzeń i 11 NVPS,
• 3 serwery aplikacyjne – aplikacje napisane przez programistów na środowisku Linux; oprócz standardowych sprawdzeń (3x 50 oraz 3x 1NVPS) szacujemy, że monitoring będzie wykonywał po około 100 sprawdzeń na każdą aplikację co 1 minutę (razem 300), co dla 3ch serwerów da nam 5NVPS; łącznie dla 3ch serwerów to 450 wartości i 8 NVPS,
• Switch – podłączone są do niego wszystkie serwery oraz komputery w firmie; interesują nas statystyki takie jak: Upload/Download wyrażonej w ilości bajtów/pakietów na sekundę oraz ilość błędów na poszczególnych interfejsach – dla switchy o 48 portach daje nam to 240 sprawdzeń; przy założeniu, że będziemy sprawdzać te informacje co 30 sekund, daje nam to 8 NVPS.
• Router – wyjście na świat dla naszej firmy; chcemy sprawdzać zarówno stan routera (temperaturę, stan poszczególnych interfejsów itp.) jak i stan naszego łącza do internetu (sprawdzenia polegające na odpytywaniu różnych stron w internecie); zakładamy około 240 sprawdzeń co 30 sekund, czyli 8NVPS.
• Serwer zabbix – tak, zabbix musi monitorować sam siebie! Oprócz standardowych sprawdzeń na linuxie (50 wartości i 1 NVPS) mamy jeszcze monitorowanie samego procesu zabbix-server (przy standardowym monitoringu jest to około 40 wartości i 1NVPS). Dodając jeszcze bardziej zaawansowany monitoring samej bazy danych, musimy oszacować jeszcze około 300 sprawdzeń co 30 sekund, czyli 10 NVPS; łącznie 390 wartości i 12NVPS.

Przy takich założeniach po dodaniu wszystkich wartości mamy około 1780 wartości oraz 50 nowych wartości na sekundę. Patrząc na tabelę nr 2 będziemy musieli założyć serwer już z procesorem dwurdzeniowym oraz 2GB pamięci RAM.

Nadszedł teraz czas na obliczenie spodziewanego zajętego miejsca. Do tego musimy dodatkowo założyć, ile dni będziemy trzymać historię, trend, oraz zdarzenia. Przy naszych obliczeniach wykorzystamy standardowe wartości przyjęte przez programistów Zabbix:

• Historia – 90 dni,
• Trend – 365 dni,
• Zdarzenia – 365 dni.

Mając już wszystkie potrzebne informacje, możemy w łatwy sposób obliczyć przewidywaną zajętość miejsca:

Miejsce = 50*7.5*90+1780*0,75*1+14*365=33750 + 1335 + 5110 = 40195 [MB]

Dodatkowo zakładając nadwyżkę miejsca (około 20-30%) powinniśmy spodziewać się, że zabbix zajmie około 50GB miejsca po roku.

Warto tutaj zwrócić uwagę na jeszcze jeden ważny czynnik, jakim jest wielkość poszczególnych tabel z danymi. Spostrzegawczy czytelnik zauważy, że najwięcej miejsca na dysku zajmuje tabela z historią, która jest zależna od nowych wartości na sekundę oraz ilości dni, w których chcemy ją trzymać. Gdybyśmy dla przykładu zmniejszyli ilość dni z 90 do 7, to tabela historyczna zmniejszy się z 34 do około 3GB! Natomiast  po zwiększeniu częstotliwość wszystkich sprawdzeń w naszej analizie do 1 min (pozostawiając 90 dni trzymania historii), uzyskalibyśmy około 31NVPS, co daje nam oszczędność około 13GB na dysku. Warto zatem zastanowić się (nie tylko na etapie projektowania, ale również dla istniejącego środowiska!) czy nie warto zmniejszyć tych dwóch parametrów, by znacząco zmniejszyć potrzebną ilość miejsca na dysku oraz odciążyć sam serwer zabbixa (mniej NVPS = mniej sprawdzeń = mniejsze zużycie zasobów).

Tabela z trendami jest zupełnym przeciwieństwem – tutaj możemy pokusić się o wydłużenie dni, w których będziemy trzymali trend, ponieważ w naszym przykładzie 1 rok trendu zajmuje tylko 1,3GB.

Podsumowanie

Analiza potrzeb pod środowisko zabbix nie jest łatwym zadaniem. Najlepiej jest zrobić analizę całej infrastruktury. Autor celowo w czasie zestawienia środowiska nie wchodził w szczegóły – nie jesteśmy w stanie oszacować potrzeb serwera zabbix w 100%, dlatego analiza nie powinna być za bardzo wnikliwa. Pamiętaj jednak, by zawsze przygotowywać się na najgorszy scenariusz i zawsze zakładać nadwyżkę (szczególnie jeżeli chodzi o miejsce na dysku!).

— Albert Przybylski, fanatyk Zabbixa, pełnoprawny admin 24/7