Сервер выполняет опрос и отлов данных, вычисляет триггеры, отправляет оповещения пользователям. Он является центральным компонентом, которому Zabbix агенты и прокси сообщают данные о доступности и целостности систем. Сервер может самостоятельно удалённо проверять сетевые службы (такие как веб-серверы и почтовые серверы), используя простые проверки сервисов.

Сервер является главным хранилищем, в котором находятся все конфигурационные, статистические и оперативные данные, он также рассылает уведомления администраторам в случае возникновения проблем на любой из наблюдаемых систем.

Функционал базового Zabbix сервера разделён на три отдельных компонента; это: Zabbix сервер, веб-интерфейс и хранилище в базе данных.

Все данные о конфигурации Zabbix хранятся в базе данных, с которой взаимодействуют и сервер, и веб-интерфейс. Например, когда вы создаёте новый элемент данных, используя веб-интерфейс (или API), запись об этом добавляется в таблицу элементов данных в базе данных. Затем примерно раз в минуту Zabbix сервер опрашивает таблицу элементов данных для получения списка активных элементов данных, и сохраняет этот список в кэше Zabbix сервера. Поэтому любые изменения, сделанные в веб-интерфейсе Zabbix, могут отобразиться в разделе последних данных с задержкой до двух минут.

Запуск сервера

Если установлен из пакета

Zabbix сервер работает как демон. Его можно запустить, выполнив:

systemctl start zabbix-server

Эта команда будет работать на большинстве систем GNU/Linux. На других системах вам, возможно, потребуется выполнить:

/etc/init.d/zabbix-server start

Аналогично, для остановки/перезапуска/просмотра состояния используйте следующие команды:

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

Запуск вручную

Если приведённые ранее команды не работают, вам необходимо запустить сервер вручную. Найдите путь к бинарному файлу zabbix_server и выполните:

zabbix_server

С Zabbix сервером можно использовать следующие параметры командной строки:

-c --config <файл>             Путь к файлу конфигурации (по умолчанию /usr/local/etc/zabbix_server.conf)
-f --foreground                Запуск Zabbix сервера без перехода в фоновый режим
-R --runtime-control <опция>   Выполнение административных функций
-h --help                      Вывод этого сообщения помощи
-V --version                   Вывод номера версии

Примеры запуска Zabbix сервера с параметрами командой строки:

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

Управление во время работы

Параметры управления во время работы:

Option	Description	Target
`config_cache_reload`	Перезагрузить кэш конфигурации. Игнорируется, если кэш в данный момент загружается.
`diaginfo[=<section>]`	Собрать диагностическую информацию в файле журнала сервера.	`historycache` - статистика кэша истории; `valuecache` - статистика кэша значений; `preprocessing` - статистика менеджера предварительной обработки; `alerting` - статистика менеджера оповещений; `lld` - статистика менеджера LLD; `locks` - список мьютексов (пусто в системах BSD); `connector` - статистика для коннекторов с наибольшей очередью.
`ha_status`	Записать в журнал состояние кластера высокой доступности (HA).
`ha_remove_node=target`	Удалить узел высокой доступности (HA), указанный по имени или ID. Обратите внимание, что активные/резервные узлы удалить нельзя.	target - имя или ID узла (можно получить, выполнив `ha_status`).
`ha_set_failover_delay=delay`	Установить задержку переключения высокой доступности (HA). Поддерживаются суффиксы времени, например 10s, 1m.
`proxy_config_cache_reload[=<target>]`	Перезагрузить кэш конфигурации прокси.	target - список имен прокси, разделенных запятыми. Если target не указан, конфигурация будет перезагружена для всех прокси.
`secrets_reload`	Перезагрузить секреты из Vault.
`service_cache_reload`	Перезагрузить кэш менеджера служб.
`snmp_cache_reload`	Перезагрузить кэш SNMP — очистить свойства SNMP engine (engine time, engine boots, engine id, credentials) для всех узлов сети. Используйте для принудительной глобальной очистки кэша при устранении проблем с SNMP.
`housekeeper_execute`	Запустить процедуру housekeeping. Игнорируется, если процедура housekeeping уже выполняется.
`trigger_housekeeper_execute`	Запустить процедуру housekeeping для триггеров. Игнорируется, если процедура housekeeping для триггеров уже выполняется. Пока процедура housekeeping для триггеров не запущена, проблемы, вызванные триггерами, которые к этому моменту уже были удалены, все еще могут создавать проблемы служб и назначать их службам. Если в вашей системе используется много правил расчета статуса служб, основанных на часто обнаруживаемых/необнаруживаемых триггерах, рассмотрите возможность увеличения частоты процедуры housekeeping путем настройки серверного параметра конфигурации `ProblemHousekeepingFrequency`.
`log_level_increase[=<target>]`	Повысить уровень журналирования, влияет на все процессы, если target не указан. Не поддерживается в системах BSD.	process type - все процессы указанного типа (например, `poller`). См. все типы процессов сервера. process type,N - тип процесса и номер (например, `poller,3`). pid - идентификатор процесса (`1` to `65535`). Для больших значений укажите target как 'process type,N'.
`log_level_decrease[=<target>]`	Понизить уровень журналирования, влияет на все процессы, если target не указан. Не поддерживается в системах BSD.
`prof_enable[=<target>]`	Включить профилирование. Влияет на все процессы, если target не указан. Включенное профилирование предоставляет сведения обо всех rwlocks/mutexes по имени функции.	process type - все процессы указанного типа (например, `history syncer`) Поддерживаемые типы процессов в качестве целей профилирования: `alerter`, `alert manager`, `availability manager`, `configuration syncer`, `discovery manager`, `escalator`, `history poller`, `history syncer`, `housekeeper`, `http poller`, `icmp pinger`, `ipmi manager`, `ipmi poller`, `java poller`, `lld manager`, `lld worker`, `odbc poller`, `poller`, `preprocessing manager`, `preprocessing worker`, `proxy poller`, `self-monitoring`, `service manager`, `snmp trapper`, `task manager`, `timer`, `trapper`, `unreachable poller`, `vmware collector`. process type,N - тип процесса и номер (например, `history syncer,1`). pid - идентификатор процесса (`1` to `65535`). Для больших значений укажите target как 'process type,N'. scope - `rwlock`, `mutex`, `processing` можно использовать с типом процесса и номером (например, `history syncer,1,processing`) или со всеми процессами типа (например, `history syncer,rwlock`).
`prof_disable[=<target>]`	Отключить профилирование. Влияет на все процессы, если target не указан.	process type - все процессы указанного типа (например, `history syncer`). Поддерживаемые типы процессов в качестве целей профилирования: см. `prof_enable`. process type,N - тип процесса и номер (например, `history syncer,1`). pid - идентификатор процесса (`1` to `65535`). Для больших значений укажите target как 'process type,N'.

Когда тип процесса указан как target для управления во время работы, команда применяется только к запущенным процессам этого типа. Если в данный момент ни один процесс указанного типа не запущен, команда возвращает ошибку:

zabbix_server -R log_level_increase='discovery worker'
Cannot redirect signal: "discovery worker" process does not exist

Пример использования административных функций для перезагрузки кэша конфигурации сервера:

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

Примеры использования административных функций для перезагрузки кэша конфигурации прокси:

# Перезагрузить конфигурацию всех прокси:
zabbix_server -R proxy_config_cache_reload

# Перезагрузить конфигурацию Proxy1 и Proxy2:
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

Примеры использования административных функций для сбора диагностической информации:

# Сбор всей доступной диагностической информации в файл журнала сервера:
zabbix_server -R diaginfo

# Сбор статистики кэша истории в файл журнала сервера:
zabbix_server -R diaginfo=historycache

Пример использования административных функций для перезагрузки SNMP кэша:

zabbix_server -R snmp_cache_reload

При обновлении интерфейса SNMPv3 через веб-интерфейс Zabbix, в большинстве случаев Zabbix автоматически загрузит новые учётные данные SNMPv3 для этого интерфейса; используйте -R snmp_cache_reload только в том случае, если опрос по-прежнему не удаётся после изменения учётных данных (например, из-за несоответствия engineBoots/engineID или устройств, не соответствующих RFC), или же когда вам нужно принудительно очистить глобальный кэш SNMP для устранения неполадок.

Пример использования административных функций для вызова выполнения очистки базы данных:

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

Примеры использования административных функций по изменению уровня журналирования:

# Увеличение уровня журналирования по всем процессам:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase

# Увеличение уровня журналирования у второго процесса поллера:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2

# Увеличение уровня журналирования у процесса с PID 1234:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234

# Уменьшение уровня журналирования по всем http поллер процессам:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Пример изменения настройки задержки аварийного переключения для HA в минимальное значение в 10 секунд:

zabbix_server -R ha_set_failover_delay=10s

Пользователь процесса

Zabbix сервер спроектирован для запуска от непривилегированного пользователя (non-root). Он будет работать от любого непривилегированного пользователя, от которого был запущен. Таким образом, вы можете запускать сервер от имени любого непривилегированного пользователя, без каких либо последствий.

Если вы попытаетесь запустить сервер от имени «root», он сразу переключится на пользователя «zabbix», который должен присутствовать в вашей системе. Единственный способ запустить сервер от пользователя «root» — соответствующим образом отредактировать параметр «AllowRoot» в файле конфигурации сервера.

Если Zabbix сервер и агент работают на одном сервере, то рекомендуется использовать разных пользователей для запуска сервера и для запуска агента. В противном случае, если сервер и агент запущены под одним пользователем, агент будет иметь доступ к файлу конфигурации сервера и любой пользователь с правами Администратора в Zabbix может с лёгкостью получить, например, пароль от базы данных.

Файл конфигурации

Смотрите опции файла конфигурации для получения подробной информации по настройке zabbix_server.

Скрипты запуска

Скрипты используются для автоматического запуска/остановки процессов Zabbix при включении/выключении системы. Скрипты располагаются в директории misc/init.d.

Типы процессов и потоков сервера

agent poller - асинхронный процесс опроса для пассивных проверок с рабочим потоком;
alert manager - менеджер очереди оповещений;
alert syncer - процесс записи оповещений в БД;
alerter - процесс отправки уведомлений;
availability manager - процесс обновления доступности узлов сети;
browser poller - процесс опроса для проверок элементов данных браузера;
configuration syncer - процесс управления кэшем конфигурационных данных в памяти;
configuration syncer worker - процесс разрешения и синхронизации значений пользовательских макросов в именах элементов данных;
connector manager - процесс-менеджер для коннекторов;
connector worker - процесс обработки запросов от менеджера коннекторов;
discovery manager - процесс-менеджер для обнаружения устройств;
discovery worker - процесс обработки задач обнаружения от менеджера обнаружения;
escalator - процесс эскалации действий;
ha manager - процесс управления высокой доступностью;
history poller - процесс обработки вычисляемых проверок, требующих подключения к базе данных;
history syncer - процесс записи истории в БД;
housekeeper - процесс удаления устаревших данных (истории и трендов элементов данных, пользовательских сессий, событий и т. д.), а также данных, оставшихся после удаленных объектов;
http agent poller - асинхронный процесс опроса для HTTP-проверок с рабочим потоком;
http poller - процесс опроса для веб-мониторинга;
icmp pinger - процесс опроса для проверок icmpping;
internal poller - процесс опроса для внутренних проверок;
ipmi manager - менеджер процесса опроса IPMI;
ipmi poller - процесс опроса для проверок IPMI;
java poller - процесс опроса для проверок Java;
lld manager - процесс-менеджер задач низкоуровневого обнаружения;
lld worker - рабочий процесс задач низкоуровневого обнаружения;
odbc poller - процесс опроса для проверок ODBC;
poller - обычный процесс опроса для пассивных проверок;
preprocessing manager - менеджер задач предварительной обработки с потоками рабочих процессов предварительной обработки;
preprocessing worker - поток предварительной обработки данных;
proxy poller - процесс опроса для пассивных прокси;
proxy group manager - менеджер балансировки нагрузки и высокой доступности прокси;
report manager- менеджер задач планового формирования отчетов;
report writer - процесс формирования плановых отчетов;
self-monitoring - процесс сбора внутренних статистических данных сервера;
service manager - процесс управления сервисами путем получения информации о проблемах, тегах проблем и восстановлении проблем от history syncer, task manager и alert manager;
snmp poller - асинхронный процесс опроса для проверок SNMP с рабочим потоком (только элементы данных walk[OID] и get[OID]);
snmp trapper - trapper для SNMP trap;
task manager - процесс удаленного выполнения задач, запрошенных другими компонентами (например, закрытие проблемы, подтверждение проблемы, немедленная проверка значения элемента данных, функциональность удаленной команды);
timer - таймер для обработки обслуживаний;
trapper - trapper для активных проверок, trap, взаимодействия с прокси;
trigger housekeeper - процесс удаления проблем и событий, сгенерированных триггерами, которые впоследствии были удалены;
unreachable poller - процесс опроса для недоступных устройств;
vmware collector - сборщик данных VMware, отвечающий за сбор данных из служб VMware.

Файл журнала сервера можно использовать для наблюдения за этими типами процессов.

Начиная с Zabbix 7.0.22, файл журнала сервера создается с правами чтения и записи только для владельца файла. Кроме того, файл доступен для чтения группе владельца. Все остальные права запрещены.

Различные типы процессов сервера Zabbix можно отслеживать с помощью внутреннего элемента данных zabbix[process,<type>,<mode>,<state>].

Поддерживаемые платформы

В связи с требованиями безопасности и критически важного характера работы сервера, UNIX является единственной операционной системой, которая может обеспечить необходимую производительность, отказоустойчивость и гибкость. Zabbix работает с ведущими на рынке версиями операционных систем.

Zabbix сервер протестирован на следующих платформах:

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

Также Zabbix может работать и на других Unix-подобных операционных системах.

Региональные настройки (локаль)

Обратите внимание, что серверу требуется локаль UTF-8, чтобы некоторые текстовые элементы данных интерпретировались корректно. Большинство современных Unix-подобных систем уже имеют локаль UTF-8 по умолчанию, тем не менее, есть некоторые системы где это необходимо указывать вручную.

What’s next?

1. Кластер высокой доступности

Docs

1. Сервер

Обзор