История состояний триггеров

[AndreyHammer]

Возможно ли как-нибудь выдернуть историю состояний триггеров. Т.е. видеть не последние изменение триггера как сейчас,а за все время жизни триггера? Нужно, например, чтобы посмотреть как вел себя порт в течении определенного периода, когда лежал, когда поднялся. Если данного функционала нет, планируется ли его сделать? А может кто и сам допиливал такое?

[Andrey_79]

А закладка события чем не устраивает?

[AndreyHammer]

А как там задать период просмотра да еще и по всем узлам?

[Andrey_79]

А как там задать период просмотра да еще и по всем узлам?

В фильтре можно выбрать с какого периода, выбрать события. Группу выбираете - Все и узлы - Все. Просматриваете все события за указанное время.

[hulk45]

Мне кажется вам лучше ваше пожелание релизовать через скул запросы.
Интрфейс это конечно круто но замучаетесь.

[AndreyHammer]

Мне собственно и надо выдернуть через sql, но не могу найти в БД данные об истории срабатывания триггеров. Пришлось навесить тригер на апдейт таблицы triggers в котором делаются селекты и запись в собственную таблицу, а отсюда получаются задржки при выполнении запросов апдейта таблицы triggers(о проблеме я писал в др. топике). Нужно это для вывода аварий в собственное приложения которое мониторит деж. смена. Скрины проги в приложении.

[hulk45]

А ну тут всё просто, так бы сразу и сказали что через скул хотите выдернуть историю срабатывания

для этого нам понадобится всего 2 таблички (минимум) events, triggers

Сделаю подсказку в табличке events есть поле objectid. Как думаете, какому полю оно должно равнятся из таблички triggers? Ладно не буду томить

select * from events e, triggers t
where e.objectid=t.triggerid

Далее попробуйте сделать так чтобы вывод который вам даёт вкладка events совпадал с выводом который вам даёт скул запрос.
Давайте если не справитесь, то я подскажу.
Ведь это интересно копаться с БД.

Ну и дальше начинайте раскручивать.

Также если чётко сформулируете запрос, (какие поля), за какое время нужна история. Напишу вам запросик.
По скринам увидел, что есть у меня подобный запрос с использованием аналитических функций. Тоже как раз для отчётности, за сутки триггера отправляет по почте (автоматически). У меня например такие поля:

HOST (хост) DESCRIPTION_(описание триггера) prev_time (время срабатывания триггера) CUR_TIME (время когда триггер вернулся в нормальное состояние) delta_time (сколько висел) severity (приоритет) VALUE_ (значение триггера)

Напоследок дам запрос простенький, разберётесь думаю. Тут полностью показана связь

6. Выборка айтемов с привзанными к ним триггерами на конкретных серверах:

select distinct h1.host,t1.description, t1.triggerid, i1.description, i1.delay,
decode(i1.status,'0','ENABLE','1','DISABLE','3','N OT SUPPORTED') STATUS_DATCH,
decode(t1.status,'0', 'ENABLE', '1', 'DISABLE' ) TRIGGER_STATUS,
decode(t1.value,'0','FALSE', '1','TRUE','2', 'UNKNOWN') TRIGGER_VALUE,
decode(t1.priority,'0', 'NOT CLASSIFICATE','1','INFORMATION','2', 'WARNING','3','AVERAGE', '4','HIGH', '5','DISASTER') Severity
from items i1, hosts h1, hosts_templates ht,functions f1, triggers t1
where i1.templateid=0
and h1.hostid=i1.hostid
and h1.hostid=ht.hostid
and f1.itemid=i1.itemid
and f1.triggerid=t1.triggerid
order by i1.description

[gospodin.horoshiy]

мммм... а как из базы вытащить когда триггер вернулся в исходное состояние?

[hulk45]

мммм... а как из базы вытащить когда триггер вернулся в исходное состояние?

Мне кажется что тут всё просто. Вам некогда думать?

Вам нужно такое:
{триггер} {время когда он вернулся в нормальное состояние, после последнего перехода из true?}

[gospodin.horoshiy]

я пробовал использовать сначала triggers.lastvalue - но у меня не работает.... объясню почему:

мне нужно сделать отчет о триггерах за день,
вывод хочу такой:
типа

|описание триггера | время начала | время окончания
host has gone offline 12:01 12:50


проблема в том, что если допустим за день один и тот же триггер срабатывал многократно, то вышеуказанная запись будет верна только один раз, и получится вот так:

|описание триггера | время начала | время окончания
host has gone offline 12:01 12:50
host has gone offline 10:01 12:50
host has gone offline 08:01 12:50


Это потому что время окончания берется из колонки triggers.lastvalue, а оно для триггера только последнее хранится....


Вот запрос который начеркал пока что:

SELECT DISTINCT
g.name AS GROUPNAME,
h.host AS HOSTNAME,
t.description,
t.priority AS Severity,
FROM_UNIXTIME(e.clock) AS START_TIME,
FROM_UNIXTIME(t.lastchange) AS END_TIME

FROM
events e,
triggers t,
items i,
functions f,
hosts h,
groups g,
hosts_groups hg

WHERE
g.groupid=hg.groupid
and hg.hostid=h.hostid
and e.objectid=t.triggerid
and h.hostid=i.hostid
and i.itemid=f.itemid
and t.triggerid=f.triggerid

and e.value=1
and e.`clock`>=UNIX_TIMESTAMP(NOW())-86400

ORDER BY GROUPNAME,HOSTNAME,START_TIME;

еще была мысль подставлять в END_TIME e.clock, который будет при e.value=0, ну то есть когда триггер "угомонился", тогда встает вопрос как строки попарно объединить, но вообще кажется не лучшим решением даже если реализовать, так как время от времени еще и e.value=2 проскакивает, который UNKNOWN соответствует

[novoselov.ai]

Alexei! Неплохо бы в картах сделать движок 4-го измерения, то есть, чтобы смотреть на состояние триггеров на карте в разное время.

[hulk45]

я пробовал использовать сначала triggers.lastvalue - но у меня не работает.... объясню почему:
................................

понял что хотите. Тут надо аналитические функции применять.
Писал такой запрос уже.
Постараюсь найти сегодня завтра.

[gospodin.horoshiy]

Буду оч благодарен!

[hulk45]

Буду оч благодарен!

вот запросец.
Скорее всего вот в таком виде он не сработает, т.к. там немного надо с синонимами разобраться в первом запросе пред юнионом.
Т.к. в нём использовались не только таблицы заббикса и наши собственные.

Ну смысл таков:
1 запрос выводит триггера время начала срабатования и время окончания (даже если он несколько раз сработал, то выдаст нормальные строчки)
юнион
2 запрос выводит текущие триггера .....

Короче поиграйтесь со внутренними запросами , может что то своё умное натворите

[gospodin.horoshiy]

Ух, спасибо, сейчас буду осознавать написанное