NetXMS Support Forum

починился копированием всех указанных файлов из каталога постгреса в каталог мониторинга.
сервер мониторинга завёлся.

правда чисто субъективно стал медленнее работать. но могу и ошибаться.
по результатам тестов отпишусь.

Установка проводилась на Win2008Std (x32).
База - PGSQL 8.3

И теперь сервер NXMS не заводится.

Application popup: nxdbmgr.exe - Unable To Locate Component : This application has failed to start because k5sprt32.dll was not found. Re-installing the application may fix this problem.

+ не поставился агент. пришлось ставить вручную.
+ запустить nxdbmgr невозможно- ругается на отсутствие либы MSVCR71, gssapi32.dll

not fixed yet.

i try right now to install 0.26 Agent BY HAND to my own PC, it stop existing Agnet but stops to install new version.
previous vesion files looks like locked by system.

is distribution fixed at latest veresion?

кое-как поставилось и тут же упало:

The application, C:\Program Files\NetXMS\bin\nxagentd.exe, generated an application error The error occurred on 02/05/2009 @ 13:33:37.827 The exception generated was c00000fd at address 10014F87 (libnetxms!XMLGetAttrBoolean)

подмечено что падение агента вызывает вот такой запрос:

ServiceCheck.HTTP(10.10.13.32,17000,/IQLib.XBook?text=%CF%F3%F2%E8%ED,testserver.mydom.ru,"^HTTP/1\.[01] 200.*<html.*Путин.*")

это запрос на получение веб-страницы у поисковой системы.
как параметр передано преобразованное слово "Путин", в получаемой странице с результатами поиска ищем тоже слово.

в конфиге клиента включён portcheck.

Проблема странная. Проявилась только сейчас и только на двух машинах.

Клиент не ставится (точнее не устанавливается сервис).
Ошибка в логе:

Reporting queued error: faulting application nxagentd.exe, version 0.0.0.0, faulting module libnetxms.dll, version 0.0.0.0, fault address 0x00014f87.

Пока не пойму в чём дело...

На всякий случай напоминаю =)

всё, понял, спасибо за помощь =)

и кстати: только что проверил. моя метода + новый скрипт = работают.

Виктор, спасибо за помощь =)

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

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

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

=)

=) только начинаю разбираться в скриптовании, а потому вопросы в основном будут глупыми...

Задача: нужно сделать Правило-ловушку, в которую должны попадаться только события, в которых фигурирует 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"?

сегодня наконец поставил, буду посмотреть как оно себя поведёт...

=) не вопрос.

шаблон - единоразово (только 1 раз) применяемые к ноде настройки DCI (оптимально- на стадии создания новой ноды)
политика - шаблон (набор шаблонов), работающий в режиме реального времени, когда в случае изменения вводных в шаблоне (шаблонах) эти изменения незамедлительно применяется (реплицируются на) ко всем подчинённым данной политике нодам.

маладэц... =)
а расшарить полученные знания..?

не поленись плиз- напиши. вдруг кому пригодится.

тогда такой вопрос...

а нельзя ли будет в будущей версии применить такой алгоритм: добавить в Шаблон 2 новые функции

1) одна ведёт себя аналогично удалённому редактированию конфига агента и СПРАШИВАЕТ такое же подтверждение, прежде чем применить новые шаблонные настройки (отказ, только сохранить, сохранить и применить)
2) вторая показывает окно и позволяет в этом окне выбрать ноды, к которым будет (или НЕ БУДЕТ, радиосвич типа "Применить ко всем кроме этих" или "Применить только к этим") применён шаблон (выбор, например, чекбосами).

это так, мысль на будущее.
кстати.. чем больше смотрю на Шаблоны, тем больше они мне по поведению напоминают Политики. всё таки шаблоны себя несколько иначе должны вести, а тут- вполне такие настоящие Policy.