Упражнения с Zabbix Server и TimeScaleDB, часть 1

... Даже и не предполагал, что обновить корпоративный Zabbix Server с 5.0 LTS на 6.0 LTS окажется настолько трудно. В моём случае тому есть множество причин.

1. Используется TimeScaleDB с компрессией данных.


2. Несколько лет тому назад после обновления с 4.0 до 5.0 я поленился сделать апгрейд БД до Double Precision (как-то каши особо не просило).


3. Овердохрена метрик (местами по 60 тысяч на один хост) и срок хранения истории в полгода. Как следствие, БД весит в районе 80 гигабайт (после сжатия TimeScale).


4. Изначально тухловатые версии софта-обвязки: Postgres 12, TimeScaleDB 1.7, PHP 7.3, Debian 10 и всё вот это.


5. В 6й версии Zabbix хочет наличия дополнительных Primary Keys в History-таблицах, при этом он сам их туда добавить при миграции не может. Ибо есть ненулевая вероятность наличия повторяющихся строк.


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

В первой серии журнала "Мурзилка" я опишу свои упражнения с TimeScaleDB. Потому что.

• Продвигаться дальше без перехода на Double Precision уже не получится, т.к. "шестерка" хочет работать только с оным.


• Чтобы перейти на Double Precision, нужно сделать ALTER TABLE, но в сжатых chunk-ах TimeScaleDB никаких изменений вносить уже не допускается.


• Имеет место классический Dependency Hell. Потому что определённые даже минорные версии Zabbix Server умеют работать только с определёнными версиями TimeScaleDB и PHP. TimeScaleDB в свою очередь хочет определённых версий Postgres-а. И конечно же, имеющиеся в "родных" репозиториях Debian-а пакеты "не срастаются" между собой.

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

1. Сам Zabbix Server до последней минорной версии.


2. TimeScaleDB до последней версии, которую ещё умеет Postgres. Если Postgres слишком тухлый, то придется сделать несколько итераций.


3. Если TimeScale обновляется с 1.x до 2.11, то надо идти транзитом через 2.10.1, пушо уже в 2.10.2 сломали скрипты миграции.


4. Postgres до 15го.


5. Дистрибутив Linux-а. Но если это Debian, то не дальше чем до 11го, иначе "разъедется" PHP и libssl.


6. Шаманство с БД, добавление первичных ключей в history-таблицы.


7. Обновление Zabbix-сервера и всех проксей до "шестёрки".


8. Обновление дистрибутива Linux до последнего актуального.

Теперь конкретно про TimeScaleDB.

Начнём с того, что после 2-й версии пакетики с оными делятся на две категории. В имени одной есть буковки "-oss-", а в другой нет. Дык вот, та которая с буквами "-oss-", не умеет в компрессию ввиду лицензионных заморочек. До этого тоже надо каким-то образом догадаться и потом принять во внимание.

Далее, чтобы распаковать когда-то ранее запакованные chunk-и, нужно проделать нижеследующее, можно без остановки сервиса.

Перво-наперво отключить компрессию в настройках в веб-морде самого Zabbix-а. Иначе он тут же сожмет обратно то, что вы будете долго и мучительно расжимать.

Далее нужно найти идентификторы (номера) job-ов сжатия гипертаблиц history, trends и выключить их. В моем примере это 1000 и 1005, но вообще они могут быть любыми.

Собственно расжать chunk-и. Это надолго. На SSD-шках бежит пару часов. Главное чтобы ещё места хватило, потому что база может раздуться в полтора-два раза.

После того, как все chunk-и разжаты, нужно отключить компрессию. Без этого ALTER не сделать.

И только теперь можно ALTER. Но, строго при остановленном Zabbix Server. У меня на SSDшках он бежал где-то полчаса суммарно. На шпинделях 50 минут. В "официальной" инструкции написано делать "ALTER TABLE ONLY", но реально такое не отработает. Поэтому на самом деле без "ONLY" надо.

После этого можно запускать взад Zabbix Server и разрешить компрессию под капотом TimeScaleDB.

В настройках "zabbix.conf.php" раскомментировать / добавить / изменить строчку чтобы стало true, иначе веб-морда не прочухает, что там уже внезапно double precision попёрла.

Опосля всех этих манипуляций можно вернуть взад "галку" в веб-интерфейсе "Enable compression". Через какое-то время демон Zabbix-а сам восстановит все job-ы TimeScaleDB. А можно и не включать, потому что всё равно потом первичные ключи ещё добавлять. "Но это уже совсем другая история". ©

Продолжение следует.