1. Сервер

Обзор

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

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

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

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

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

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

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