NetXMS Support Forum

Иногда генерируются такие события и алармы:

676504 24.02.2016 02:03:51 SW41 0 SYS_IF_EXPECTED_DOWN Normal Interface "swp25" with expected state DOWN changed state to DOWN (IP Addr: UNSPEC/0, IfIndex: 26) 0
676813 24.02.2016 05:09:08 SW1 (1.250) 0 SYS_IF_EXPECTED_DOWN Normal Interface "1/8" with expected state DOWN changed state to DOWN (IP Addr: UNSPEC/0, IfIndex: 8) 0

673900 23.02.2016 05:32:58 SW1 (1.250) 0 SYS_IF_UP Normal Interface "1/22 (MONITORING SW)" changed state to UP (IP Addr: UNSPEC/0, IfIndex: 22) 0

По времени это может быть 05:00 утра или 02:00 ночи, на коммутаторах при этом ничего не происходит похожего.

Я понимаю когда, например, срабатывает такое:

[Normal] SW10 (167.1) Interface "1/25" with expected state DOWN changed state to DOWN (IfIndex: 25)
[Major] SW10 (167.1) Interface "1/25" unexpectedly changed state to UP (IfIndex: 25)

Тут всё правильно, и на самом коммутаторе из unexpectedly state UP порт переходит в expected state DOWN.

А вот ситуация выше похожа на какой то баг, возможно. Какую доп. информацию нужно предоставить?

UPD.

Заметил еще следующее:

677530 24.02.2016 12:11:47 SW41 0 SYS_IF_UP Normal Interface "swp06 (Solnechnaya 85)" changed state to UP (IP Addr: UNSPEC/0, IfIndex: 7) 0
677529 24.02.2016 12:10:43 SW41 0 SYS_IF_UNKNOWN Warning Interface "swp06 (Solnechnaya 85)" changed state to UNKNOWN (IP Addr: UNSPEC/0, IfIndex: 7) 0

То есть почему то вначале вообще SYS_IF_UNKNOWN создаётся....

676504 24.02.2016 02:03:51 SW41 0 SYS_IF_EXPECTED_DOWN Normal Interface "swp25" with expected state DOWN changed state to DOWN (IP Addr: UNSPEC/0, IfIndex: 26) 0
676503 24.02.2016 02:02:47 SW41 0 SYS_IF_UNKNOWN Warning Interface "swp25" changed state to UNKNOWN (IP Addr: UNSPEC/0, IfIndex: 26) 0

Тогда на баг не похоже, но как бороться с этим SYS_IF_UNKNOWN ?

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

https://www.netxms.org/forum/oe-oo/koe-eto/

Если кратко: в некоторых ситуациях не генерируется ивент SYS_NODE_DOWN(когда нет ответа на SNMP?) интерфейсы становятся UNKNOWN, а потом когда связь восстанавливается - они переходят в expected state и генерируется Normal ивент.

Вероятно нужно починить генерацию SYS_NODE_DOWN если snmp отвалился и не генерить при восстановлении SYS_IF_EXPECTED_DOWN/UP

Проблема вообще очень раздражает.

Существует и другая похожая проблема:
1) Связь реально пропадает, SYS_NODE_DOWN генерируется
2) для интефейсов ноды генерируется SYS_IF_UNKNOWN
3) Связь восстанавливается, для каждого интерфейса(речь о тех у которых expected state=down) генерируется SYS_IF_EXPECTED_DOWN.

Фактически выходит что в event processing policy нельзя отличить SYS_IF_EXPECTED_DOWN как восстановление SYS_IF_UNEXPECTED_UP от  SYS_IF_EXPECTED_DOWN который пришел просто после восстановления связи с коммутатором. Это приводит к флуду в почте поле восстановления связи с коммутатором.

Эту проблему можно было бы решить галкой типа "suppress event if key not found" - то есть если ключ IF_UNEXP_UP_%i_%1 при обработке SYS_IF_EXPECTED_DOWN не найден, то подавлять ивент. С помощью такой фичи можно было бы подавлять ивенты о нормализации чего либо, если до этого не было ивента о аларме.

Я вижу два возможных решения:

1. Не генерировать UP/EXPECTED DOWN события если интерфейс выходит из состояния UNKNOWN. Единственная возможная проблема которую я вижу - если интерфейс был например UP, пропала связь с SNMP агентом, интерфейс стал UNKNOWN. Потом связь восстановилась, но интерфейс уже DOWN к этому моменту. Тогда не будет события, которое на самом деле информативно.

2. Добавить параметр к событию - предыдущее состояние. Тогда можно будет отфильтровать переходы из UNKNOWN, но проблема из варианта 1 все равно останется.

Возможно надо сохранять еще и последнее состояние перед UNKNOWN, и на основе него уже принимать решение о генерации события.

Quote
Не генерировать UP/EXPECTED DOWN события если интерфейс выходит из состояния UNKNOWN. Единственная возможная проблема которую я вижу - если интерфейс был например UP, пропала связь с SNMP агентом, интерфейс стал UNKNOWN. Потом связь восстановилась, но интерфейс уже DOWN к этому моменту. Тогда не будет события, которое на самом деле информативно.

Если EXPECTED state был UP, то после выхода из UNKNOWN нужно сгенерить  UNEXPECTED DOWN(а это другой тип евента). Таким образом если  не слать EXPECTED DOWN/UP события если интерфейс выходит из состояния UNKNOWN все будет работать как требуется - потому что смена состояния будет приводить в генерации UNEXPECTED  UP/DOWN. Потери полезного события не будет.

QuoteЭту проблему можно было бы решить галкой типа "suppress event if key not found" - то есть если ключ IF_UNEXP_UP_%i_%1 при обработке SYS_IF_EXPECTED_DOWN не найден, то подавлять ивент. С помощью такой фичи можно было бы подавлять ивенты о нормализации чего либо, если до этого не было ивента о аларме.

А почему не возможен этот вариант? Мне кажется это было бы более гибко.

Quote from: 2c2i on March 20, 2016, 10:44:19 PM

Quote
Не генерировать UP/EXPECTED DOWN события если интерфейс выходит из состояния UNKNOWN. Единственная возможная проблема которую я вижу - если интерфейс был например UP, пропала связь с SNMP агентом, интерфейс стал UNKNOWN. Потом связь восстановилась, но интерфейс уже DOWN к этому моменту. Тогда не будет события, которое на самом деле информативно.

Если EXPECTED state был UP, то после выхода из UNKNOWN нужно сгенерить  UNEXPECTED DOWN(а это другой тип евента). Таким образом если  не слать EXPECTED DOWN/UP события если интерфейс выходит из состояния UNKNOWN все будет работать как требуется - потому что смена состояния будет приводить в генерации UNEXPECTED  UP/DOWN. Потери полезного события не будет.

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

Quote from: 2c2i on March 20, 2016, 10:44:19 PM

QuoteЭту проблему можно было бы решить галкой типа "suppress event if key not found" - то есть если ключ IF_UNEXP_UP_%i_%1 при обработке SYS_IF_EXPECTED_DOWN не найден, то подавлять ивент. С помощью такой фичи можно было бы подавлять ивенты о нормализации чего либо, если до этого не было ивента о аларме.

А почему не возможен этот вариант? Мне кажется это было бы более гибко.

А где галку ставить?

А так при помощи скриптов и custom attributes это можно и сейчас сделать.

Галка в Event Processing policy rule. В меню Action->Alarm. Если выбран режим Terminate alarm или Resolve alarm - указывать не только ключ, но и галочку для отмены срабатывания правила, если алармов с указанным ключем не было на момент срабатывания. Таким образом если аларма не было, можно будет подавить Terminate alarm или Resolve alarm

Отмена срабатывание этого-же правила, или не идти дальше по правилам? А то правило terminate alarm так и так ничего не сделает если алармов с заданным ключом нет.

>Отмена срабатывание этого-же правила, или не идти дальше по правилам?
Отмена срабатывания этого правила.

>А то правило terminate alarm так и так ничего не сделает если алармов с заданным ключом нет.
Правило terminate alarm сейчас выполняет Action независимо от наличия/отсутствия ключа аларма (в результате у нас генерируются тысячи бессмысленных писем "[Normal] Interface blabla with expected state DOWN changed state to DOWN" ) . Вот галка про которую я говорю, могла бы отменять выполнение всех экшнов данного правила если ключа аларма не найдено.

Т.е. в правиле несколько действий - terminate alarm плюс рассылка, и подавлять надо именно остальные действия.

>Т.е. в правиле несколько действий - terminate alarm плюс рассылка, и подавлять надо именно остальные действия.

Да, если при terminate alarm оказалось что нет аларма с таким ключем - нужна галочка решит выполненять ли server actions или просто закончить работу правила.

Скажите, нет ли в планах реализации вышеописанного поведения?
Быть может вы подскажете как его эмулировать с помощью  custom attributes, как вы упоминали ранее. Тк эта проблема нам мешает завершить переход на netxms полностью.

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

sub main() {
key="IF_UNEXP_UP_".$event->parameters[1]."_".d2x($event->id);
trace(1, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(1, "key" .key." Not found. disable event rule");
return false;
}
return true;
}

Quote from: 2c2i on June 24, 2016, 02:22:50 PM
получилось добиться вышеописанного таким скриптом фильтрации:

Code Select Expand

sub main() {
key="IF_UNEXP_UP_".$event->parameters[1]."_".d2x($event->id);
trace(1, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(1, "key" .key." Not found. disable event rule");
return false;
}
return true;
}

Это к какому правилу применять нужно ?

Для правила EPP "Terminate interface unexpectedly up alarms when interface goes down":

sub main() {
key="IF_UNEXP_UP_".$event->parameters[1];
trace(1, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(1, "key" .key." Not found. disable event rule");
return false;
}
trace(1, "key" .key." Found. process event rule");

return true;
}

Для Terminate interface down alarms when interface is up:

sub main() {
key="IF_DOWN_".$event->parameters[1];
trace(1, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(1, "key ".key." Not found. disable event rule");
return false;
}
trace(1, "key ".key." Found. process event rule");

return true;
}

Quote from: 2c2i on August 22, 2016, 11:33:15 AM
Для правила EPP "Terminate interface unexpectedly up alarms when interface goes down":

Code Select Expand

sub main() {
key="IF_UNEXP_UP_".$event->parameters[1];
trace(1, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(1, "key" .key." Not found. disable event rule");
return false;
}
trace(1, "key" .key." Found. process event rule");

return true;
}

Для Terminate interface down alarms when interface is up:

Code Select Expand

sub main() {
key="IF_DOWN_".$event->parameters[1];
trace(1, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(1, "key ".key." Not found. disable event rule");
return false;
}
trace(1, "key ".key." Found. process event rule");

return true;
}

Спасибо! Так полегче