NetXMS Support Forum

Очень странная проблема. Похоже что все-таки не проходят какие-то 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

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'?