База данных Zabbix стала быстро разрастаться

[Kolmik]

Сегодня что-то приключилось странное. База данных zabbix стала разрастаться практически со скоростью 1гб каждую минуту. Из всех изменений что сегодня делал - перенастраивал конфиги zabbix-agent на хостах(добавлял балансировку между прокси) и включил Housekeeping.

Когда место начало резко улетать и заканчиваться - сразу же вернул настройки Housekeeping как было(а было вообще не настроено, всё выключено), но это не помогло - место улетает куда-то.

Куда можно посмотреть?
Менял на такие настройки, сейчас вернул как было - галочки нигде не стоят.

[Alex_UUU]

Скорее всего - это проблема БД, захотела жить своей жизнью. Посмотри, какая табла растет. Ну и какая БД. В Кликхаузе, насколько знаю, специфическое выполнение процедур удаления.

[Griboed0ff]

У меня было похожее когда, включил журналирование аудита(там не работало удаление), ну а так не помешало бы посмотреть в базе какая таблица растет, а далее уже понять откуда ноги растут.

[Kos]

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

Судя по упоминанию балансировки между прокси, могу предположить, что речь идёт о версии Zabbix 7.0.0 (причём, этой версии должны быть и сервер, и все прокси, и все упоминаемые агенты; если это не так - возможны проблемы).

Судя по тому, что housekeeper был отключен вообще, предполагаю, что настроена база данных с партиционированием (т.е. удаление старых данных выполняется средствами базы данных путём удаления сразу целой партиции соответствующих таблиц). Типы баз данных (PostgreSQL/MySQL/MariaDB/Oracle), к сожалению, мой хрустальный шар не показывает.

Настройки Housekeeper-а могут влиять только на очистку таблиц (в первую очередь - хранящих историю и тренды) от старых записей. Если он уже был отключен, то его включение на рост базы повлиять не должно. Значит, повлияли игры с настройками агентов; я бы смотрел в этом направлении.

Например, если ошибиться с конфигурацией агентов и в параметре "ServerActive=" указать несколько прокси-серверов не через точку запятой, а через запятую, то агент будет обращаться не на один прокси (первый из тех, до которых он смог достучаться), а на каждый из них (с возможностью отослать дубликаты собранных данных). Если к тому же эти прокси не объединены в прокси-группу, но включена авторегистрация активных агентов, то каждый из проксей будет говорить серверу, что этот хост мониторится через него, и сервер будет то и дело менять конфигурацию конфигурацию хоста, заполняя аудитный лог.

[Kolmik]

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

Прошу прощения, я сразу хотел дополнить первое сообщение в теме, но не мог - почему-то все мои посты помечается тэгом unapproved и требующими проверки со стороны модератора.
У меня все сервера Zabbix и прокси обновлены до версии 7.0.0, агенты сейчас в процессе обновления. Так как хостов очень много - то конечно до сих пор остались со старой версией агента, но там и конфиг старый, без балансировки. Остановить разрастание базы - помимо отключения Housekeeping смог только рестартом службы postgres. Думаю именно включение Housekeeping послужило катализатором для этого, а пока я не рестартанул postgres - какие-то процессы оставались и продолжали работать.

Судя по тому, что housekeeper был отключен вообще, предполагаю, что настроена база данных с партиционированием (т.е. удаление старых данных выполняется средствами базы данных путём удаления сразу целой партиции соответствующих таблиц). Типы баз данных (PostgreSQL/MySQL/MariaDB/Oracle), к сожалению, мой хрустальный шар не показывает.

У нас старый сотрудник, который этим занимался - уволился, сам я раньше никогда Zabbix не занимался, пытаюсь разобраться на ходу, читая документацию и форумы. Поэтому не совсем представляю было ли партиционирование настроено, по-моему предположению - не было сделано вообще ничего.
Debian GNU/Linux 12 (bookworm), база данных на PostgreSQL 13.11.

Топ20 таблиц по весу:
relation | total_size
--------------------------+------------
public.history_text | 554 GB
public.history_uint | 378 GB
public.history | 330 GB
public.trends_uint | 67 GB
public.trends | 33 GB
public.item_discovery | 13 GB
public.auditlog | 6190 MB
public.trigger_discovery | 2150 MB
public.history_str | 522 MB
public.events | 509 MB
public.alerts | 431 MB
public.items | 381 MB
public.graph_discovery | 287 MB
public.housekeeper | 209 MB
public.history_log | 208 MB
public.event_tag | 106 MB
public.problem_tag | 64 MB
public.item_tag | 63 MB
public.item_rtdata | 58 MB
public.triggers | 56 MB
(20 rows)

А вот информация по таблицам которую я получил вчера сразу после перезапуска postgres, после чего место стало уменьшаться с прежней скоростью(инфа только по таблицам, которые изменились):
relation | total_size
--------------------------+------------
public.history_text | 543 GB
public.history_uint | 374 GB
public.history | 324 GB
public.trends_uint | 66 GB

указать несколько прокси-серверов не через точку запятой, а через запятую, то агент будет обращаться не на один прокси (первый из тех, до которых он смог достучаться), а на каждый из них

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

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

1. Прокси объединены в группу
2. Авторегистрация отключена в настройках веб-интерфейса Zabbix, так как ещё до создания балансировки прочитал, что она работать не будет. Однако возможно она осталась где-то в конфигах агентов, параметр ### Option: HostMetadata, который отвечает за авторегистрацию.

[Griboed0ff]

2. Авторегистрация отключена в настройках веб-интерфейса Zabbix, так как ещё до создания балансировки прочитал, что она работать не будет

Не могли бы вы мне показать где было такое написано? Я видел такие новости, но для других версий, где балансировка производилась скриптами через апи. Но по 7 версии и встроенной балансировке, я пока не нашел новостей о нерабочей авторегистрации активных агентов.
В документации я нашел только о том что авторегистрация работает:

When a host is created based on auto registration/network discovery data from a proxy belonging to proxy group - then this host is set to be monitored by this proxy group.

[Kos]

Присоединяюсь к вопросу.

[Kolmik]

Не могли бы вы мне показать где было такое написано? Я видел такие новости, но для других версий, где балансировка производилась скриптами через апи. Но по 7 версии и встроенной балансировке, я пока не нашел новостей о нерабочей авторегистрации активных агентов.
В документации я нашел только о том что авторегистрация работает:

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

Хотел спросить по timescaledb
https://www.zabbix.com/documentation...#configuration Overview
Zabbix supports TimescaleDB, a PostgreSQL-based database solution of automatically partitioning data into time-based chunks to support faster performance at scale.
Currently, TimescaleDB is not supported by Zabbix proxy.

Получается, если у меня куча прокси и балансировка - у меня не получится использовать TimescaleDB?

[Kos]

Получается, если у меня куча прокси и балансировка - у меня не получится использовать TimescaleDB?

У сервера Zabbix и у каждого Zabbix прокси - своя собственная база данных.Они могут быть разных типов. Так, самый простой вариант для Zabbix прокси - использовать базу SQLite (которая не поддерживается для Zabbix сервера). В свою очередь, TimescaleDB поддерживается для сервера Zabbix, но не поддерживается для Zabbix прокси (тем более, она там и не нужна - прокси не хранит долговременную информацию).

[Kolmik]

А ещё такой вопрос по TimescaleDB - если у меня база 2тб, то потом при выполнении скрипта schema.sql, который осуществляет миграцию данных - сколько нужно свободного места на сервере, чтобы скрипт отработал? Столько же сколько и база весит?
И по времени не совсем понятно какой простой должен быть у zabbix, чтобы 2тб данных переконвертировалось.

[Griboed0ff]

А ещё такой вопрос по TimescaleDB - если у меня база 2тб, то потом при выполнении скрипта schema.sql, который осуществляет миграцию данных - сколько нужно свободного места на сервере, чтобы скрипт отработал? Столько же сколько и база весит?
И по времени не совсем понятно какой простой должен быть у zabbix, чтобы 2тб данных переконвертировалось.

Непонятно откуда куда мигрируете и что пытаетесь сделать. Конечно запас пространства должен быть не менее необходимого, а перед началом любых действий обязательно сделать полный бэкап. Простой зависит от вашей конфигурации машины, на которой база. Я ранее имел базу postgresql ~2тб, и для того чтобы включить TimescaleDB тоже хотел партиционировать огромные таблицы истории, но потом решил отказаться от этой затеи, так как оказалось все эти данные оказались никому не нужны. Я просто оставил последние месяц два в историях, остальное осталось в бэкапе на всякий случай. Партиционирование в варианте урезанной истории прошло довольно быстро.
Ваши вопросы больше относятся к администрированию БД, чем к заббикску. И есть ощущение, что вам будет сложно, надеюсь вы сделаете все на тесте, а уже потом на проде.

[Griboed0ff]

Если вернутся к изначальному вопросу о росте базы, то я бы все таки выяснил бы установлен ли TimescaleDB и партиционированы ли таблицы. Например так

[root@0001zabdb01 ~]# psql -U postgres -d zabbix
psql (9.2.24, server 14.8)
WARNING: psql version 9.2, server version 14.0.
         Some psql features might not work.
Type "help" for help.

zabbix=# \dx
                                                 List of installed extensions
      Name      | Version |   Schema   |                                     Description
----------------+---------+------------+--------------------------------------------------------------------------------------
 pg_buffercache | 1.3     | public     | examine the shared buffer cache
 plpgsql        | 1.0     | pg_catalog | PL/pgSQL procedural language
 tablefunc      | 1.0     | public     | functions that manipulate whole tables, including crosstab
 timescaledb    | 2.11.1  | public     | Enables scalable inserts and complex queries for time-series data (Apache 2 Edition)
(4 rows)

zabbix=# SELECT hypertable_name
zabbix-# FROM timescaledb_information.hypertables;
 hypertable_name
-----------------
 history_text
 trends
 trends_uint
 history
 history_uint
 history_str
 history_log
(7 rows)

zabbix=#

Когда я начал работать с Zabbix, то столкнулся с проблемой быстрого роста базы данных, и похоже, что ваш процесс очистки данных тоже не работает должным образом. Ваши симптомы очень напоминают мои: таблицы истории занимают гораздо больше места, чем тренды, хотя логично, что год данных должен занимать больше пространства, чем неделя. Попробуйте сделать запрос к базе данных, чтобы найти самую старую запись в таблице, например, в history_text, где есть временная метка. Вы, вероятно, обнаружите, что она намного старше, чем указано в настройках удаления данных.

Если это действительно так, то вашими действиями по исправлению проблемы должны стать переопределение интервалов хранения данных. Проблемы возникают, когда для разных элементов данных установлены различные периоды хранения. Как мы знаем, TimescaleDB удаляет данные чанками, и если интервалы хранения истории для каждого элемента разные, то данные не могут быть удалены и накапливаются. Поэтому, если вы используете TimescaleDB, убедитесь, что все элементы данных имеют одинаковый срок хранения. Просто снимите галочку с "override item history period", примените изменения, затем верните галочку обратно и снова примените изменения.

[Kolmik]

Если это действительно так, то вашими действиями по исправлению проблемы должны стать переопределение интервалов хранения данных. Проблемы возникают, когда для разных элементов данных установлены различные периоды хранения. Как мы знаем, TimescaleDB удаляет данные чанками, и если интервалы хранения истории для каждого элемента разные, то данные не могут быть удалены и накапливаются. Поэтому, если вы используете TimescaleDB, убедитесь, что все элементы данных имеют одинаковый срок хранения. Просто снимите галочку с "override item history period", примените изменения, затем верните галочку обратно и снова примените изменения.

У меня не стоит ещё расширение TimescaleDB, я сделал снэпшот виртуалки, установил TimescaleDB, начал конвертацию таблиц, но из-за их большого размеру у меня скоро улетело всё свободное место и мне пришлось откатиться из снэпшота.
Поэтому возникает вопрос как бы сначала уменьшить размер таблиц, а потом уже выполнить конвертацию. В данный момент housekeeper отрабатывает, но в логах он ничего не удаляет. Думал может как-то вручную удалить старые данные из таблицы.

[Griboed0ff]

У меня не стоит ещё расширение TimescaleDB, я сделал снэпшот виртуалки, установил TimescaleDB, начал конвертацию таблиц, но из-за их большого размеру у меня скоро улетело всё свободное место и мне пришлось откатиться из снэпшота.
Поэтому возникает вопрос как бы сначала уменьшить размер таблиц, а потом уже выполнить конвертацию. В данный момент housekeeper отрабатывает, но в логах он ничего не удаляет. Думал может как-то вручную удалить старые данные из таблицы.

ну удаление из таблиц элементарно:

delete FROM public.history where clock > тут временная метка старше, которой хотите удалить

[Kolmik]

ну удаление из таблиц элементарно:

delete FROM public.history where clock > тут временная метка старше, которой хотите удалить

А в каком формате указывается временная метка? Запросил 100 первых записей из таблицы и 100 последних.

[Kos]

А в каком формате указывается временная метка?

Вероятно, в unixtime (т.е. количество секунд, прошедших с 1 января 1970 года 00:00 по Гринвичу).