Оглавление
По умолчанию, шаблоны Zabbix собирают очень много информации о сервисах Windows, с большой периодичностью — 1 раз в минуту, что на мой взгляд, очень часто. Перед добавлением узлов сети, стоит разработать политику шаблонов. Лучше это сделать заранее, так в последствии с большой БД будет работать намного дольше.
После перехода на новую версию Zabbix, обнаружил резкий рост нагрузки на базу данных. При расследовании причины, выяснилось, очень большое количество элементов с малым интервалом опроса. Данные элементы создаются при использовании шаблона Template OS Windows Log Discovery, а конкретнее правилом авто обнаружения — Windows service discovery, в котором задан интервал опроса в 1 минуту.
Картина выглядит примерно так
Система начала немного притормаживать. Изменения количества обработчиков, количество удаляемых данных в конфигурационном файле zabbix_server.conf, положительного результата не принесли. Отключение функции autovacuum на сервере баз данных тоже не принесло ожидаемого снижения нагрузки. Произведена ревизия не поддерживаемых элементов, которые были отключены. Тем не менее за неделю, размер БД увеличился на 150%
Элементов не очень много, но явное замедление было на лицо. Это и провали в графиках, т.е. отсутствие данных и ложные срабатывания
Вот для этого необходимо проработать политику опроса необходимых элементов. Так, например, наименее критичные сервера можно опрашивать раз в 15-30 минут и наоборот. Для этого необходимо:
Клонировать шаблон Zabbix
Должен получиться абсолютно идентичный шаблон, с полным набором правил обнаружения, триггеров, элементов и групп
Изменить в политике авто обнаружения интервал опроса, для добавляемых элементов
Стоит отметить, что элементы, созданные авто обнаружением можно добавлять как не активные и активировать их в случае необходимости. Все тоже самое касается и других шаблонов. Например для сбора информации о загрузке сетевого интерфейса на не критичных коммутаторах сети. Данные мероприятия позволят снизить нагрузку на базу данных и в тоже время получать информацию о всех узлах и серверах сети. После проделанных действий и очистки базы, очередь опроса исчезла.
Сейчас активно работает housekeeper, оно и понятно, сколько высвободилось места после отключения мониторинга не нужных сервисов и уменьшения интервала опроса
Внесение изменений в PostgreSQL
|
1 2 3 4 5 6 7 8 9 |
# Задаём размер области памяти, выделяемой для операций VACUUM, CREATE INDEX, ALTER TABLE и FOREGIN KEY (при общем объёме ОЗУ в 4Gb рекомендуется выделить около 512MB) maintenance_work_mem = 512MB .... # Выключаем "autovacuum" # autovacuum = off |
|
1 2 3 |
0 22 * * 5 root sudo -u postgres vacuumdb -U postgres --quiet --analyze --dbname=zabbix |
Информация от официалов
Дополнительно
Абсолютно не исследовано, но! в последних версиях ZABBIX, политика изменилась. Если изменить интервал опроса в шаблоне, то данное изменение будет применено к имеющимся хостам. При этом, однозначно, необходимо иметь различные шаблоны для критичных серверов и сетевого оборудования, отличающихся интервалами опроса. Конечно, есть еще и тюнинг БД. Я склоняюсь к PostgreSQL, которая позволяет очень тонко настроить не только параметры движка, но и хранение таблиц различных разделах (читай дисковых массивах), тонкая настройка кеша, можно сказать приближенного к tempdb в MSSQL, размещенного на RAM диске и …
Нет предела совершенства!
Загрузка...
Иметь различные шаблоны, различающиеся интервалами опроса, не нужно. Можно просто в элементе данных или в правиле дискавери указать интервал опроса пользовательским макросом, например {$INTERVAL}, а в шаблоне во вкладке Macros или в глобальной области задать этот макрос, например {$INTERVAL} = 15m. Для отдельного хоста, который важно опрашивать почаще, этот макрос нужно записать в свойствах самого хоста. В 5-й версии zabbix это точно работает.