PostgreSQL Zabbix пухнет: сократите history/trends и проверьте housekeeper

Короткий ответ

База растёт, потому что NVPS × срок хранения history не сходится с диском, а не «PostgreSQL сломан». Сократите history на высокочастотных item (не годы на 10s CPU), оставьте trends для длинных графиков, убедитесь, что housekeeper реально удаляет (или TimescaleDB compression/retention в поддерживаемой схеме 6.0/7.0). Не TRUNCATE history в бою и не выключайте housekeeper «чтобы не грузило». Нагрузка чистки — housekeeper перегружает. Очередь из-за диска — очередь. Мусор item: LLD.

Хост БД часто тот же 10.0.20.50 / zabbix.example.

Симптомы и как отличить

Типичная картина:

• df на томе PostgreSQL +N ГБ/день;
• автовакуум вечно active;
• графики за год открываются минутами;
• после отключения housekeeper диск «стабилизировался ростом» ещё быстрее.

Отличия:

Возможные причины

1. Шаблон с history 90d на item интервала 10s (метрика: десятки миллионов строк на ключ).
2. Trends включены, но history не урезан — оба жирные.
3. Housekeeper не успевает (MaxHousekeeperDelete слишком мал/велик — см. соседнюю статью), DeleteData выключен.
4. LLD наплодил item на каждую docker fs.
5. Override периодов не задан, в item «Do not override» + дефолт шаблона огромный.
6. Timescale не настроен, ожидали compression «из коробки» без работы.
7. Редко: хранят blob/тексты логов в history (log item без фильтра).

Диагностика

1. Размер БД и топ отношений

SELECT pg_size_pretty(pg_database_size('zabbix'));
SELECT relname, pg_size_pretty(pg_total_relation_size(c.oid))
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public'
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 20;

2. NVPS

График zabbix[nvps] на сервере. Оценка диска history грубо: NVPS × 50–100 байт × 86400 × дни (порядок, не бухгалтерия). Если NVPS 5000 и history 90d — это не «маленькая VM на 40 ГБ».

3. Периоды в UI

Administration → General → Housekeeping: History/Trends включены? Сроки. Затем на шаблоне типичного хоста WS-042: item system.cpu.util History/Trends.

В 6.0/7.0 удобно Override item history/trend period на уровне шаблона или глобально (смотрите раздел Housekeeping / Overrides вашей версии UI).

4. Работает ли удаление

График zabbix[process,housekeeper,avg,busy] и лог:

sudo grep -i housekeeper /var/log/zabbix/zabbix_server.log | tail -n 30

Строки deleted/duration. Если duration часы и deleted мало — не успевает, диск продолжит расти.

Решение

Сценарий A. Урезать history, сохранить trends

Практика для CPU/интерфейсов: history 7–14d, trends 1–2y. Для DISASTER-метрик диска history 30d ок. Для LLD-мусора — сначала фильтр, потом период.

Меняйте шаблоном, не 5000 item руками. Дождитесь housekeeper: место освободится не сразу (PostgreSQL держит файлы до vacuum). После больших delete:

-- только после backup и в окно, по конкретным таблицам, не «VACUUM FULL всей БД без оценки»
VACUUM (ANALYZE) history_uint;

VACUUM FULL блокирует и требует временного места. Не первый шаг.

Сценарий B. Overrides

Включите глобальные пределы history, чтобы один «забытый» item на 3650d не убил диск. Документируйте исключение для юридически нужных метрик.

Сценарий C. Снизить NVPS

Интервалы 10s → 60s там, где 10s не меняют решение. Dependent items вместо десяти сырых. Выкинуть шаблоны «на всякий».

Сценарий D. TimescaleDB

Если у вас поддерживаемая связка Zabbix 6/7 + Timescale — compression и retention политики по документации этой связки. Не копируйте SQL с форума для другой major.

Сценарий E. Логи в Zabbix

log[] с полным journal — это не мониторинг, это SIEM-пародия. Фильтры, редкий item, короткий history.

Как проверить, что проблема устранена

Суточный прирост pg_database_size упал на порядок после завершения housekeeper+vacuum. NVPS снизился, если резали интервалы. Графики за 3 месяца всё ещё строятся из trends. Диск не упирается в 95%. Снапшот прироста запишите в заявку «было +8 ГБ/день, стало +0.5».

Если не помогло

• Размер не падает после урезания period: строки ещё в сроке, или vacuum не идёт, или вы смотрите TOAST/indexes.
• Растёт events: храните события не годы, чистите OK events.
• Растёт auditlog: срок аудита в Administration.
• WAL на весь диск: archive_command пишет в полный NFS — это не history.

Профилактика

• Бюджет диска в проекте мониторинга до подключения 200 хостов.
• Алерт на vfs.fs.size тома БД и на прирост за сутки.
• Шаблон housekeeping defaults в git/документации.
• Не давать всем админам ставить history 365d в UI без ревью.

Посчитайте бюджет диска до закупки, а не после алерта 95%. NVPS, срок history и размер строки дают порядок гигабайт; сверху индексы, trends, WAL и запас под vacuum. Если том 100 ГБ «на всё», вы не оптимизируете PostgreSQL, вы обязаны укоротить history. Housekeeper не сжимает данные магией, он удаляет строки в пределах period.

Не храните log item с полным текстом журнала «на всякий случай». Windows Event и Linux journal — только фильтр и дни, не месяцы. Иначе топ pg_relation_size будет history_text, а не uint, и поведение VACUUM станет менее предсказуемым.

Снимок прироста pg_database_size за сутки до и после смены period — обязательный артефакт заявки. Без цифры «вроде перестало расти» через три дня окажется, что смотрели не ту инстанцию.

FAQ

Trends заменяют history?

Для минутного графика за вчера — нет. Для «как было полгода» — да. Нужны оба с разными сроками.

Можно ли хранить history в Elasticsearch и выкинуть SQL?

Интеграции менялись между версиями. Не переносите историю на внешнее хранилище по статье 2018 года без сверки с 6.0/7.0 LTS docs. Сначала periods.

Удалить старые партиции руками?

Только если у вас документированное партиционирование/Timescale. Слепой DROP history_uint_old с выдуманным именем — путь к мёртвому серверу.

Почему после VACUUM FULL снова рост

NVPS не изменился. FULL дал место обратно ОС, заполнение продолжается тем же темпом.

MySQL так же?

Да: топ таблиц history*, innodb file size, те же рычаги Zabbix. Команды СУБД другие.

Нужно ли чистить history, чтобы ускорить очередь?

Косвенно: больной диск тормозит syncer. Прямая очередь — pollers. Смотрите оба слоя.