Иногда генерируются такие события и алармы:
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
получилось добиться вышеописанного таким скриптом фильтрации:
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":
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 June 24, 2016, 02:22:50 PM
получилось добиться вышеописанного таким скриптом фильтрации:
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" и "Terminate interface down alarms when interface is up".
То есть я их не терминирую автоматически, а хотел бы отслеживать вручную.
Мне нужно SYS_IF_EXPECTED_DOWN создавать Alarm (Normal) только если до этого был SYS_IF_UNEXPECTED_UP, а если был SYS_NODE_DOWN или SYS_IF_UNKNOWN то НЕ создавать.
Именно как вы писали:
QuoteЭту проблему можно было бы решить галкой типа "suppress event if key not found" - то есть если ключ IF_UNEXP_UP_%i_%1 при обработке SYS_IF_EXPECTED_DOWN не найден, то подавлять ивент. С помощью такой фичи можно было бы подавлять ивенты о нормализации чего либо, если до этого не было ивента о аларме.
Вроде бы вот этот ваш скрипт должен как раз помочь, но с ним почему то возвращает false. (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;Где вы вызываете скрипт для отладки (trace) ?
>Где вы вызываете скрипт для отладки (trace) ?
trace - выводит сообщения в лог демона на сервере.
>То есть я их не терминирую автоматически, а хотел бы отслеживать вручную.
Я не совсем понял о чем речь. Мои скрипты подавляют экшны для инвентов о нормализации состояния порта в том случае если не было аларма на тему ненормального состояния. Это как раз происходит если статус интерфейсов стал UNKNOWN. То есть делаются две вещи:
- не пишется письмо что ситуация нормализовалась по SYS_IF_EXPECTED_DOWN в случае если ранее не было аларма SYS_IF_UNEXPECTED_UP( как раз если у вас был SYS_NODE_DOWN или SYS_IF_UNKNOWN)
- не пишется письмо что ситуация нормализовалась по SYS_IF_EXPECTED_UP в случае если ранее не было проблемы SYS_IF_UNEXPECTED_DOWN(аналогично, но для интерфейсов с другим expected state).
Вам не нужно терминировать аларм автоматически если стейт порта изменился с expected state на другой, а потом снова нормализовался?
>Мне нужно SYS_IF_EXPECTED_DOWN создавать Alarm (Normal) только если до этого был SYS_IF_UNEXPECTED_UP, а если был SYS_NODE_DOWN или SYS_IF_UNKNOWN то НЕ создавать.
То есть если пришел SYS_IF_UNEXPECTED_UP - вы создаете аларм, а потом если пришел SYS_IF_EXPECTED_DOWN(то есть нормализация) - вы хотите не удалять аларм, а создать еще один? Если так, то вы в принципе можете применить мои фильтры, немного их поменяв.
Quote from: 2c2i on August 30, 2016, 07:16:45 PM
>Мне нужно SYS_IF_EXPECTED_DOWN создавать Alarm (Normal) только если до этого был SYS_IF_UNEXPECTED_UP, а если был SYS_NODE_DOWN или SYS_IF_UNKNOWN то НЕ создавать.
То есть если пришел SYS_IF_UNEXPECTED_UP - вы создаете аларм, а потом если пришел SYS_IF_EXPECTED_DOWN(то есть нормализация) - вы хотите не удалять аларм, а создать еще один? Если так, то вы в принципе можете применить мои фильтры, немного их поменяв.
Да, создавать еще один (у него всё равно severity Normal) или хотя бы резолвить его.
>trace - выводит сообщения в лог демона на сервере.
У меня кстати пусто в netxmsd.log по трейсам, trace 1 — это же уровень дебага\лога, может больше надо?)
>Я не совсем понял о чем речь. Мои скрипты подавляют экшны для инвентов о нормализации состояния порта в том случае если не было аларма на тему ненормального состояния. Это как раз происходит если статус интерфейсов стал UNKNOWN. То есть делаются две вещи:
- не пишется письмо что ситуация нормализовалась по SYS_IF_EXPECTED_DOWN в случае если ранее не было аларма SYS_IF_UNEXPECTED_UP( как раз если у вас был SYS_NODE_DOWN или SYS_IF_UNKNOWN)
- не пишется письмо что ситуация нормализовалась по SYS_IF_EXPECTED_UP в случае если ранее не было проблемы SYS_IF_UNEXPECTED_DOWN(аналогично, но для интерфейсов с другим expected state).
У меня нет actions для этих правил, мне достаточно Алармов для них. Ну грубо говоря сработал внезапно где то SYS_IF_UNEXPECTED_UP (монтёр порт включил у которого expected state down или несанкционированное подключение) приходит аларм SYS_IF_UNEXPECTED_UP, потом порт погасили - приходит аларм (Normal) SYS_IF_EXPECTED_DOWN. Вручную уже разбираешь их, удаляешь или резолвишь, например. А в остальном всё тоже самое, только без Action.
SYS_IF_EXPECTED_UP и SYS_IF_UNEXPECTED_DOWN я у себя не нахожу :) Это системные или вы сами создавали ивенты?
Поправил ваш скрипт с помощью Виктора, для того чтобы полностью получать Unique ID.
nodeid = "0x" . right(d2x($node->id), 8, "0");
key = "IF_UNEXP_UP_".nodeid."_".$event->parameters[1];
trace(0, "Checking key ".key);
if (FindAlarmByKey(key) == null) {
trace(0, "key " .key." Not found. disable event rule");
return false;
}
trace(0, "key " .key." Found. process event rule");
return true;
//IF_UNEXP_UP_0x00000981_9374
Спасибо!