4. Прокси

Обзор

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

Развертывание прокси не является обязательным, однако может быть очень полезным для распределения нагрузки одного сервера Zabbix. Если данные собирают только прокси, обработка на сервере требует меньше ресурсов CPU и дискового ввода-вывода.

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

Прокси Zabbix требует отдельную базу данных.

Обратите внимание, что базы данных, поддерживаемые прокси Zabbix, — это SQLite, MySQL и PostgreSQL.

См. также: Использование прокси в распределенной среде

Запуск прокси

Если установлен из пакета

Прокси Zabbix работает как процесс-демон. Прокси можно запустить, выполнив:

systemctl start zabbix-proxy

Это будет работать в большинстве систем GNU/Linux. В других системах может потребоваться выполнить:

/etc/init.d/zabbix-proxy start

Аналогично, для остановки/перезапуска/просмотра состояния прокси Zabbix используйте следующие команды:

systemctl stop zabbix-proxy
systemctl restart zabbix-proxy
systemctl status zabbix-proxy
Запуск вручную

Если описанное выше не работает, необходимо запустить его вручную. Найдите путь к исполняемому файлу zabbix_proxy и выполните:

zabbix_proxy

С прокси Zabbix можно использовать следующие параметры командной строки:

-c --config <file>              путь к файлу конфигурации
-f --foreground                 запуск прокси Zabbix на переднем плане
-R --runtime-control <option>   выполнение административных функций
-T --test-config                проверить файл конфигурации и выйти
-h --help                       показать эту справку
-V --version                    показать номер версии

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

zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf
zabbix_proxy --help
zabbix_proxy -V
Управление во время выполнения

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

Параметр Описание Цель
config_cache_reload Перезагрузить кэш конфигурации. Игнорируется, если кэш загружается в данный момент.
Активный прокси Zabbix подключится к серверу Zabbix и запросит данные конфигурации.
Пассивный прокси Zabbix запросит данные конфигурации у сервера Zabbix при следующем подключении сервера к прокси.
history_cache_clear=target Очистить кэш истории для элемента данных, указанного по его ID.
Затрагивает все значения элемента данных, кроме первого и последнего значения.		 target - ID элемента данных
diaginfo[=<section>] Собрать диагностическую информацию в файле журнала прокси. historycache - статистика кэша истории
preprocessing - статистика менеджера предобработки
locks - список mutex'ов (пуст на системах BSD)
snmp_cache_reload Перезагрузить кэш SNMP — очистить свойства SNMP engine (engine time, engine boots, engine id, credentials) для всех узлов сети. Используйте для принудительной глобальной очистки кэша при устранении проблем с SNMP.
housekeeper_execute Запустить процедуру очистки устаревших данных. Игнорируется, если процедура очистки устаревших данных уже выполняется.
log_level_increase[=<target>] Увеличить уровень журналирования; если target не указан, затрагиваются все процессы.
Не поддерживается в системах BSD.		 process type - Все процессы указанного типа (например, poller)
См. все типы процессов прокси.
process type,N - Тип процесса и номер (например, poller,3)
pid - Идентификатор процесса (от 1 до 65535). Для больших значений указывайте target как 'process type,N'.
log_level_decrease[=<target>] Уменьшить уровень журналирования; если target не указан, затрагиваются все процессы.
Не поддерживается в системах BSD.
prof_enable[=<target>] Включить профилирование.
Если target не указан, затрагиваются все процессы.
При включенном профилировании предоставляются сведения обо всех rwlocks/mutexes по имени функции.		 process type - Все процессы указанного типа (например, history syncer)
См. все типы процессов прокси.
process type,N - Тип процесса и номер (например, history syncer,1)
pid - Идентификатор процесса (от 1 до 65535). Для больших значений указывайте target как 'process type,N'.
scope - rwlock, mutex, processing можно использовать с типом процесса и номером (например, history syncer,1,processing) или со всеми процессами типа (например, history syncer,rwlock)
prof_disable[=<target>] Отключить профилирование.
Если target не указан, затрагиваются все процессы.		 process type - Все процессы указанного типа (например, history syncer)
См. все типы процессов прокси.
process type,N - Тип процесса и номер (например, history syncer,1)
pid - Идентификатор процесса (от 1 до 65535). Для больших значений указывайте target как 'process type,N'.

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

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

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

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

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

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

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

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

zabbix_proxy -R snmp_cache_reload

Когда интерфейс SNMPv3 обновляется через веб-интерфейс Zabbix, Zabbix в большинстве случаев автоматически перезагружает новые учетные данные SNMPv3 для этого интерфейса; используйте -R snmp_cache_reload только если опрос по-прежнему завершается ошибкой после изменения учетных данных (например, из-за несоответствий engineBoots/engineID или устройств, не соответствующих RFC), либо когда необходимо принудительно выполнить глобальную очистку кэша SNMP для устранения неполадок.

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

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

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

# Увеличить уровень журналирования для всех процессов:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase

# Увеличить уровень журналирования для второго процесса poller:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,2

# Увеличить уровень журналирования для процесса с PID 1234:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=1234

# Уменьшить уровень журналирования для всех процессов http poller:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="http poller"
Пользователь процесса

Прокси Zabbix разработан для запуска от имени непривилегированного пользователя. Он будет работать от имени того непривилегированного пользователя, от которого был запущен. Таким образом, вы можете без каких-либо проблем запускать прокси от имени любого непривилегированного пользователя.

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

Файл конфигурации

Подробные сведения о настройке zabbix_proxy см. в разделе configuration file.

Типы процессов и потоков прокси

  • agent poller — асинхронный процесс опроса для пассивных проверок с рабочим потоком
  • availability manager — процесс обновления доступности узла сети
  • browser poller — процесс опроса для проверок browser-элементов данных
  • configuration syncer — процесс управления кэшем данных конфигурации в памяти
  • data sender — отправитель данных прокси
  • discovery manager — управляющий процесс обнаружения устройств
  • discovery worker — процесс обработки задач обнаружения от discovery manager
  • history syncer — процесс записи истории в БД
  • housekeeper — процесс удаления устаревшей истории элементов данных
  • http agent poller — асинхронный процесс опроса для HTTP-проверок с рабочим потоком
  • http poller — процесс опроса веб-мониторинга
  • icmp pinger — процесс опроса для проверок icmpping
  • internal poller — процесс опроса для внутренних проверок
  • ipmi manager — управляющий процесс опроса IPMI
  • ipmi poller — процесс опроса для проверок IPMI
  • java poller — процесс опроса для проверок Java
  • odbc poller — процесс опроса для проверок ODBC
  • poller — обычный процесс опроса для пассивных проверок
  • preprocessing manager — управляющий процесс задач предобработки с рабочими потоками предобработки
  • preprocessing worker — поток предобработки данных
  • self-monitoring — процесс сбора внутренней статистики сервера
  • snmp poller — асинхронный процесс опроса для проверок SNMP с рабочим потоком (только элементы данных walk[OID] и get[OID])
  • snmp trapper — trapper для SNMP-ловушек
  • task manager — процесс удаленного выполнения задач, запрошенных другими компонентами (например, закрытие проблемы, подтверждение проблемы, немедленная проверка значения элемента данных, функциональность удаленных команд)
  • trapper — trapper для активных проверок, ловушек, взаимодействия с прокси
  • unreachable poller — процесс опроса для недоступных устройств
  • vmware collector — сборщик данных VMware, отвечающий за получение данных из сервисов VMware

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

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

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

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

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

205276 ?        S      0:00  zabbix_proxy: history syncer #1 [processed 1 values in 0.001179 (0.001167,0.000000) sec, idle 1 sec]
205277 ?        S      0:00  zabbix_proxy: history syncer #2 [processed 0 values in 0.000022 (0.000000,0.000000) sec, idle 1 sec]

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

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

Прокси Zabbix имеет процесс housekeeper, который удаляет устаревшую историю и тренды элементов данных. Он работает циклически; частота определяется параметром HousekeepingFrequency, а лимит удаления за один цикл — параметрами ProxyLocalBuffer и ProxyOfflineBuffer. В отличие от процедуры очистки устаревших данных на сервере Zabbix, процесс housekeeper на прокси не использует таблицу housekeeper — он удаляет все устаревшие данные один раз за каждый цикл очистки.

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

Прокси Zabbix работает на том же списке поддерживаемых платформ, что и сервер Zabbix.

Буфер памяти

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

В установках до Zabbix 7.0 собранные данные сохранялись в базе данных перед отправкой на сервер Zabbix. Для таких установок это поведение остается используемым по умолчанию после обновления до Zabbix 7.0.

Для оптимальной производительности рекомендуется настроить использование буфера памяти на прокси. Это можно сделать, изменив значение ProxyBufferMode с "disk" (жестко заданное значение по умолчанию для существующих установок) на "hybrid" (рекомендуется) или "memory". Также необходимо задать размер буфера памяти (параметр ProxyMemoryBufferSize).

В режиме hybrid буфер защищен от потери данных за счет сброса неотправленных данных в базу данных, если прокси остановлен, буфер заполнен или данные слишком старые. Когда все значения будут сброшены в базу данных, прокси возвращается к использованию буфера памяти.

В режиме memory будет использоваться буфер памяти, однако защита от потери данных отсутствует. Если прокси будет остановлен или память переполнится, неотправленные данные будут отброшены.

Режим hybrid (ProxyBufferMode=hybrid) применяется ко всем новым установкам начиная с Zabbix 7.0.

Дополнительные параметры, такие как ProxyMemoryBufferSize и ProxyMemoryBufferAge, определяют соответственно размер буфера памяти и максимальный возраст данных в буфере.

Обратите внимание, что при конфликтующей конфигурации прокси выведет ошибку и не сможет запуститься, например, если:

  • ProxyBufferMode установлено в "hybrid" или "memory", а ProxyMemoryBufferSize — в "0";
  • ProxyBufferMode установлено в "hybrid" или "memory", а ProxyLocalBuffer — не в "0".

Локаль

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

Расчет очередей во время обслуживания

Прокси Zabbix не знает о периодах обслуживания; подробности см. в разделе Расчет очередей во время обслуживания.