1 Server

Przegląd

Serwer Zabbix jest centralnym procesem oprogramowania Zabbix.

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

Serwer jest centralnym repozytorium, w którym przechowywane są wszystkie dane konfiguracyjne, statystyczne i operacyjne, oraz elementem Zabbix, który aktywnie alarmuje administratorów, gdy w którymkolwiek z monitorowanych systemów pojawią się problemy.

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

Wszystkie informacje konfiguracyjne Zabbix są przechowywane w bazie danych, z którą współpracują zarówno serwer, jak i frontend WWW. Na przykład, gdy tworzysz nową pozycję przy użyciu frontend WWW (lub API), jest ona dodawana do tabeli items w bazie danych. Następnie, mniej więcej raz na minutę, serwer Zabbix odpytuje tabelę items o listę aktywnych pozycji, która jest następnie przechowywana w pamięci podręcznej serwera Zabbix. Dlatego wprowadzenie zmian w frontend Zabbix może spowodować, że ich pojawienie się w sekcji najnowszych danych zajmie do 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żyć 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 niebędący rootem. Będzie działał jako dowolny użytkownik niebędący rootem, pod którym został uruchomiony. Dlatego możesz uruchomić serwer jako dowolnego użytkownika niebędącego rootem 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. Możesz uruchomić serwer jako 'root' tylko wtedy, gdy odpowiednio zmodyfikujesz parametr 'AllowRoot' w pliku konfiguracyjnym serwera.

Jeśli serwer Zabbix i agent są uruchomione na tej samej maszynie, zaleca się użycie innego użytkownika do uruchamiania serwera niż do uruchamiania agenta. W przeciwnym razie, jeśli oba procesy są uruchomione 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 stosunkowo łatwo odczytać na przykład hasło do bazy danych.

Plik konfiguracyjny

Szczegółowe informacje na temat 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 serwera i wątki

• agent poller - asynchroniczny proces odpytywania dla pasywnych kontroli 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 - proces odpytywania dla kontroli pozycji przeglądarki
• configuration syncer - proces zarządzania pamięcią podręczną danych konfiguracyjnych w pamięci
• configuration syncer worker - proces rozwiązywania i synchronizacji wartości makr użytkownika w nazwach pozycji
• connector manager - proces menedżera konektorów
• connector worker - proces obsługi żądań od menedżera konektorów
• discovery manager - proces menedżera wykrywania urządzeń
• discovery worker - proces obsługi zadań wykrywania od menedżera wykrywania
• escalator - proces eskalacji działań
• ha manager - proces zarządzania wysoką dostępnością
• history poller - proces obsługi kontroli obliczanych wymagających połączenia z bazą danych
• history syncer - proces zapisujący historię do bazy danych
• housekeeper - proces usuwania nieaktualnych danych (historii i trendów pozycji, sesji użytkowników, zdarzeń itp.), a także danych pozostawionych przez usunięte obiekty
• http agent poller - asynchroniczny proces odpytywania dla kontroli HTTP z wątkiem roboczym
• http poller - proces odpytywania monitorowania WWW
• icmp pinger - proces odpytywania dla kontroli icmpping
• internal poller - proces odpytywania dla kontroli wewnętrznych
• ipmi manager - menedżer procesów odpytywania IPMI
• ipmi poller - proces odpytywania dla kontroli IPMI
• java poller - proces odpytywania dla kontroli Java
• lld manager - proces menedżera zadań wykrywania niskiego poziomu
• lld worker - proces roboczy zadań wykrywania niskiego poziomu
• odbc poller - proces odpytywania dla kontroli ODBC
• poller - zwykły proces odpytywania dla pasywnych kontroli
• preprocessing manager - menedżer zadań przetwarzania wstępnego z wątkami roboczymi przetwarzania wstępnego
• preprocessing worker - wątek przetwarzania wstępnego danych
• proxy poller - proces odpytywania dla pasywnych proxy
• proxy group manager - menedżer równoważenia obciążenia proxy i wysokiej dostępności
• report manager- menedżer zadań generowania raportów cyklicznych
• report writer - proces generowania raportów cyklicznych
• self-monitoring - proces zbierania wewnętrznych statystyk serwera
• service manager - proces zarządzania usługami poprzez odbieranie informacji o problemach, tagach problemów i odtworzeniu problemów z history syncer, task manager i alert manager
• snmp poller - asynchroniczny proces odpytywania dla kontroli 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, sprawdzenie wartości pozycji teraz, funkcjonalność zdalnych poleceń)
• timer - timer do przetwarzania okresów utrzymania
• trapper - trapper dla aktywnych kontroli, trapów, komunikacji proxy
• trigger housekeeper - proces usuwania problemów i zdarzeń wygenerowanych przez wyzwalacze, które zostały od tego czasu usunięte
• unreachable poller - proces odpytywania dla nieosiągalnych 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 odczytu i zapisu tylko dla właściciela pliku. Dodatkowo plik jest dostępny do odczytu dla grupy właściciela. Wszystkie pozostałe uprawnienia są zabronione.

Różne typy procesów serwera Zabbix mogą być monitorowane przy użyciu wewnętrznej pozycji zabbix\[process,<type>,<mode>,<state>\] item.

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 „A+B triggers”:

• A - wyzwalacze przetworzone z powodu wartości historii;
• B - wyzwalacze przetworzone z powodu timerów.

Czasy w „processed...in N (<timings>) sec” oznaczają:

• Czas poświęcony na zapisywanie wartości pozycji do bazy danych;
• Czas poświęcony na aktualizację danych pozycji (stan, błędy, inwentarz hosta itp.);
• Czas poświęcony na opróżnianie trendów do bazy danych;
• Czas poświęcony na obliczanie wyzwalaczy;
• Czas poświęcony na przetwarzanie zdarzeń i akcji.

Procedura housekeeping

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

W celu usuwania danych pozostawionych po usuniętych obiektach proces housekeeper opiera się na zadaniach z tabeli housekeeper, która jest wypełniana przy każdym usunięciu obiektu. Na przykład po usunięciu hosta Zabbix usuwa również jego pozycje, ale nie ich historii, trendów ani problemów. Zamiast tego wyzwalacze bazy danych wypełniają tabelę housekeeper zadaniami składającymi się z następujących pól:

• 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 wypełnia tabelę 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; sprawdzenie to wykonuje 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. Dodatkowo sprawdza tabelę problems i usuwa nieaktualne zdarzenia wewnętrzne powiązane z tymi pozycjami.

• Dla wyzwalaczy - sprawdza tabele powiązane ze zdarzeniami (problem, event_symptom, event_recovery, events) i usuwa nieaktualne 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 nieaktualne zdarzenia usług, a także nieaktualne problemy usług, rozwiązując je tym samym w momencie działania housekeeping.

• Dla wykrywania sieci - usuwa nieaktualne zdarzenia wykrywania z tabeli problems.

Proces housekeeper usuwa tylko te zdarzenia, które nie są powiązane z problemami. Na przykład nieaktualne zdarzenie problemu/odzyskania nie zostanie usunięte, jeśli jest powiązane z otwartym problemem. Gdy proces housekeeper usuwa nieaktualne 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.