При выключенном хосте висят триггеры

[alekseyeng]

Добрый день!
Имеется zabbix 3.2. Есть несколько машин которых необходимо мониторить.

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

Вопрос :
1. Как я понимаю, при выключении хоста, все что с ним связанно, должно пропасть, а не фиксировать последнии данные и висеть в сосяние проблемы к примеру.
2. Если это не так, то как лучше организовать?

[Dorlas]

Добрый день!
Имеется zabbix 3.2. Есть несколько машин которых необходимо мониторить.

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

Вопрос :
1. Как я понимаю, при выключении хоста, все что с ним связанно, должно пропасть, а не фиксировать последнии данные и висеть в сосяние проблемы к примеру.
2. Если это не так, то как лучше организовать?

Как вариант, отправлять команду на сервер, чтобы данный сервер переводился в режим обслуживания без сбора информации...

[kyern]

Машина выключается и включается всегда в одно и то же время?
Если да, то можно создать периоды обслуживания для нее.
Так же есть вариант использования зависимости триггеров, тогда вместо нескольких проблем вы будете видеть только одну

[alekseyeng]

Как вариант, отправлять команду на сервер, чтобы данный сервер переводился в режим обслуживания без сбора информации...

т.е. если не доступен то переводился в режим обслуживания, а если машина снова вклачется, но режим обслуживания сам включался ?
Как это можно реализовать ?

Объясню и добавлю, машины - это рабочие станции пользователей.

[Dorlas]

т.е. если не доступен то переводился в режим обслуживания, а если машина снова вклачется, но режим обслуживания сам включался ?
Как это можно реализовать ?

Объясню и добавлю, машины - это рабочие станции пользователей.

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

А для включения в режим обслуживания сделать скрипт, который сначала отправляет данные для zabbix-server'a, а потом выключался компьютер

[Dorlas]

т.е. если не доступен то переводился в режим обслуживания, а если машина снова вклачется, но режим обслуживания сам включался ?
Как это можно реализовать ?

Объясню и добавлю, машины - это рабочие станции пользователей.

Кстати, у вас пользователи работают с ХХ:ХХ до yy:yy? График работы постоянный?
Если да, то можно поставить режим обслуживания:
Например график работы с 9:00 до 18:00
Ежедневно В 18:00 каждый 1 день
Период установить равным количество часов между yy:yy и xx:xx
В нашем случае 15 часов
Тип обслуживания "Без сбора данных"

[pzabortsev]

2. Если это не так, то как лучше организовать?

Посмотрите в сторону зависимости триггеров

[alekseyeng]

Кстати, у вас пользователи работают с ХХ:ХХ до yy:yy? График работы постоянный?
Если да, то можно поставить режим обслуживания:
Например график работы с 9:00 до 18:00
Ежедневно В 18:00 каждый 1 день
Период установить равным количество часов между yy:yy и xx:xx
В нашем случае 15 часов
Тип обслуживания "Без сбора данных"

В том то и дело что это юзера ) они в 18.00 не все уходят как правило. Бывает и в 20.00 уходят.

[alekseyeng]

Посмотрите в сторону зависимости триггеров

Все таки думаете делать зависимость ? обычными настройками (где нибудь в общих и так далее) не получиться?

[yukra]

Все таки думаете делать зависимость ? обычными настройками (где нибудь в общих и так далее) не получиться?

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

Но как вариант: делаем например триггер c ipmp-ping'ом, важность "инфо", делаем все имеющиеся триггеры зависимыми от него, в дашборде выставляем "Минимальная важность триггеров" - "предупреждение"

[nc-pv]

Можно копнуть глубже

Есть один способ, но он довольно грубый...

Стандартными настройками сделать то, что Вы хотите не получится. Можно сделать зависимость триггеров, но опять же таки, понадобится не один костыль, а как минимум два - нужно будет скрыть и сам триггер о недоступности.

Однако... Web GUI Zabbix делает запрос к API, чтобы получить список активных триггеров для их дальнейшего отображения. Можно слегка изменить исходный код API, чтобы он не возвращал триггеры, у которых есть какие-то ошибки.

На Web сервере, где крутится Web приложение Zabbix, в файле

/include/classes/api/services/CTrigger.php

найдите такое место (в районе 410 строки) и добавьте указанную строку:

// min_severity
if (!is_null($options['min_severity'])) {
        $sqlParts['where'][] = 't.priority>='.zbx_dbstr($options['min_severity']);
}

// limit
if (!zbx_ctype_digit($options['limit']) || !$options['limit']) {
        $options['limit'] = null;
}

# Добавьте нижеследующую строку #
$sqlParts['where'][] = 'length(t.error) = 0';

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

Это очень грубое решение, так как оно повлияет на все запросы к API ото всех пользователей.

Можно сделать это решение более элегантным, написав код, добавляющий настройку "Не отображать триггеры с ошибками", чтобы эта опция могла быть включена/выключена пользователями по их желанию. Что-то вроде

if (!is_null($options['only_without_errors'])) {
     $sqlParts['where'][] = 'length(t.error) = 0';
}

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

[alekseyeng]

Есть один способ, но он довольно грубый...

Стандартными настройками сделать то, что Вы хотите не получится. Можно сделать зависимость триггеров, но опять же таки, понадобится не один костыль, а как минимум два - нужно будет скрыть и сам триггер о недоступности.

Однако... Web gui zabbix делает запрос к api, чтобы получить список активных триггеров для их дальнейшего отображения. Можно слегка изменить исходный код api, чтобы он не возвращал триггеры, у которых есть какие-то ошибки.

На web сервере, где крутится web приложение zabbix, в файле

/include/classes/api/services/ctrigger.php

найдите такое место (в районе 410 строки) и добавьте указанную строку:

// min_severity
if (!is_null($options['min_severity'])) {
        $sqlparts['where'][] = 't.priority>='.zbx_dbstr($options['min_severity']);
}

// limit
if (!zbx_ctype_digit($options['limit']) || !$options['limit']) {
        $options['limit'] = null;
}

# Добавьте нижеследующую строку #
$sqlparts['where'][] = 'length(t.error) = 0';

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

Это очень грубое решение, так как оно повлияет на все запросы к api ото всех пользователей.

Можно сделать это решение более элегантным, написав код, добавляющий настройку "Не отображать триггеры с ошибками", чтобы эта опция могла быть включена/выключена пользователями по их желанию. Что-то вроде

if (!is_null($options['only_without_errors'])) {
     $sqlparts['where'][] = 'length(t.error) = 0';
}

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

Спасибо ! решение конечно нестандарное, но попробовать стоит.

[alekseyeng]

Еще еще идеи у кого ?

[alekseyeng]

Есть один способ, но он довольно грубый...

Стандартными настройками сделать то, что Вы хотите не получится. Можно сделать зависимость триггеров, но опять же таки, понадобится не один костыль, а как минимум два - нужно будет скрыть и сам триггер о недоступности.

Однако... Web gui zabbix делает запрос к api, чтобы получить список активных триггеров для их дальнейшего отображения. Можно слегка изменить исходный код api, чтобы он не возвращал триггеры, у которых есть какие-то ошибки.

На web сервере, где крутится web приложение zabbix, в файле

/include/classes/api/services/ctrigger.php

найдите такое место (в районе 410 строки) и добавьте указанную строку:

// min_severity
if (!is_null($options['min_severity'])) {
        $sqlparts['where'][] = 't.priority>='.zbx_dbstr($options['min_severity']);
}

// limit
if (!zbx_ctype_digit($options['limit']) || !$options['limit']) {
        $options['limit'] = null;
}

# Добавьте нижеследующую строку #
$sqlparts['where'][] = 'length(t.error) = 0';

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

Это очень грубое решение, так как оно повлияет на все запросы к api ото всех пользователей.

Можно сделать это решение более элегантным, написав код, добавляющий настройку "Не отображать триггеры с ошибками", чтобы эта опция могла быть включена/выключена пользователями по их желанию. Что-то вроде

if (!is_null($options['only_without_errors'])) {
     $sqlparts['where'][] = 'length(t.error) = 0';
}

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

решение подошло . но все триггеры которые не получали данные пропали. Можно ли применить только на группу ? или на шаблон ?

[nc-pv]

решение подошло . но все триггеры которые не получали данные пропали. Можно ли применить только на группу ? или на шаблон ?

Не удивительно. Я даже это упомянул в изначальном посте:

Это очень грубое решение, так как оно повлияет на все запросы к api ото всех пользователей.

Мне пришла в голову другая идея. Добавьте в те триггеры, которые Вы хотите скрыть, следующее условие:

and {hostname:agent.ping.nodata(120)}=0

Например, у Вас есть триггер, который срабатывает, если в домашнем каталоге есть файл test_file. В этом случае весь триггер будет выглядеть так:

{hostname:vfs.file.exists[/home/user/test_file].last()}=1 and {hostname:agent.ping.nodata(120)}=0

Если связь с хостом пропадает на 120 секунд и более, то проблема перестанет отображаться. Этот способ намного лучше того, который я предложил изначально, так как он позволяет сделать настройку для каждого триггера индивидуально.

К потенциальным недостаткам этого метода стоит отнести то, что Вы получите повторное оповещение о проблеме как только хост станет доступен. Если же Вы так и хотите, то рассматривайте это как дополнительный плюс.

Я бы хотел добавить, что когда Zabbix теряет связь с хостами, то он не знает по какой причине это случилось - аварийная ли это ситуация (проблема с сетью, проблема с самими хостами) или они были целенаправленно выключены. Поэтому Zabbix занимает "безопасную" позицию и продолжает отображать проблемы, так как на момент последней проверки они всё ещё существовали.