Прокси

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

Кроме того, использование Прокси – это самый простой способ осуществления централизованного и распределённого мониторинга, при котором все Агенты и Прокси отчитываются перед одним Сервером и все данные собираются в централизованном порядке.

Прокси можно использовать для:

мониторинга удаленных мест;
мониторинга в местах с ненадёжной связью;
снижения нагрузки на Сервер при мониторинге тысяч устройств;
упрощения обслуживания распределенного мониторинга.

Прокси требует только одно TCP-соединение к Серверу. Таким образом, будет проще настроить обход брандмауэра, потребуется настроить только одно правило в брандмауэре.

Прокси должен использовать отдельную базу данных. Если указать базу данных Сервера, то конфигурация будет испорчена.

Все данные, собранные Прокси, до отправки их Серверу хранятся локально. Таким образом, данные не теряются из-за временных проблем со связью с Сервером. Параметры ProxyLocalBuffer и ProxyOfflineBuffer в файле конфигурации Прокси управляют длительностью локального хранения данных.

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

Прокси – сборщик данных. Он не вычисляет триггеры, не обрабатывает события и не отправляет оповещения. Для обзора возможностей Прокси предлагается таблица 159.

Примечание – Чтобы убедиться, что Агент запрашивает активные проверки у Прокси (а не у Сервера), именно Прокси должен быть указан в параметре ServerActive файла конфигурации Агента.

Защита от перегрузки

Если Сервер был остановлен на какое-то время и Прокси собрали много данных, а затем Сервер запустился, он может оказаться перегруженным (использование кэша истории некоторое время остаётся на уровне 95-100%). Эта перегрузка может привести к падению производительности, при этом проверки обрабатываются медленнее, чем должны. Чтобы избежать проблем, возникающих из-за перегрузки кэша истории, была реализована защита от такого сценария.

Когда кэш истории Сервера полностью заполнен, доступ на запись в кэш истории ограничивается, что приводит к задержке процессов сбора данных Сервера. Наиболее распространенный случай перегрузки кэша истории – после останова Сервера, когда Прокси-серверы пересылают собранные данные. Чтобы избежать этого, был добавлен троттлинг Прокси (его нельзя отключить).

Сервер остановит приём данных от Прокси, когда использование кэша истории достигнет 80%. Вместо этого эти Прокси будут помещены в список троттлинга. Это будет продолжаться до тех пор, пока использование кэша не упадёт до 60%. В этом случае Сервер начнёт принимать данные от Прокси по очереди, определенной списком троттлинга. Это означает, что первый Прокси-сервер, который пытался выгрузить данные в течение периода троттлинга, будет обслужен первым, и до тех пор, пока он не завершит, Сервер не будет принимать данные от других Прокси.

Этот режим троттлинга будет продолжаться до тех пор, пока или использование кэша снова не достигнет 80%, или не упадет до 20%, или пока список троттлинга не опустеет. В первом случае Сервер снова перестанет принимать данные Прокси. В остальных двух случаях Сервер начнёт работать как обычно, принимая данные со всех Прокси.

Приведённую выше информацию можно проиллюстрировать таблицей 160.

Можно использовать внутренний элемент данных zabbixwcache,history,pused, чтобы скоррелировать это поведение Сервера с метрикой.