Как проверять состояние нод zabbix?

Может быть функция nodata ?

То-ли в джире у них, то-ли в форуме был подобный вопрос... Не могу найти, в общем там рекомендовали использовать nodata

я пока не пойму куда её прикрутить. По идее триггер с nodata будет проверяться на первой же по пути ноде, а центральная будет только собранные данные отображать. Просто потому, что шаблон - локальная сущность ноды.

Пойду исходники читать.

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

1) Пишем скрипт который ходит в БД удаленных нод, и смотрит последний эвентИд или хисториИд или тожесамоеТайм (колво айтемов = колву нод). 2) Повторяем пункт 1, только ходим в БД основной ноды, а запись выбираем для удаленной ноды (колво айтемов = колву нод) . 3) Делаем триггер на «айтем из п.2 не изменялся дольше Х минут и при этом не совпадает с аналогичным айтемом из п.1» ... х) Прибыль!

Задачу решил.

Шаблон и скрипт пока выложил на pastebin, дальше буду думать что с ними делать. Код местами ужасен - я не программист. К тому же на данном этапе я добивался только успешной работы скрипта. «не стреляйте в пианиста, он играет как умеет»

Надеюсь, кому-нибудь пригодится

• шаблон
• скрипт

Что-то в этом роде и получилось.

Но в удалённые БД никто не ходит - скрипт ставится и на master node, и на slave node, выбирает информацию из БД и шлёт непосредственно на master node

таблицы бывают разные. Они делятся на 2 группы - ZBX_HISTORY и ZBX_HISTORY_SYNC. Первые zabbix синхронизирует. Вторые - временные; как только строка отправлена на master node, zabbix удаляет её из локальной БД. Соответственно, для первой группы нужно сравнивать самые новые строки, для второй - смотреть на самые старые строки в БД slave node.

Ну а триггеры и графики создаются из прототипов с помощью low level discovery

И ещё в тему

1. За синхронизацию истории отвечают:
   • со стороны дочерней ноды - nodewatcher, см. src/zabbix_server/nodewatcher/nodewatcher.c, стр. 164, void main_nodewatcher_loop()
   • со стороны master node - trapper, см. ./src/zabbix_server/trapper/trapper.c, стр. 203, static int process_trap(zbx_sock_t *sock, char *s, int max_len)
2. nodewatcher в цикле
   • синхронизирует конфиги host'ов ( но не чаще чем раз в 2 минуты )
   • шлёт историю, но не более 10000 строк из каждой таблицы за один цикл ( это важно. Если скорость добавления данных в таблицу выше, то эти данные всегда будут отставать )
   • если цикл занял менее 10 секунд, сэкономленное время спит. И при этом обновляет статистику для selfmon'а
3. таблицы, которые синхронизирует nodewatcher (см. src/libs/zbxdbhigh/dbschema.c, стр. 23, const ZBX_TABLE tables[]), делятся на 2 группы:
   • отмеченные флагом ZBX_HISTORY. При их синхронизации у master node запрашивается последнее событие, которое уже прислали для синхронизируемой ноды. Это таблицы: alerts history_log history_text events acknowledges auditlog auditlog_details service_alarms
   • Таблицы, отмеченные флагом ZBX_HISTORY_SYNC. При их синхронизации дочерняя нода шлёт ВСЕ строки из таблицы, начиная с самых старых, а после успешной отправки - удаляет из БД дочерней ноды ( и это тоже крайне важно. Отсюда получаем способ мониторинга - запрашиваем из БД самую старую строку и проверяем её timestamp. Думаю, хорошей идеей будет подключить КЛИЕНТОВ, установленных непосредственно на дочерние ноды, к master node. И через client script запрашивать данные о синхронизации ). Это таблицы

     history_sync
     history_uint_sync
     history_str_sync

4. у меня на дочерней ноде таблицы c флагом ZBX_HISTORY успешно и вовремя отправлялись на master node ( т.е. их чистить было не обязательно), а вот ZBX_HISTORY_SYNC сильно отставали