NetXMS Support Forum

Долго думал над красивым решением, без патчей на сервер не получится к сожалению. В следующей версии сделаю дополнительные функции, которые упростят конфигурацию в таких ситуациях. Пока-что можно сделать такой скрипт для event processing policy (для события по трешолду на параметры [N]SensorData):


sub main()
{
   loc = GetDCIValue($node, FindDCIByDescription($node, left($2, 1) . "SensorLocale"));
   return loc == "ambient";   
}


C таким скриптом правило будет срабатывать для событий от [N]SensorData если значение соответствующего [N]SensorLocale равно строке ambient.

P.S. Скрипт можно упростить до


GetDCIValue($node, FindDCIByDescription($node, left($2, 1) . "SensorLocale")) == "ambient"


Quote from: Anth0ny on January 28, 2009, 09:51:16 AM
а чем плох метод использования системного события? ведь по идее таким образом можно было бы минимизировать количество дополнительных событий? а можно поподробнее, почему предложенный мною метод не сработает? ведь обработка Правил идёт сверху вниз и по идее при обработке 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_SERVICE_DOWN - это системное событие, если мониторится что-то через DCI и thresholds - то должно быть какое-то свое событие (это уже обсуждалось где-то на форуме). И если это событие от срабатывания трешолда, то имя параметра DCI будет в первом параметре события, т.е. надо использовать $1 вместо $2. Ну и поскольку это строка, то она должна быть в кавычках. Таким образом, правильный скрипт:


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


или просто


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


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

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

Hello!

You can change global server configuration parameter PollCountForStatusChange. This parameter determines how many consecutive interface or network service polls should fail before declaring interface or service down. Because node declared down when all it's interfaces and services are down, this should help.

Best regards,
Victor

Just ignore it. It's a part of unimplemented feature.

Best regards,
Victor

Hi!

UNICODE build of libnxlp currently is not supported. This library used by server and logwatch subagent, both of them not using UNICODE as well.

Best regards,
Victor

V smisle hosti, najdennie posle togo, kak set' bila vistavlena v unmanaged? Esli da, to tak zadumano - manage/unmanage eto razovie operacii, esli potom k unmanaged ob'ektu dobavljaetsja novij podob'ekt, to emu unmanage ne delaetsja. Mozno sdelat' takuju opciju konechno. Edinstvennij vopros, chto delat' v sluchae konflikta - naprimer nashli router, kotorij v dvuh setkah, odna managed, drugaja net - chto s takim hostom delat'?

Na dannij moment suschestvuet tol'ko vozmoznos' nastroit' neskol'ko NetXMS serverov i peresilat' mezdu nimi sobitija. Obschej centralizovannoj konfiguracii poka net - k kazdomu serveru pridetsja podkljuchatsja otdel'no. Eto obsuzdalos' zdes' (v konce est' instrukcija po nastrojke event forwarding): https://www.netxms.org/forum/index.php/topic,256.0.html

Integracija s Google Maps - horoshaja misl', zapisal v TODO

Best regards,
Victor

Quote from: Anth0ny on January 13, 2009, 04:01:33 PM
это так, мысль на будущее.
кстати.. чем больше смотрю на Шаблоны, тем больше они мне по поведению напоминают Политики. всё таки шаблоны себя несколько иначе должны вести, а тут- вполне такие настоящие Policy.

Pohoze, nachat' nado s opredelenija chto takoe shablon i chto takoe politika

It's a bug Is it critical? If it's really critical, I can make a patch for 0.2.24, if not - please wait for next release.

Best regards,
Victor

Hello!

Below are some possible reasons:
1. Lost database connection.
2. Heavily corrupted database, where some tables for collected data (like idata_1734) does not exist.
3. Clock shift on server - if clock shifted back, server occasionally may try to write collected data with already existing timestamp.

You can try to run failed query in SQL query analyzer - it should give more diagnostic output.

Best regards,
Victor

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

Нельзя - в этом смысл шаблона. Можно вынести DCI Nr. 2 в отдельный шпблон и накладывать его только туда, где он нужен.

Quote from: possamai on January 12, 2009, 12:31:22 PM
Why?

Design flaw I agree that connections from agent to server can be very useful in many situations, especially for hosts with dynamic addresses or behind NAT. It is in my long to-do list, because it requires significant changes on server side, but eventually this feature will be available.


Best regards,
Victor

Удалять нельзяб это будет именно удаление ноды вообще. Надо выбрать шаблон, right click -> Unbind, и выбрать ноду которую хотим вывести.