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

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

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

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

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

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

Различные типы процессов сервера 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:

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

Процедура housekeeping

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

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

• housekeeperid - ID задачи
• object - тип объекта (0 - элемент данных; 1 - триггер; 2 - service; 3 - обнаруженный узел сети; 4 - обнаруженный service)
• 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 и удаляет устаревшие события сервисов, а также устаревшие проблемы сервисов, тем самым устраняя их во время housekeeping.

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