Сервер выполняет опрос и отлов данных, вычисляет триггеры, отправляет оповещения пользователям. Он является центральным компонентом, которому 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`, `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 -R log_level_increase='discovery manager'
Cannot redirect signal: "discovery manager" 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 — процесс асинхронного поллера для пассивных проверок с рабочим потоком (worker thread);
alert manager — менеджер задач оповещений;
alert syncer — процесс записи оповещений в БД;
alerter — процесс отправки оповещений;
availability manager — процесс для обновления доступности узлов сети;
browser poller — процесс поллера для проверок браузерных элементов данных;
configuration syncer — процесс управления кэшем данных конфигурации в оперативной памяти;
configuration syncer worker — процесс для раскрытия и синхронизации значений пользовательских макросов в именах элементов данных;
connector manager — процесс менеджера для коннекторов;
connector worker — процесс для обработки запросов от connector manager-а;
discovery manager — процесс менеджера для обнаружения устройств;
discovery worker — процесс для обработки задач обнаружения от discovery manager-а;
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 — траппер сбора/обработки SNMP трапов;
task manager — процесс для удалённого выполнения задач, которые запрашиваются другими компонентами (например, функционал закрытия проблемы, подтверждения проблемы, принудительной проверки значения элемента данных, удалённой команды);
timer — процесс для обработки обслуживаний;
trapper — процесс-траппер для активных проверок, трапов и взаимодействия с прокси;
trigger housekeeper — процесс для удаления проблем и событий, сгенерированных триггерами, которые впоследствии были удалены;
unreachable poller — поллер недоступных устройств;
vmware collector — сборщик данных VMware, ответственный за сбор данных от служб VMware.

Можно воспользоваться файлом журнала сервера для выявления этих типов процессов.

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

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

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

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

Обзор