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

Спасибо!

>Мне нужно 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 я у себя не нахожу Это системные или вы сами создавали ивенты?

>То есть я их не терминирую автоматически, а хотел бы отслеживать вручную.
Я не совсем понял о чем речь. Мои скрипты подавляют экшны для инвентов о нормализации состояния порта в том случае если не было аларма на тему ненормального состояния. Это как раз происходит если статус интерфейсов стал 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(то есть нормализация) - вы хотите не удалять аларм, а создать еще один? Если так, то вы в принципе можете применить мои фильтры, немного их поменяв.

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

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 то НЕ создавать.

Именно как вы писали:

Эту проблему можно было бы решить галкой типа "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) ?

Для правила 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;
}

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

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;
}

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

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;
}

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

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;
}

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

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

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

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

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

@2c2i said in ошибочные срабатывания SYS_IF_UP и SYS_IF_EXPECTED_DOWN:

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

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

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

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

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

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

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 не найден, то подавлять ивент. С помощью такой фичи можно было бы подавлять ивенты о нормализации чего либо, если до этого не было ивента о аларме.