Комментарии 10
Кровавый энтерпрайз… Часы (дни?) тестов и перелопачивания мануалов и просаженые деньги на виртуалки с 24 cpu. Зато теперь можно в резюме написать, что из 3х годового графика response time не потеряно даже 5 минут. Вот оно — SRE в вакууме. Осталось посчитать окупились ли эти 5 минут для организации...
Работа ради работы...
почему до сих пор заббикс не перевели на временную базу, например тот же ClickHouse
присоединяюсь к вопросу, но пока в Zabbix на это не решились — можно обходными путями это сделать, включить real_time_export, подхватывать изменения в этих файлах и сохранять куда угодно, например — отправлять в Kafka, а уже оттуда — в Clickhouse
Не реклама, но просто попробовать паралельно мониторить еще из под glaber.io и почувствовать разницу.
Еще есть перкрасный бекпорт фич из 5ки в 4ку https://github.com/CHERTS/zabbix_44x_next
В вашем случае можно потерять все данные, которые будут записаны в таблицу history после начала копирования содержимого в history_new (зависит от уровня изоляции в постгресе). Поэтому нужно после переименования таблиц отдельно скопировать и эти новые записи.
Можно поступить гораздо проще - сразу в одной транзакции переименовать ту же history в history_old и создать новую гипертаблицу history, куда заббикс и начнёт писать данные с этого момента. А потом можно не спеша переносить исторические данные из старой таблицы в новую. Чтобы не ругались триггеры, можно в рамках первой транзакции, сразу после создания новой гипертаблицы history, скопировать из history_old метрики за последние полчаса-час-сколько нужно. Хотя скорее всего и так ругаться не будет, потому что заббикс старается в своем кэше все нужные метрики держать.
Как ускорить миграцию Zabbix на TimescaleDB