Znachenie peremennoj counter mozno vstavit' v stroku vot tak:

CUSTOM_MESSAGE="Interface Ethernet0/" . counter . " changed state to DOWN";

A sam skript mozno sokratit' do

sub main()
{
  CUSTOM_MESSAGE = "Interface Ethernet0/" . int32(($2 - 386) / 128) . " changed state to DOWN";
  return 1;
}

ili, esli trebuetsja proverka chto $2 - eto 386 + chislo, kratnoe 128, i ne previshaet 3458, to:

sub main()
{
  if (($2 >= 3458) || (($2 - 386) % 128 != 0))
      return 0;
  CUSTOM_MESSAGE = "Interface Ethernet0/" . int32(($2 - 386) / 128) . " changed state to DOWN";
  return 1;
}

 sub main()
{
  if ($1==770)
      CUSTOM_MESSAGE="FastEthernet 0/3";
  return 1;
}

I ja podumaju kak sdelat', chtobi ne pisat' if dlja kazdogo interfejsa.

У нас возник следующий вопрос. Имеется оборудование Хуавей, которое в SNMP-трапах не шлёт ifDescr, а только ifIndex интерфейса. Сейчас пытаемся написать скрипт который бы преобразовывал индекс в дескрипшен, для внятного отображения. Придумали пока что-то типа этого:

 sub main()
{
if ($1==770)
$CUSTOM_MESSAGE="FastEthernet 0/3";
return $CUSTOM_MESSAGE;
}

И сделать так для всех существующих  у нас индексов. Но этот скрипт у нас не работает. Может подскажете как это организовать. И может это возможно как то более оптимально сделать?

а чем плох метод использования системного события? ведь по идее таким образом можно было бы минимизировать количество дополнительных событий? а можно поподробнее, почему предложенный мною метод не сработает? ведь обработка Правил идёт сверху вниз и по идее при обработке SYS_SERVIСE_DOWN, дополненного указанным скриптом, именно это Правило должно обрабатывать ВСЕ события, связанные с SYS_SERVIСE_DOWN + System.ServiceState(lanmanserver). а остальные события должны проваливаться по иерархии Правил дальше, пока не будут соответствующим образом обработаны.

В данном случае все действительно будет работать, поскольку есть дополнительный скрипт для проверки. Просто получится что в разных местах одно и то-же событие обозначает совершенно разные вещи - через год самому можно будет запутаться. А в общем случае получается такая ситуация: сервер генерирует SYS_xxx события в заранее определенных ситуациях, и если их-же использовать в DCI, то потом без использования скриптов невозможно разделить события, созданные сервером по внутренним правилам и по трешолдам. Например, если я определил HTTP сервис на ноде, то если он станет недоступен, сервер создаст событие SYS_SERVICE_DOWN. Если это событие используется и в DCI трешолде, то в event processing policy без скрипта различить их будет нельзя. Ну и текст сообщения для SYS_SERVICE_DOWN определен как

Network service "%1" is not responding

что при использовании в трешолде даст например

Network service "System.ServiceState(lanmanserver)" is not responding

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

т.е. мне нужно использовать при генерации события и его обработке только собственное событие и приведённый скрипт?

а чем плох метод использования системного события? ведь по идее таким образом можно было бы минимизировать количество дополнительных событий? а можно поподробнее, почему предложенный мною метод не сработает? ведь обработка Правил идёт сверху вниз и по идее при обработке SYS_SERVIСE_DOWN, дополненного указанным скриптом, именно это Правило должно обрабатывать ВСЕ события, связанные с SYS_SERVIСE_DOWN + System.ServiceState(lanmanserver). а остальные события должны проваливаться по иерархии Правил дальше, пока не будут соответствующим образом обработаны.

у меня предварительно настроено так:

мониторим System.ServiceState(lanmanserver), если получаем 1, то используем событие SYS_SERVIСE_DOWN, если возвращаемся к 0, то SYS_SERVIСE_UP. я просто при разработке этого DCI предположил что именно так и нужно использовать данные события...

мне просто не очень понятно...

sub main()
{
   return $1 == "System.ServiceState(lanmanserver)";
}

или просто

$1 == "System.ServiceState(lanmanserver)"

Я убрал "? 1 : 0", поскольку результатом операции сравнения и так будет 1 или 0.

И да, для прекращения обработки события надо использовать "Options: Stop processing if rule match".

Задача: нужно сделать Правило-ловушку, в которую должны попадаться только события, в которых фигурирует Parameter System.ServiceState(lanmanserver). Остальные События с ошибками от других сервисов должны игнорироваться и проходить на процессинг дальше...

Если я создам такое Правило в EPPE (Event Processing Policy Editor), это должно сработать?:

Source: Any
Event: SYS_SERVICE_DOWN (Major)
Severity: Major
Script:

sub main()
{
   return ($2 == System.ServiceState(lanmanserver)) ? 1 : 0;
}

Alarm: указан только параметр "%m"
Situation: нет
Action: 2 реакции

1. отправить почтой оповещение
2. перезапустить сервис "lanmanserver"
   Options: нет

Правда возникает вопрос: а как сделать так что бы не происходило двойного срабатывания правил, если есть 2 правила, 1 - Специальное (то, что я привёл выше) и 2 - общее, общего назначения для всех отслеживаемых служб?

Нужно использовать "Options: Stop processing if rule match"?

sub main()
{
   return ($2 == 4227794) ? 1 : 0;
}