Zabbix + Housekeeper + PostgreSQL + Vacuum ( Оптимизация использования дискового пространства Zabbix в связке с PostgreSQL. )

OS: Linux Debian Lenny/Squeeze.
Application: Zabbix Server 1.8/2.0.

Задача: явно настроить контроль за объёмом используемого Zabbix-сервером и СУБД PostgreSQL дискового пространства при обеспечении работы сервиса мониторинга.

По умолчанию, "действия" и "события" системы мониторинга Zabbix не хранятся более 365 дней. Этот параметр можно произвольно изменять в процессе конфигурирования каждого элемента мониторинга индивидуально или задавать обобщение с помощью шаблона; ничто не мешает нам задать для какого-нибудь параметра срок хранения данный в течении одного дня, например.

Для удаления данных с истёкшим сроком хранения в Zabbix-сервере есть специальная подсистема, называемая "Housekeeper". Регулярно, в соответствии с заданными параметрами, подсистема отрабатывает удаление старых данных. Всё просто, настраиваемо в общем конфигурационном файле Zabbix:




Ничто не совершенно; это касается и способа запуска утилиты очистки баз Zabbix от устаревшей информации. К сожалению, нельзя явно задать время старта "Housekeeper"; можно лишь задавать время относительно предыдущего запуска. А как было бы хорошо задать старт очистки в середине ночи, чтобы к утру уже завершилась как очистка, так и последующая оптимизация с помощью "vacuum".

После удаления части данных таблицы "фрагментируются". Не будем здесь говорить о том, как это сказывается на характеристиках скорости доступа к таблице, заметка больше о проблеме разрастания таблиц баз в размере. PostgreSQL последних версий, с интегрированным и настроенным "autovacuum" (что уже сделано по умолчанию, в Debian Lenny для PostgreSQL 8.3/8.4, например), самостоятельно пытается оптимизировать таблицы, перераспределяя данные и размечая как доступное высвобожденное пространство, занятое ранее удалёнными данными, отслеживая изменения на уровне таблиц. Оно вроде-бы и хорошо, в принципе, но на деле настройки по умолчанию побуждают запускаться "vacuum" каждую минуту, дёргая базу ради обработки двадцати-тридцати строк, больше тормозя систему целом, нежели давая какой-то выигрыш в производительности. Понятно, что в большом, сложном "enterprise" проекте, со множеством сервисов, изменяющемся функционале, часто подвергающемся масштабированию, стоит настроить "autovacuum", отвечающий общим потребностям и целям; проще потерять чуть-чуть на автоматизации, чем вручную выискивать слабые места - но не в нашем случае, со "standalone" сервером мониторинга. Не уверен, но не думаю, чтобы кто-то эксплуатировал нагруженный Zabbix-сервер, разделяя ресурсы СУБД PostreSQL с другими сервисами. По сути, "база данных" - самое узкое место в разветвлённой системе мониторинга, от неё добиваются максимальной производительности при том, что задачи СУБД ограничены и ручная настройка ряда параметров вполне приемлема.

В общем, я предлагаю отключать "autovacuum" в PostgreSQL, в том случае, если кроме Zabbix её более никто не использует, планируя процедуру оптимизации на то время, когда система мониторинга предположительно наименее загружена обработкой поступающих и запрашиваемых данных.

Оптимизируем параметры запуска PostgreSQL, позволяющие более эффективно отрабатывать утилите "vacuum" и отключаем функционал "autovacuum":



Останавливаем Zabbix-сервер, перезапускаем PostgreSQL и снова запускаем Zabbix-сервер:


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



В примере выше мы запустили утилиту "vacuumdb" в режиме параллельного с клиентскими обращениями исполнения, без перераспределения данных, лишь с разметкой высвобожденного пространства как готового к использованию и анализом структуры для оптимизации запросов к таблицам. Ежедневный проход утилиты позволит стабилизировать размер базы на определённом уровне, но не даст выигрыша в доступном дисковом пространстве после массированного удаления данных, как этого хотелось бы иногда ожидать. Для высвобождения дискового пространства следует провести более глубокое "вакуумирование", которое буквально высвободит занятое пустыми блоками дисковое пространство; но для этого потребуется блокировка базы от клиентских обращений - такое можно себе позволить лишь изредка, во время профилактики или реструктуризации:


В качестве дополнительной пищи для размышлений, применяющим PostgreSQL (или даже MySQL) в качестве СУБД для Zabbix в качестве сервера мониторинга с тысячами субъектов мониторинга, рекомендую присмотреться к секционированию (partition) таблиц, например по дням или месяцам, что позволит повысить производительность самой СУБД в работе и упростит управление архивами данных, позволяя при необходимости просто удалять старые куски таблицы.