NetXMS Support Forum

мда. несколько перекликается с моим запросом...
Виктор, дали бы нам возможность стоить сложные WMI-запросы, а...?

А то мы сейчас ограничены получением простых значений.
Вот было бы удобно выполнять целые wmi-скрипты... =)

О! Виктор появился и жизнь закипела =)
Ждём 0.2.22 (патченную с учётом обнаруженных проблем)

И по возможности ответы на вопросы.

see FAQ

I tested NXMS on W2008.

Quote
Windows NT/2000/2003/XP/2008_64bit, Linux, Solaris, AIX, HP-UX, FreeBSD

Win2008 32bit supported too....

https://www.netxms.org/forum/index.php/topic,204.0.html
Опираясь на эти данные, можно конечно попробовать создать actions, но...

Вот какой вопрос возник: предположим я хочу создать простой скрипт, перезапускающий сервис в случае сбоя (остановки или приостановки). Как мне этот сервис идентифицировать в скрипте перезапуска?

Предположим ситуацию:

Есть сервис w3svc, я мониторю его состояние. Для этого созданы Event'ы (Normal и Warning). настроен Event Processing Policy (давайте его уже для простоты называть EPP ). Создан Action типа "Execute action on remote agent" с привязкой к скрипту rezet_svc.cmd в каталоге c:\NetXMS\var\ на стороне машины с Агентом (это правильное место для скрипта?)

содержимое rezet_svc.cmd:

@echo off
net stop w3svc
net start w3svc

А вот теперь собственно вопрос: в данном конкретном примере у меня скрипт жёстко привязан к сервису w3svc. А можно ли сделать его (скрипт) универсальным? Ведь при мониторинге сервиса мы имеем %1 как название сервиса. Можно ли это как-то использовать в выполняемых скриптах?

Например: net stop %1 & net start %1

& - ждём выполнения предыдущей команды

Или же всё-таки можно в поле Action (при создании реакции типа "Execute command on management server") указать именно эту команду?

Странно немного....

По сути 90% выполняемых на Windows-серверах команд- именно CMD-команды (на Unix- соответственно shell-команды). Так может быть имеет смысл немного подтюнить данную возможность...? Например, изменить формат ввода и хранения команд?

Сейчас это поле "Action", в которой указывается только алиас команды, и собственно сконфигурированная в конфиге клиента команда.

Я если честно не совсем понимаю, зачем всё сделано именно так, ведь по логике вещей в 90% случаев используется именно перезапуск служб, и скрипт перезапуска вполне достаточно хранить (типа того что я привёл) на самом сервере. А с сервера перезапуск служб выполнять при помощи sc.exe (стандартный компонент любой Винды). Так же удалённо можно выполнять команды на стороне Агента при помощи psexec. На случай если права Сервера отличаются от прав Агента вполне ж можно приделать окно для ввода и последующего хранения логина с паролем. Насколько мне известно именно это - общепринятая практика...

Если так сделать, то больше не понадобится усложнять себе жизнь копированием на разные машины разных скриптов. Все скрипты будут лежать в едином репозитарии и именно из него сервер будет их брать для выполнения (причём они вполне могут храниться в текстовом виде в базе и извлекаться от туда по мере необходимости).

Кстати, было бы неплохо привязать Actions к Tools. Чтобы ими тоже можно было пользоваться интерактивно.

И не будет нужды в разделении команд на выполняемые на Сервере и на Агенте.
В общем я думаю что это позволит упростить и сделать систему Реагирования более стройной и понятной. Потому что сейчас если честно весьма непросто понять логику использования внешних программ и скриптов.

Документация по практическому применению возможностей субагентов NetXMS отсутствует как класс (простите, Виктор, но это так, я уже несколько раз перечитал официальное руководство и даже написал собственное, практическое: текущая документация не даёт почти никакого представления о ПРАКТИЧЕСКОМ применении всех возможностей NetXMS и при реализации мониторинга остаётся только догадываться, что и как из настроек и фич должно использоваться. Не хватает именно документации по параметрам субагентов).

Вопрос: насколько WMI-субагент и nxget.exe совместимы со стандартным WQL (WMI Query Language)?

Пытаюсь создавать запросы типа (это примеры):

SELECT ThreadCount FROM Win32_Process WHERE ThreadCount>10,Handle
SELECT ThreadCount FROM Win32_Process WHERE ThreadCount LIKE 10,Handle
SELECT HandleCount FROM Win32_Process WHERE name='dns.exe',Handle

И ничего не получается.
Всё время получаю ошибку 500.

Ещё вопрос:

nxget.exe 10.100.1.4 "WMI.Query(root\CIMV2,SELECT * from Win32_GroupInDomain,PartComponent)"

этот запрос возвращает только одно значение. подозреваю, что первое по списку из всех полученных, хотя не факт, не факт...

\\MYSERVER\root\cimv2:Win32_Group.Domain="MYDOMAIN",Name="RAS and IAS Servers"

И можно ли использовать запросы типа:

SELECT * FROM Win32_Service WHERE Started=0 AND StartMode="Auto"

(поиск всех сервисов которые должны стартовать автоматом при запуске системы но не запущены в настоящее время. суть в том, что хотелось бы иметь возможность получать через WMI не единичное значение а весь запрошенный массив и уже в этом массиве делать выборку. ну или же делать выборку непосредственно в запросе. как в данном примере- ищем ВСЕ остановившиеся или не запустившиеся сервисы, но их может быть > 1 а я пока могу получить только одно значение)

Прошу разъяснить ситуацию и подсказать, какого типа запросы можно использовать?
Должны ли работать указанные выше запросы?
Если должны то где я ошибся?
Может ли быть выборка не "SELECT *" а более конкретная?

Прощу помочь.

(
пища для размышлений:
http://www.ks-soft.net/hostmon.eng/wmi/index.htm
http://msdn.microsoft.com/en-us/library/aa394084(VS.85).aspx
http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx
)

не понимаю =(

версия старая, 0.2.21

раньше вроде как безотказно действовал метод такой проверки:

сделал DCI, указал в Threshold размер порога (такой чтобы точно получить аларм) и формулу сверки, получил аларм, терминировал (Terminate) аларм, подкрутил размер порога (попрежнему такой чтобы получить аларм при следующем цикле опроса), снова получил аларм, снова терминировал, выставил окончательный размер порога и всё, DCI начинает работать так как настроено.

а сейчас почему-то после терминирования перестал получаться аларм. чтобы я ни делал.
даже если условия порога однозначно TRUE, всё равно ничего не работает... =((
событие повторно не обрабатывается.

Наткнулся на странность:

есть маршрутизатор (cisco) с 4мя интерфейсами.
задача - мониторить загрузку канала (in\out) на двух интерфейсах (local & inet).

для проверки создал на интерфейсе Inet:

1) создал 2 Event'а: SYS_BANDW_OK (Normal) и SYS_BANDW_WARN (Warning), задействовал их в Event Processing Policy.

2) создал DCI для Inet-интерфейса:
ifInOctets (.1.3.6.1.2.1.2.2.1.10.3)
ifOutOctets (.1.3.6.1.2.1.2.2.1.16.3)

Data type = Unsigned Integer

При создании DCI на интерфейсе использованы значения:
"Inbound traffic", "Delta Value"
"Outbound traffic", "Delta Value"

выставил для обоих OID'ов параметр Threshold (для проверки) в 10000 (greater than 10000 -> SYS_BANDW_WARN). всё остальное (то, что создалось в процессе)- по дефолту.

В настройках DCI, во вкладе "Transformation" стоит "Average Delta per Second"

странность вот в чём: при первом срабатывании всё верно, определяется что текущее delta-значение больше порогового. и запускается событие SYS_BANDW_WARN.

НО если выбрать этот Alarm и нажать Terminate, то повторно превышение нагрузки не обнаруживается! Хотя опрос точно идёт (данные приходят) каждую минуту и каждый раз получаемое значение сильно больше порогового.

Не понимаю, в чём проблема... =(
Почему если в обычном случае с серверами после прерывания при повторном опросе Событие снова активируется (или я не прав?), то здесь всё как-то не так? Не происходит повторная активация События. Как будто где-то старый статус сидит, не до конца удалённый...

Или же Terminate нельзя таким образом использовать?

Сейчас наткнулся на то, что уже и на обычном сервере если сделать Аларму Terminate то повторно Аларм уже не активируется.... =(. раньше вроде само повторно активировалось... а теперь перестало.

Как в таком случае мне поступить?

Объект в мониторинг добавлен, получен Аларм, я его прервал вручную  (terminate) и теперь Объект не реагирует когда его Threshold должен сгенерировать новый Аларм...

Прошу помочь разобраться...

В случае с шаблонами всё достаточно очевидно: при применении шаблона на Объект в свойствах Data Collection Объекта видно, откуда им унаследованы текущие настройки DCI.

А вот с локальными DCI, созданными для интерфейса Объекта (именно только для интерфейса) всё не так хорошо: при просмотре списка DCI нельзя однозначно понять, для чего же служит созданный DCI, для всего Объекта или же только для конкретного отдельно взятого интерфейса.

Можно ли при создании DCI для интерфейса как-то их идентифицировать в списке всех DCI Объекта?
По аналогии с шаблонами.

Quote from: Victor Kirhenshtein on August 09, 2008, 11:43:27 AM
Problemu s Control Panel -> Network Maps ja ispravil, tak-ze kak i crash servera. Kak budet vozmoznost', vilozu obnovlenij build.

Виктор, очень, очень ждём... =)

Отлично, спасибо за информацию... =).
Правда я пока не могу воспользоваться всеми этими благами, я уже писал почему =(.
Валится сервер после обновления. Сегодня попробую (если будет время) поставить новую версию с нуля).

cпасибо, ждём =)

да-с. проблема терминологии...

ну всё, разобрались.

странное дело...

у меня 2 сервера, один- тестовый, физический. второй- продуктивный, виртуальный (сделано через Intel VT и MS Hyper-V).

на тестовом всё работает нормально, обновляется до 2.22 и крутится дальше. а продуктивный через некоторое время после после обновления валится, как подкошенный...

Quote
  Problem Event Name:   APPCRASH
  Application Name:   netxmsd.exe
  Application Version:   0.0.0.0
  Application Timestamp:   48931a95
  Fault Module Name:   nxcore.dll
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   48931a85
  Exception Code:   c0000005
  Exception Offset:   00024d0f
  OS Version:   6.0.6001.2.1.0.272.7
  Locale ID:   1049

разница между ними в том что тестовый - Win2003 а продуктивный- Win2008 (ну и несколько различаются конфиги: на продуктивном, так как он помощнее, увеличено число poller'ов).

собственно на этом разница кончается.

debug-лог на продуктивном сервере получил, но там никакого криминала нет. просто в какой-то момент прекращается запись в лог-файл (обрывается на обычной строке) и демон сервера вылетает с ошибкой. причём вылетает довольно быстро, минут через 3-5 как я уже писал. я лог весь просмотрел, но, повторяюсь, ничего странного там не увидел. Виктор, если лог всё же нужен- готов выслать мылом (не готов запостить сюда, сами понимаете почему).

вот концовка лога:

Quote
[04-Aug-2008 14:31:30] DEBUG: Name for node 77 was resolved to quantuma.test.net
[04-Aug-2008 14:31:30] DEBUG: Finished configuration poll for node quantuma.test.net (ID: 77)
[04-Aug-2008 14:31:30] DEBUG: Starting configuration poll for node f01.test.net (ID: 129)
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(f01.test.net): trying SNMP GET
[04-Aug-2008 14:31:30] DEBUG: SnmpCheckCommSettings: trying version 1 community 'public'
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(h01.test.net): checking for NetXMS agent - finished
[04-Aug-2008 14:31:30] DEBUG: Name for node 79 was resolved to b4.test.net
[04-Aug-2008 14:31:30] DEBUG: Finished configuration poll for node b4.test.net (ID: 79)
[04-Aug-2008 14:31:30] DEBUG: Starting configuration poll for node samanta.test.net (ID: 132)
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(s01.test.net): trying SNMP GET
[04-Aug-2008 14:31:30] DEBUG: SnmpCheckCommSettings: trying version 1 community 'public'
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(f01.test.net): checking for CheckPoint SNMP on port 260
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(g01.test.net): checking for NetXMS agent - finished
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(r01.test.net): checking for NetXMS agent - connected
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(f01.test.net): checking for NetXMS agent Flags={00000003} DynamicFlags={00000002}
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(f01.test.net): checking for NetXMS agent - connecting
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(s01.test.net): checking for CheckPoint SNMP on port 260
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(s01.test.net): checking for NetXMS agent Flags={00000003} DynamicFlags={00000002}
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(s01.test.net): checking for NetXMS agent - connecting
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(r01.test.net): checking for NetXMS agent - finished
[04-Aug-2008 14:31:30] DEBUG: ConfPoll(f01.test.net): checking for NetXMS agent - connected

сейчас проведу ещё один тест.
по результатам отпишу.

хмм...

я думаю что будет правильно при запросе отдавать IP, ассоциированный с ClusterGroup.
ведь именно по этому адресу кластер отвечает по сети.