Skip to content

Логика работы триггеров в Glaber

Значение триггеров

  1. Триггер может иметь три значения (value) [OK(0), PROBLEM(1), UNKNOWN(2)]

  2. Любое изменение состояния триггера логируется в события (EVENTS)

  3. Все актуальные проблемы хранятся в таблице PROBLEMS. Актуальные — это те, которые активны, триггер по ним в состоянии PROBLEM и по ним не было события восстановления). По событию восстановления проблемы вычищаются с некоторой небольшой задержкой, чтобы можно было визуально увидеть что проблема недавно была но уже решилась. Проблемы могут иметь значение [OK, PROBLEM, SUPPRESSED].

SUPPRESSED проблемы - «на паузе» - это те, которые были заморожены (подавлены) из-за блокирующих причин (maintenance, зависимости).

В значении SUPPRESSED проблема не изменяется (не может перейти в ОК), только когда пропадет блокирующая причина, проблема сменит значение на PROBLEM и потом сможет быть разрешена при очередном вычислении триггера или корреляций.

  1. Триггер переходит в UNKNOWN после своего создания, а также, если его нельзя вычислить:

  2. элемент данных перешел в UNSUPPORTED состояние

  3. функция вычисления вернула функция (например, деление на 0 или невозможность извлечь нужное количество данных из кеша).

События триггеров (да и вообще любые события — еще есть 3-4 типа объектов) в Glaber создаются всегда. Блокирующие причины влияют только на создание проблем и, косвенно, эскалаций.

Если у триггера срабатывают зависимости, то он перейдет в UNKNOWN, о чем также будет записано соответствующее событие.

Также, в отличие от Zabbix система действий и эскалаций, не привязывается к событиям, а связана с проблемами, события (EVENTS) представляют из себя лог системы триггеринга и эскалации.

Логика работы машины состояний значений триггеров

[!UNKNWON]→UNKNOWN Создается internal problem event

UNKNWON→[!UNKNWON] Создаем internal recovery event

PROBLEM->OK Создаем trigger recovery event

OK->PROBLEM Создаем trigger problem event

[*]→OK

  • Проверяем зависимости, если есть триггеры, от которых зависим в состоянии PROBLEM, если все хосты в maintebace without data collection — заканчиваем обработку

  • Если в триггере выставлен «OK event generation» NONE,заканчиваем обработку

  • Находим открытые проблемы, сгенерированные триггером, если в триггере выставлен тег по фильтру — то фильтруем только те проблемы, которые соответствуют фильтру. Закрываем, заканчиваем обработку

[*]→PROBLEM

  • Проверяем зависимости, если есть триггеры, от которых зависим в состоянии PROBLEM, если все хосты в maintebace without data collection — проблему не создаем, заканчиваем обработку

  • Проверяем, выставлен ли режим генерации множественных проблем, если так — создаем новую проблему, заканчиваем обработку

  • Проверяем, есть ли уже открытая проблема. Если открытых проблем более одной и режим генерации проблем - единичный, то закрываем все проблемы, кроме самой актуальной. Если есть хот одна проблема — заканчиваем обработку.

  • Создаем новую проблему

Примечание

Ситуации смены состояния [OK]→[OK] и [PROBLEM]→[PROBLEM] также полностью отрабатываются согласно логике выше, так как триггер может перейти в новое состояние во время работы того или иного механизма подавления или во время рестарта сервера. Такой механизм обеспечит восстановление корректного списка проблем при нештатных ситуациях работы и при работе механизмов подавления.