NetXMS Support Forum

It is possible that nxagentd.exe from previous version is in use by operating system. For example, if you have event log opened, it will use nxagentd.exe because it contains message texts. Try to close all mmc instances.

Best regards,
Victor

Da, moja oshibka. Unmanaged voobschem-to i dumalos' kak priznak togo, chto sostojanie hosta nas ne interesuet, poetomu vse sobitija dlja nego ne prohodjat cherez event policy. Nado budet sdelat' atribut "external node" - togda vse budet logichno - esli noda pomechena kak external, to server ee ne monitorit, no prinimaet sobitija i processit ih kak nado. Nu i ee toze mozno delat' unmanaged, chto vikljuchaet priem sobitij do teh por, poka ne vernit v sostojanie managed.

Hello!

Most likely node with given IP address already exist in NetXMS database. Check Entire Network tree - it should be under appropriate subnet, or try search by IP adress (press Ctrl+F in object browser, and type ip:ip_address in search string).

Best regards,
Victor

Очень странная проблема. Похоже что все-таки не проходят какие-то SQL запросы. А какой драйвер используется - mssql.ddr или odbc.ddr?

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

A kakaja baza? i chto pishet server v svoem loge? Skoree vsego tam budud "failed SQL query".

Yes, it should be fixed. However, I suggest to test on single server before mass distribution

Best regards,
Victor

Т.е. если выключить portcheck то не падает?

Windows 32 битный?

Вариант с циклом:


sub main()
{
        i = 1;
        while(i < 6)
        {
                if (GetDCIValue($node, FindDCIByDescription($node, i . "SensorLocale")) == "ambient" )
                        return GetDCIValue($node, FindDCIByDescription($node, i . "SensorData"));
                i++;
        }
        return 0;
}


Hello!

Sorry for late response, but it's a lot of writing, and I'm not good in doc writing I have updated NetXMS User Manual with log monitoring section (chapter 7). Updated manual already available at https://www.netxms.org/documentation/netxms_user_manual.pdf. In theory, it should give you all information about log monitoring Feel free to ask any questions.

Best regards,
Victor

Очень странно. А что скажет /etc/init.d/netxmsd если запустить его с командной строки (с разными командами: start, stop, status)?

Hello!

You can purge your SQLite database simply by deleting database file. Look at your netxmsd.conf, in case of SQLite parameter DBName will contain database file name. Delete this file and run nxdbmgr init - you will get fresh database.

Best regards,
Victor

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