Очистка очереди оповещений по некоторым

[igoreha311]

Здравствуйте!
Получилось так, что был отключен интерфейс у сервера, соответственно, хостов он не видел и все они ушли в down, в следствие этого начали срабатывать триггеры. Через некоторое время проблему с интерфейсом решили и начался шквал оповещений.
Так вот вопрос - где можно увидеть очередь этих уведомлений с целью её очистки. Может файлы временные где-то или в БД что-то удалить надо?

[ableev]

В чем конкретно у вас проблема? Начали дублироваться и постоянно отправляться уведомления одни и те же?
Или вы не хотите допустить этого в будущем?

Если первое: вам поможет табличка escalations в базе zabbix.
Если второе: указывайте "Maintenance status" при создании экшенов к триггерам. Если что-то с сетью случается - выставляйте с самого сервера локально maintenance status и уведомления не будут пачкой сыпать.

[igoreha311]

В чем конкретно у вас проблема? Начали дублироваться и постоянно отправляться уведомления одни и те же?
Или вы не хотите допустить этого в будущем?

Если первое: вам поможет табличка escalations в базе zabbix.
Если второе: указывайте "maintenance status" при создании экшенов к триггерам. Если что-то с сетью случается - выставляйте с самого сервера локально maintenance status и уведомления не будут пачкой сыпать.

Проблема в том, что за то время пока доступ в сеть у сервера отсутствовал, накопилось куча сработавших триггеров. После восстановления связи все эти триггеры со своими действиями начали отправлять оповещения.
Например, через час после проблемы 1 смс, через 5 часов другая, а сервер простоял 6 часов, так вот он обе смс-ки отправляет, а если хостов более 1000, то это не есть хорошо. Хотелось бы зайти и удалить очередь, чтобы избежать отправки 2000 смс.

[ableev]

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

[igoreha311]

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

Большое спасибо за информацию!

[igoreha311]

mysql> SELECT * FROM escalations;
+--------------+----------+-----------+-----------+-----------+------------+----------+--------+
| escalationid | actionid | triggerid | eventid | r_eventid | nextcheck | esc_step | status |
+--------------+----------+-----------+-----------+-----------+------------+----------+--------+
| 157 | 3 | 14397 | 1394 | NULL | 1341216361 | 1 | 2 |
| 158 | 3 | 14432 | 1436 | NULL | 1341216391 | 1 | 2 |
| 173 | 3 | 15486 | 1576 | NULL | 1341221411 | 1 | 2 |
...
| 62404995 | 144 | 1051468 | 151464732 | NULL | 1383952331 | 2 | 2 |
| 62405813 | 145 | 1051877 | 151465634 | NULL | 1383952489 | 2 | 2 |
| 62866178 | 145 | 1051925 | 152144472 | NULL | 1384131579 | 2 | 2 |
+--------------+----------+-----------+-----------+-----------+------------+----------+--------+
2650 rows in set (0.18 sec)

Если я правильно понимаю, то он мне ещё что-то слать собирается?

nextcheck - в каких единицах?
esc_step - шаг эскалации в действий?
status - какие варианты есть? (2 - это статус "планируется/в очереди"?)
Если я выполню очистку всей таблицы или её части, например, последних 600 записей, мне это как-то аукнется?

mysql> SELECT * FROM escalations where actionid=148;
...
| 62352534 | 148 | 1052942 | 151376439 | NULL | 1384190644 | 7 | 0 |
| 62355174 | 148 | 1052983 | 151377042 | NULL | 1384190826 | 7 | 0 |
+--------------+----------+-----------+-----------+-----------+------------+----------+--------+
1317 rows in set (56.42 sec)

удалил это действие с ИД=148,

mysql> SELECT * FROM escalations where actionid=148;
| 62349032 | 148 | 1052888 | 151375351 | NULL | 1384190639 | 7 | 0 |
| 62352534 | 148 | 1052942 | 151376439 | NULL | 1384190644 | 7 | 0 |
| 62355174 | 148 | 1052983 | 151377042 | NULL | 1384190826 | 7 | 0 |
+--------------+----------+-----------+-----------+-----------+------------+----------+--------+
1317 rows in set (37.81 sec)

Есть желание снести все эти данные...

[yukra]

...

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

#!/bin/bash
echo $* >> /tmp/log

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

[igoreha311]

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

#!/bin/bash
echo $* >> /tmp/log

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

Когда мне полетело много сообщений, я переименовал скрипт, выключил все действия и оповещения и заменил, а в конце ещё и маршрут изменил до смс-шлюза, но от этих махинаций мне легче не стало...

[yukra]

Когда мне полетело много сообщений, я переименовал скрипт, выключил все действия и оповещения и заменил, а в конце ещё и маршрут изменил до смс-шлюза, но от этих махинаций мне легче не стало...

Я так и не понял, пробовали ли Вы положить на место Вашего скрипта, такой, который не шлет смс, но при этом имеет нулевой код возврата?

[igoreha311]

Я так и не понял, пробовали ли Вы положить на место Вашего скрипта, такой, который не шлет смс, но при этом имеет нулевой код возврата?

Нет, подмену не делал.
Переименовал существующий скрипт.