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

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

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

Вся информация о конфигурации Zabbix хранится в базе данных, с которой взаимодействуют и сервер, и веб-интерфейс. Например, когда вы создаете новый элемент данных с помощью веб-интерфейса (или API), он добавляется в таблицу items в базе данных. Затем примерно раз в минуту сервер Zabbix запрашивает таблицу items, чтобы получить список активных элементов данных, который затем сохраняется в кэше внутри сервера 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 server можно использовать следующие параметры командной строки:

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

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

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

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

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

Option	Description	Target
`config_cache_reload`	Перезагрузить кэш конфигурации. Игнорируется, если кэш в данный момент загружается.
`history_cache_clear=target`	Очистить кэш истории для элемента данных, указанного по его ID. Затрагивает все значения элемента данных, кроме первого и последнего значения.	target - ID элемента данных
`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'.

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

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 -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

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

# Собрать всю доступную диагностическую информацию в файле журнала сервера:
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-кэш для устранения неполадок.

Пример использования управления во время выполнения для запуска housekeeper:

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

# Увеличить уровень журнала для второго процесса poller:
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 poller:
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-ловушек;
task manager - процесс удаленного выполнения задач, запрошенных другими компонентами (например, закрытие проблемы, подтверждение проблемы, немедленная проверка значения элемента данных, функциональность удаленной команды);
timer - таймер для обработки обслуживаний;
trapper - trapper для активных проверок, ловушек, связи с прокси;
trigger housekeeper - процесс удаления проблем и событий, сгенерированных триггерами, которые были впоследствии удалены;
unreachable poller - процесс опроса для недоступных устройств;
vmware collector - сборщик данных VMware, отвечающий за сбор данных из служб VMware.

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

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

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

Статистика транзакций history syncer

Заголовок процесса history syncer отображает подробную статистику по транзакциям history syncer:

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]

В "A+B triggers":

A - триггеры, обработанные из-за значений истории;
B - триггеры, обработанные из-за таймеров.

Временные показатели в processed...in N (<timings>) sec:

Время, затраченное на запись значений элементов данных в базу данных;
Время, затраченное на обновление данных элемента данных (состояние, ошибки, инвентарь узла сети и т. д.);
Время, затраченное на запись трендов в базу данных;
Время, затраченное на вычисление триггеров;
Время, затраченное на обработку событий и действий.

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

В связи с требованиями безопасности и критически важного характера работы сервера, 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. Сервер

Обзор