Блог bitmanager

Миграция Zabbix на PostgreSQL

На этой неделе неожиданный сюрприз преподнес Zabbix. Вернее не он сам, а его web-интерфейс. Переносили его на PostgreSQL и заодно обновляли версию до 3.2. И вот он поставился – все хорошо, а web—интерфейс не стартует.

Вернее стартует, пытается подключиться к базе на localhost, не может и сильно из-за этого расстраивается. И мы вместе с ним. Потому что вся работа застопорилась. Все конфиги обнюхали, настройки поправили, права проверили. Ни в какую. Подайте мне базу на локальном хосте и все. Это при том, что у него в конфиге белым по черному написано куда и как подключаться. Потом полез я базу смотреть и вижу чудо: в базе таблица, в ней две записи, а их нет. Записи-невидимки. Да еще и в сессиях. Тут-то мы и смекнули, что база-то кривая. А так попробуй по ней понять, кривая она или нет, не будешь же все записи проверять при заливке дампа. Дропнули, перезалили, взлетело.

Теперь я понимаю, почему знак у Zabbix на красном фоне — это вся выпитая им у админов кровь.

В процессе переноса и обсуждения возникла еще одна идея для оптимизации. У нас часть триггеров в Zabbix самоблокирующаяся. То есть сбрасываются вручную через правку макропеременных. И вот то, что надо хранить эти макропеременные, а это обычно md5 от различных строковых данных, несколько удручало. Хотелось большей легкости шаблона, да и большей универсальности. И возникло следующее предложение: использовать TRIGGER.VALUE для самоблокировки триггера. То есть делаешь условие триггера таким: <условия_срабатывания> OR TRIGGER.VALUE = 1 и с этого момента при срабатывании по условию триггер остается активным, даже если условие срабатывания перестает выполняться. Сбросить можно только вручную. Учтите, что до версии 3.2 этой механикой пользоваться очень неудобно – надо менять условие триггера. Плюс выключаться он будет при следующем получении значения элементом данных, за которым он наблюдает.

Записки сисадмина