Как сжать базу Zabbix (PostgreSQL)

Zabbix прекрасная и, возможно, лучшая система мониторинга IT-инфраструктуры.
Одно из его преимуществ - низкий порог вхождения. По сути - поставил сервер, агент и вперёд собирать метрики!

К сожалению, у этой простоты есть и оборотная сторона. Далеко не всегда люди разбираются в системе, её параметрах и том, как правильно их настраивать.

Одним из проявлений этого является проблема неконтролируемого распухания базы.

Чаще всего это возникает при некорректно подобранных параметрах элементов данных. Например: малый “Update interval” + большой “History storage period” + много хостов с такими элементами данных.

Хуже всего, когда при этом ещё и не настроен (либо игнорируется) мониторинг свободного места на разделе с базой. Рано или поздно это приводит к такому результату.

pgsql disk space usage 1

Для избежания подобной ситуации необходимо руководствоваться рекомендациями по планированию базы и не жадничать с глубиной хранения данных в истории (см. разницу между историей и трендами “History and trends”).

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

Порядок уменьшения размера базы

Что же делать, если всё-таки база распухла?
Первое, что должно быть сделано - это выявление и исправление неоптимальных настроек.

Оптимизация сбора и хранения данных

1) Найдите лишние хосты Удалите или отключите их.

disable or delete host

2) Найдите лишние шаблоны Возможно вы тестировали какие-то шаблоны с Zabbix Share, возможно создавали шаблоны для какой-то конкретной уже не актуальной задачи. Возможно вы просто собираете много лишних данных :)
Удалите их. При это важно не забывать разницу между действиями “Delete” и “Delete and clear”:

  • Первое удалит лишь шаблон, оставив все айтемы и триггеры на хостах, к которым он был прилинкован;
  • Второе удалит и шаблон и данные

delete template

3) Проанализируйте все шаблоны и найдите криво настроенные айтемы

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

Например, скриншот ниже.

bad template

Конечно, возможно, вам действительно очень необходимо хранить данные по производительности памяти с двадцатисекундными интервалами в течении недели. Если так - будьте готовы заплатить за эторазмером базы. Если нет - просто уменьште эти параметры в несколько раз.

4) Если совсем лень - можно не заморачиваться с отдельными шаблонами, а задать History и Trends интервалы на уровне всей системы Для этого в разделе Administration -> General -> Housekeeping необходимо задать соответствующие периоды и проставить чекбокс “Override … period”

override houskeeping

Уменьшение размера базы

После того, как найдены и устранены причины раздувания базы можно приступить к её “сдуванию” чтобы высвободить дисковое пространство. Для этого нужно сделать следующее.

1) Подключиться к Postgress, выбрать базу zabbix

zabbix=# psql

postgres=# \c zabbix
psql (9.2.18, server 9.6.4)

2) Определить размер базы

zabbix=# SELECT pg_size_pretty(pg_database_size('zabbix'));
    pg_size_pretty
----------------
    95 GB
(1 row)

3) Определить размеры таблиц (первыее 20 по размеру)

zabbix=# SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
    FROM pg_class C
    LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
    WHERE nspname NOT IN ('pg_catalog', 'information_schema')
    AND C.relkind <> 'i'
    AND nspname !~ '^pg_toast'
    ORDER BY pg_total_relation_size(C.oid) DESC
    LIMIT 20;

            relation          | total_size
---------------------------+------------
    public.history            | 59 GB
    public.history_uint       | 21 GB
    public.history_text       | 6532 MB
    public.trends             | 5257 MB
    public.trends_uint        | 2545 MB
    public.history_str        | 347 MB
    public.events             | 264 MB
    public.alerts             | 248 MB
    public.event_recovery     | 63 MB
    public.items              | 29 MB
    public.item_discovery     | 18 MB
    public.history_log        | 11 MB
    public.event_tag          | 8776 kB
    public.auditlog           | 7568 kB
    public.sessions           | 6864 kB
    public.problem            | 5088 kB
    public.items_applications | 4936 kB
    public.graphs             | 4088 kB
    public.triggers           | 3872 kB
    public.graphs_items       | 3528 kB
(20 rows)

4) Удалить данные из таблиц, старше желаемого времени

\set history_interval 7
\set trends_interval 90

zabbix=# DELETE FROM history where age(to_timestamp(history.clock))> (:history_interval * interval '1 day');
zabbix=# DELETE FROM history_uint where age(to_timestamp(history_uint.clock))> (:history_interval * interval '1 day') ;
zabbix=# DELETE FROM history_str where age(to_timestamp(history_str.clock))> (:history_interval * interval '1 day') ;
zabbix=# DELETE FROM history_text where age(to_timestamp(history_text.clock))> (:history_interval * interval '1 day') ;
zabbix=# DELETE FROM history_log where age(to_timestamp(history_log.clock))> (:history_interval * interval '1 day') ;
zabbix=# DELETE FROM trends where age(to_timestamp(trends.clock))> (:trends_interval * interval '1 day');
zabbix=# DELETE FROM trends_uint where age(to_timestamp(trends_uint.clock))> (:trends_interval * interval '1 day') ;

Больше полезных SQL запросов для Zabbix можно взять тут.

5) Выполнить сжатие базы

zabbix=# VACUUM FULL;

6) Проверить размер базы после сжатия

zabbix=# SELECT pg_size_pretty(pg_database_size('zabbix'));
    pg_size_pretty
----------------
    15 GB
(1 row)

Ещё раз посмотрим топ-5 таблиц по размеру

            relation          | total_size
---------------------------+------------
    public.history            | 8521 MB
    public.history_uint       | 3508 MB
    public.history_text       | 1554 MB
    public.trends             | 1105 MB
    public.trends_uint        | 645 MB

Итого размер занимаемого дискового пространства уменьшлся более чем в 6 раз.

pgsql disk space usage 2