1 Server

Omówienie

Serwer Zabbix jest centralnym procesem oprogramowania Zabbix.

Serwer wykonuje odpytywanie i przechwytywanie danych, oblicza wyzwalacze, wysyła powiadomienia do użytkowników. Jest centralnym komponentem, do którego agent i proxy Zabbix zgłaszają dane o dostępności i integralności systemów. Serwer może również zdalnie sprawdzać usługi sieciowe (takie jak serwery WWW i serwery poczty) przy użyciu prostych testów usług.

Serwer jest centralnym repozytorium, w którym przechowywane są wszystkie dane konfiguracyjne, statystyczne i operacyjne, a także elementem Zabbix, który aktywnie powiadamia administratorów, gdy w którymkolwiek z monitorowanych systemów wystąpią problemy.

Działanie podstawowego serwera Zabbix jest podzielone na trzy odrębne komponenty; są to: serwer Zabbix, frontend WWW i magazyn bazy danych.

Wszystkie informacje konfiguracyjne dla Zabbix są przechowywane w bazie danych, z którą współpracują zarówno serwer, jak i frontend WWW. Na przykład, gdy tworzysz nową pozycja za pomocą frontend WWW (lub API), jest ona dodawana do tabeli items w bazie danych. Następnie, mniej więcej raz na minutę, serwer Zabbix będzie odpytywał tabelę items o listę aktywnych pozycji, która następnie jest przechowywana w pamięci podręcznej wewnątrz serwera Zabbix. Dlatego wprowadzone w frontend Zabbix zmiany mogą pojawić się w sekcji najnowszych danych dopiero po upływie nawet dwóch minut.

Uruchamianie serwera

Jeśli zainstalowano z pakietu

Serwer Zabbix działa jako proces demona. Serwer można uruchomić, wykonując:

systemctl start zabbix-server

To zadziała w większości systemów GNU/Linux. W innych systemach może być konieczne uruchomienie:

/etc/init.d/zabbix-server start

Podobnie, aby zatrzymać/uruchomić ponownie/sprawdzić stan, użyj następujących poleceń:

systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server

Uruchamianie ręczne

Jeśli powyższe nie działa, musisz uruchomić go ręcznie. Znajdź ścieżkę do pliku binarnego zabbix_server i wykonaj:

zabbix_server

Możesz używać następujących parametrów wiersza poleceń z serwerem Zabbix:

-c --config <file>              Ścieżka do pliku konfiguracyjnego (domyślnie /usr/local/etc/zabbix_server.conf)
-f --foreground                 Uruchom serwer Zabbix na pierwszym planie
-R --runtime-control <option>   Wykonaj funkcje administracyjne
-T --test-config                Sprawdź poprawność pliku konfiguracyjnego i zakończ
-h --help                       Wyświetl tę pomoc
-V --version                    Wyświetl numer wersji

Przykłady uruchamiania serwera Zabbix z parametrami wiersza poleceń:

zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -V

Kontrola w czasie działania

Opcje kontroli w czasie działania:

Przykład użycia kontroli w czasie działania do przeładowania pamięci podręcznej konfiguracji serwera:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

Przykłady użycia kontroli w czasie działania do przeładowania konfiguracji proxy:

# Przeładuj konfigurację wszystkich proxy:
zabbix_server -R proxy_config_cache_reload

# Przeładuj konfigurację Proxy1 i Proxy2:
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

Przykład użycia kontroli w czasie działania do wyczyszczenia pamięci podręcznej historii dla pozycji:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

Przykłady użycia kontroli w czasie działania do zebrania informacji diagnostycznych:

# Zbierz wszystkie dostępne informacje diagnostyczne w pliku dziennika serwera:
zabbix_server -R diaginfo

# Zbierz statystyki pamięci podręcznej historii w pliku dziennika serwera:
zabbix_server -R diaginfo=historycache

Przykład użycia kontroli w czasie działania do przeładowania pamięci podręcznej SNMP:

zabbix_server -R snmp_cache_reload

Przykład użycia kontroli w czasie działania do wyzwolenia wykonania housekeepera:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

Przykłady użycia kontroli w czasie działania do zmiany poziomu logowania:

# Zwiększ poziom logowania wszystkich procesów:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase

# Zwiększ poziom logowania drugiego procesu pollera:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2

# Zwiększ poziom logowania procesu o PID 1234:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234

# Zmniejsz poziom logowania wszystkich procesów http poller:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Przykład ustawienia opóźnienia przełączenia awaryjnego HA na minimalne 10 sekund:

zabbix_server -R ha_set_failover_delay=10s

Użytkownik procesu

Serwer Zabbix został zaprojektowany do działania jako użytkownik inny niż root. Będzie działać jako dowolny użytkownik inny niż root, z którego został uruchomiony. Dlatego można uruchamiać serwer jako dowolnego użytkownika innego niż root bez żadnych problemów.

Jeśli spróbujesz uruchomić go jako 'root', przełączy się na zakodowanego na stałe użytkownika 'zabbix', który musi być obecny w systemie. Serwer można uruchamiać jako 'root' tylko wtedy, gdy odpowiednio zmodyfikujesz parametr 'AllowRoot' w pliku konfiguracyjnym serwera.

Jeśli serwer Zabbix i agent są uruchamiane na tej samej maszynie, zaleca się użycie innego użytkownika do uruchamiania serwera niż do uruchamiania agenta. W przeciwnym razie, jeśli oba są uruchamiane jako ten sam użytkownik, agent może uzyskać dostęp do pliku konfiguracyjnego serwera, a każdy użytkownik z poziomem Admin w Zabbix może dość łatwo pozyskać na przykład hasło do bazy danych.

Plik konfiguracyjny

Szczegóły dotyczące konfiguracji zabbix_server można znaleźć w opcjach pliku konfiguracyjnego.

Skrypty startowe

Skrypty są używane do automatycznego uruchamiania/zatrzymywania procesów Zabbix podczas uruchamiania/zamykania systemu. Skrypty znajdują się w katalogu misc/init.d.

Typy procesów i wątki serwera

• agent poller - asynchroniczny proces pollera do sprawdzeń pasywnych z wątkiem roboczym;
• alert manager - menedżer kolejki alertów;
• alert syncer - proces zapisujący alerty do bazy danych;
• alerter - proces wysyłania powiadomień;
• availability manager - proces aktualizacji dostępności hostów;
• browser poller - poller do sprawdzeń pozycji przeglądarki;
• configuration syncer - proces zarządzania pamięciową pamięcią podręczną danych konfiguracyjnych;
• configuration syncer worker - proces rozwiązywania i synchronizacji wartości makr użytkownika w nazwach pozycji;
• connector manager - proces menedżera dla konektorów;
• connector worker - proces obsługujący żądania od connector manager;
• discovery manager - proces menedżera wykrywania urządzeń;
• discovery worker - proces obsługujący zadania wykrywania z discovery manager;
• escalator - proces eskalacji działań;
• ha manager - proces zarządzania wysoką dostępnością;
• history poller - proces obsługujący sprawdzenia obliczane wymagające połączenia z bazą danych;
• history syncer - proces zapisujący historię do bazy danych;
• housekeeper - proces usuwający nieaktualne dane (historię i trendy pozycji, sesje użytkowników, zdarzenia itp.), a także dane pozostawione po usuniętych obiektach;
• http agent poller - asynchroniczny proces pollera do sprawdzeń HTTP z wątkiem roboczym;
• http poller - poller monitorowania WWW;
• icmp pinger - poller do sprawdzeń icmpping;
• internal poller - poller do sprawdzeń wewnętrznych;
• ipmi manager - menedżer pollera IPMI;
• ipmi poller - poller do sprawdzeń IPMI;
• java poller - poller do sprawdzeń Java;
• lld manager - proces menedżera zadań niskopoziomowego wykrywania;
• lld worker - proces roboczy zadań niskopoziomowego wykrywania;
• odbc poller - poller do sprawdzeń ODBC;
• poller - zwykły poller do sprawdzeń pasywnych;
• preprocessing manager - menedżer zadań przetwarzania wstępnego z wątkami roboczymi przetwarzania wstępnego;
• preprocessing worker - wątek do przetwarzania wstępnego danych;
• proxy poller - poller dla pasywnych proxy;
• proxy group manager - menedżer równoważenia obciążenia i wysokiej dostępności proxy;
• report manager- menedżer zadań generowania raportów zaplanowanych;
• report writer - proces generowania raportów zaplanowanych;
• self-monitoring - proces zbierania wewnętrznych statystyk serwera;
• service manager - proces zarządzania usługami poprzez odbieranie informacji o problemach, tagach problemów i odzyskiwaniu po problemach z history syncer, task manager i alert manager;
• snmp poller - asynchroniczny proces pollera do sprawdzeń SNMP z wątkiem roboczym (tylko pozycje walk[OID] i get[OID]);
• snmp trapper - trapper dla pułapek SNMP;
• task manager - proces zdalnego wykonywania zadań żądanych przez inne komponenty (np. zamknięcie problemu, potwierdzenie problemu, natychmiastowe sprawdzenie wartości pozycji, funkcja zdalnego polecenia);
• timer - timer do przetwarzania konserwacji;
• trapper - trapper dla sprawdzeń aktywnych, pułapek i komunikacji z proxy;
• trigger housekeeper - proces usuwający problemy i zdarzenia wygenerowane przez wyzwalacze, które zostały później usunięte;
• unreachable poller - poller dla niedostępnych urządzeń;
• vmware collector - kolektor danych VMware odpowiedzialny za zbieranie danych z usług VMware.

Plik dziennika serwera może być używany do obserwowania tych typów procesów.

Plik dziennika serwera jest tworzony z uprawnieniami do odczytu i zapisu wyłącznie dla właściciela pliku. Dodatkowo plik jest czytelny dla grupy właściciela. Wszystkie pozostałe uprawnienia są zabronione.

Różne typy procesów serwera Zabbix można monitorować za pomocą wewnętrznej pozycji zabbix[process,<type>,<mode>,<state>].

Statystyki transakcji synchronizatora historii

Tytuł procesu synchronizatora historii wyświetla szczegółowe statystyki dotyczące transakcji synchronizatora historii:

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

W sekcji "A+B triggers":

• A - wyzwalacze przetworzone na podstawie wartości historii;
• B - wyzwalacze przetworzone na podstawie timerów.

Czasy w processed...in N (<timings>) sec to:

• Czas spędzony na zapisywaniu wartości pozycji do bazy danych;
• Czas spędzony na aktualizowaniu danych pozycji (stan, błędy, inwentarz hosta itp.);
• Czas spędzony na zapisywaniu trendów do bazy danych;
• Czas spędzony na obliczaniu wyzwalaczy;
• Czas spędzony na przetwarzaniu zdarzeń i działań.

Procedura housekeeping

Proces housekeeper okresowo usuwa przestarzałe dane (historię pozycji i trendy, sesje użytkowników, zdarzenia itp.), a także dane pozostawione po usuniętych obiektach. Działa on w cyklach, a częstotliwość oraz limit usuwania na cykl są określane przez HousekeepingFrequency i MaxHousekeeperDelete. Wszelkie dane nieusunięte w jednym cyklu są przenoszone do następnego. Automatyczne housekeeping można włączyć i skonfigurować w Administration > Housekeeping.

Do usuwania danych pozostawionych po usuniętych obiektach proces housekeeper korzysta z zadań z tabeli housekeeper, która jest wypełniana za każdym razem, gdy obiekt zostanie usunięty. Na przykład po usunięciu hosta Zabbix usuwa również jego pozycje, ale nie ich historię, trendy ani problemy. Zamiast tego wyzwalacze bazy danych wypełniają tabelę housekeeper zadaniami zawierającymi następujące pola:

• housekeeperid - ID zadania
• object - typ obiektu (0 - pozycja; 1 - wyzwalacz; 2 - usługa; 3 - wykryty host; 4 - wykryta usługa)
• objectid - ID obiektu (pomaga procesowi housekeeper znaleźć dane powiązane z obiektem)

Na przykład usunięcie hosta z dwiema pozycjami i jednym wyzwalaczem powoduje wypełnienie tabeli housekeeper w następujący sposób:

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

Wyzwalacze bazy danych wypełniają tabelę housekeeper bez sprawdzania danych powiązanych z obiektem; to sprawdzenie jest wykonywane przez proces housekeeper.

Każde zadanie skutkuje jedną lub większą liczbą operacji housekeeper, które zależą od typu obiektu:

• Dla pozycji (w tym reguł LLD) - usuwa dane ze wszystkich tabel historii i trendów (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint), które zawierają wartości dla tych pozycji. Ponadto sprawdza tabelę problems i usuwa przestarzałe zdarzenia wewnętrzne powiązane z tymi pozycjami.

• Dla wyzwalaczy - sprawdza tabele związane ze zdarzeniami (problem, event_symptom, event_recovery, events) i usuwa przestarzałe zdarzenia powiązane z tymi wyzwalaczami, a także powiadamia proces service manager o usuniętych zdarzeniach.

• Dla usług - sprawdza tabelę problems i usuwa przestarzałe zdarzenia usług, a także przestarzałe problemy usług, rozwiązując je w momencie housekeeping.

• Dla wykrywania sieci - usuwa przestarzałe zdarzenia wykrywania z tabeli problems.

Housekeeper usuwa tylko te zdarzenia, które nie są powiązane z problemami. Na przykład przestarzałe zdarzenie problemu/odzyskania nie zostanie usunięte, jeśli jest powiązane z otwartym problemem. Gdy housekeeper usuwa przestarzałe encje, najpierw usuwa problemy, a następnie zdarzenia.

Obsługiwane platformy

Ze względu na wymagania bezpieczeństwa oraz krytyczny charakter działania serwera, UNIX jest jedynym systemem operacyjnym, który może konsekwentnie zapewniać wymaganą wydajność, odporność na awarie i niezawodność. Zabbix działa na wiodących na rynku wersjach systemu.

Serwer Zabbix jest testowany na następujących platformach:

• Linux
• Solaris
• AIX
• HP-UX
• Mac OS X
• FreeBSD
• OpenBSD
• NetBSD
• SCO Open Server

Ustawienia regionalne

Należy pamiętać, że serwer wymaga ustawień regionalnych UTF-8, aby niektóre tekstowe pozycje mogły być poprawnie interpretowane. Większość nowoczesnych systemów typu Unix ma domyślnie ustawienia regionalne UTF-8, jednak istnieją systemy, w których może być konieczne ich jawne skonfigurowanie.