1. Сервер

Обзор

Сервер Zabbix — это центральный процесс программного обеспечения Zabbix.

Сервер выполняет опрос и прием данных, вычисляет триггеры, отправляет уведомления пользователям. Это центральный компонент, которому агенты 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 можно использовать следующие параметры командной строки:

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

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

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

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

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

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

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

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

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

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

Пример использования runtime control для очистки кэша истории для элемента данных:

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

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

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

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

Пример использования runtime control для перезагрузки кэша SNMP:

zabbix_server -R snmp_cache_reload

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

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

Примеры использования runtime control для изменения уровня логирования:

# Увеличить уровень логирования всех процессов:
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 разработан для запуска от имени пользователя, не являющегося root. Он будет работать от имени любого пользователя, не являющегося root, от которого был запущен. Поэтому вы можете без каких-либо проблем запускать сервер от имени любого пользователя, не являющегося root.

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

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

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

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

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

Статистика транзакций синхронизатора истории

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

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":

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

Процедура очистки устаревших данных

Процесс housekeeper периодически удаляет устаревшие данные (историю и тренды элементов данных, пользовательские сессии, события и т. д.), а также данные, оставшиеся после удаления объектов. Он работает циклически, при этом частота запуска и лимит удаления за один цикл определяются параметрами HousekeepingFrequency и MaxHousekeeperDelete. Любые данные, не удалённые за один цикл, переносятся на следующий. Автоматическую очистку устаревших данных можно включить и настроить в разделе Администрирование > Очистка устаревших данных.

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

• housekeeperid - ID задачи
• object - тип объекта (0 - элемент данных; 1 - триггер; 2 - сервис; 3 - обнаруженный узел сети; 4 - обнаруженный сервис)
• objectid - ID объекта (помогает housekeeper находить данные, связанные с объектом)

Например, удаление узла сети с двумя элементами данных и одним триггером заполняет таблицу housekeeper следующим образом:

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

Триггеры базы данных заполняют таблицу housekeeper без проверки наличия данных, связанных с объектом; эта проверка выполняется процессом housekeeper.

Каждая задача приводит к одной или нескольким операциям housekeeper, которые зависят от типа объекта:

• Для элементов данных (включая правила LLD) — удаляются данные из всех таблиц истории и трендов (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint), содержащих значения для этих элементов данных. Также проверяется таблица problems и удаляются устаревшие внутренние события, связанные с этими элементами данных.

• Для триггеров — проверяются таблицы, связанные с событиями (problem, event_symptom, event_recovery, events), и удаляются устаревшие события, связанные с этими триггерами, а также процесс service manager уведомляется об удалённых событиях.

• Для сервисов — проверяется таблица problems и удаляются устаревшие события сервисов, а также устаревшие проблемы сервисов, тем самым они закрываются в момент выполнения очистки.

• Для сетевого обнаружения — удаляются устаревшие события обнаружения из таблицы problems.

Housekeeper удаляет только те события, которые не связаны с проблемами. Например, устаревшее событие проблемы/восстановления не будет удалено, если оно связано с открытой проблемой. Когда housekeeper удаляет устаревшие сущности, он сначала удаляет проблемы, а затем события.

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

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

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

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

Локаль

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