Housekeeper на 10.0.20.50 жрёт диск: снизьте темп очистки, не выключайте её

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

Housekeeper, который кладёт 10.0.20.50, нельзя «вылечить» HousekeepingFrequency=0 и выключенным удалением данных: таблицы начнут расти до падения диска. Нужно: уменьшить объём удаляемого за проход (MaxHousekeeperDelete), не совмещать проход с backup/VACUUM FULL, урезать history чтобы проход был маленьким, при Timescale — штатные retention, не двойная чистка. Рестарт zabbix-server сбрасывает пик на минуту и ничего не чинит.

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

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

• ровно в HH:00 диск 100%, CPU в postgres и zabbix_server;
• internal item housekeeper busy высокий часами;
• очередь растёт только в это окно, потом падает;
• лог: housekeeper ... deleted ... с огромным duration.

Отличия:

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

1. Слишком большой backlog (месяцы не чистили).
2. MaxHousekeeperDelete не соответствует версии (0 = unlimited).
3. History 90d × огромный NVPS — каждый цикл удаляет миллионы строк.
4. Одновременно pg_dump, autovacuum wraparound, housekeeper.
5. Удаление events/sessions/audit в том же проходе, всё сразу.
6. Редко: отсутствие индексов на history после «ручной оптимизации».

Диагностика

1. Конфиг

sudo grep -E '^Housekeeping|^MaxHousekeeper' /etc/zabbix/zabbix_server.conf
sudo grep -i housekeeper /var/log/zabbix/zabbix_server.log | tail -n 50

Сверьте смысл MaxHousekeeperDelete в шапке файла пакета (комментарии upstream).

2. UI Housekeeping

Administration → General → Housekeeping: галки History, Trends, Events, Services, Audit, Sessions. Частоты. Если всё включено с агрессивными сроками на гигантской базе — удар суммируется.

3. PostgreSQL во время пика

SELECT pid, wait_event_type, wait_event, state, left(query,120)
FROM pg_stat_activity
WHERE datname = 'zabbix'
ORDER BY query_start;

DELETE по history_* + lock — housekeeper. COPY — dump.

4. Размер backlog

Если периоды только что урезали с 365d до 14d, housekeeper будет неделями догонять. Это ожидаемо: снижайте темп, не выключайте.

Решение

Сценарий A. Снизить удар за цикл

Поставьте MaxHousekeeperDelete на умеренное значение (в комментарии пакета типичны тысячи–сотни тысяч строк за таблицу/проход — прочитайте свой файл). Цель: цикл заканчивается за минуты, не часы. Частоту HousekeepingFrequency не ставьте 1 час при тяжёлом DELETE, если диск слабый: реже, но лимит строк.

sudo -u zabbix zabbix_server -c /etc/zabbix/zabbix_server.conf -T
sudo systemctl restart zabbix-server

Сценарий B. Развести расписания

Окно pg_dump / snapshot hypervisor ≠ пик housekeeper. Ночной backup VM zabbix.example не вместе с VACUUM FULL.

Сценарий C. Уменьшить работу вообще

Короче history = меньше DELETE навсегда. Это главный рычаг. LLD-мусор не хранить. См. рост базы.

Сценарий D. Timescale / партиции

Удаление drop partition дешевле row-delete. Делайте только по официальной схеме для вашей версии. Не включайте параллельно агрессивный SQL-housekeeper на тех же кусках «на всякий случай» без понимания.

Сценарий E. Ручной догон после аварии диска

После экстренного урезания period возможен гигантский backlog. Держите лимит DELETE, расширьте диск временно, дождитесь. Не kill -9 postgres посреди DELETE.

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

График busy housekeeper: короткие пики, не плато 100% на час. Очередь сбора в это время не улетает в 10+ min. pg_database_size не растёт как до фикса (чистка идёт). Лог: duration прохода приемлемый, deleted > 0 (не «крутится вхолостую»). Пользователи UI не жалуются на ночной «завис zabbix.example».

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

• Выключили History housekeeping — I/O упал, диск растёт: вы проиграли. Включите обратно с лимитом.
• Timescale job + housekeeper дерут одно: оставьте один механизм retention.
• I/O из wal — checkpoint, не DELETE.
• Proxy не при чём, если пик только на сервере БД; если proxy локально пишет SQLite и его housekeeper — смотрите узел proxy.

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

• Сразу задать реалистичные history/trends.
• Алерт на housekeeper busy и на duration из лога (парсер/item log).
• Календарь: dump, vacuum, housekeeper, патч.
• Тест нагрузки на копии БД перед урезанием 365→7 дней.

Если пик I/O совпадает с pg_dump и autovacuum wraparound, лечите календарь, не только MaxHousekeeperDelete. Разнесите dump, проход housekeeper и тяжёлый vacuum. На 10.0.20.50 один диск под WAL, data и dump гарантирует, что любой DELETE будет «класть сервер». Отдельный том под PostgreSQL часто дешевле недели тыканья лимита удаления.

Когда только что урезали history с года до двух недель, ждите дни догона. Предупредите дежурных: ночью диск будет шуметь, очередь может подрастать, не рестартите zabbix-server. Рестарт рвёт проход и заново ударяет по БД.

Пишите duration прохода из лога в заявку. Если duration растёт при стабильном NVPS, это backlog или деградация диска и индексов, а не повод выключить DeleteData.

Наблюдайте zabbix[process,housekeeper,avg,busy] рядом с iostat на том PostgreSQL. Если housekeeper 8% busy, а диск 100% из-за backup VM zabbix.example, виноват гипервизорный snapshot, не DeleteData. Не отключайте очистку в этой ситуации.

FAQ

Можно ли отключить housekeeper навсегда на SSD?

Нет. SSD не отменяет рост. Retention обязателен.

Почему MaxHousekeeperDelete маленький — база растёт?

Удаляете меньше, чем прибывает за интервал. Нужно либо чаще циклы, либо меньше NVPS/короче history, либо чуть поднять лимит, не до unlimited.

Housekeeper и Timescale compression вместе?

Compression ≠ delete. Нужны политики retention. Читайте howto Zabbix+Timescale для 6.0/7.0, не смешивайте советы.

Стоит ли отдельная БД-машина?

Да, если NVPS большой. Housekeeper всё равно должен быть кротким. Отдельный диск не отменяет MaxHousekeeperDelete.

Удаление events тормозит так же?

Да, если событий миллионы (шум триггеров). Снизьте шум: ложные алерты, сроки events в housekeeping.

Можно ли чистить SQL скриптом вместо housekeeper?

Риск рассинхрона с Zabbix. Если делаете — окно, backup, официальные рекомендации версии. Не cron DELETE FROM history без LIMIT на проде.