NetXMS Support Forum

Request author's comment:

how i can create a standalone Service object?
for example for monitoring SSH daemon availability at host 10.0.0.1 without creating Server object and DCI "ServiceCheck.SSH".

path: Console root -> All Services -> Create -> Service...

Need more information about rights of filling for all "Create Network Service" fields.

Please.

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

UP.

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

UP.

Прошу если возможно добавить в Object Properties для Шаблонов новую вкладку-фильтр типа "Apply to...".

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

UP

Виктор, нужна Ваша помощь...

UP

Нужна подсказка... 

offtop: i'm already imported my collection of MIBs to NXMS mib database.
all works perfectly.

you need to do all as said Victor.

hmm.....

i think will be better to use WMI Subagent for you...

2 prx

а можешь привести по указаному вопросу пример скрипта?

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

А по порядку - это правильно, так проще =)

1. Записал в feature requests (https://www.netxms.org/forum/index.php/topic,414.0.html).

2. А усилять и расширять мониторинг кластеров не планируется? Кстати большое Вам спасибо за то, что уже реализовано!

А можно поподробнее о SYS_ALARM_TIMEOUT? я уже отписал в теме по монитрингу HTTP, что получаю чрезвычайно странный результат при использовании данного параметра а также параметра Timeout. Может быть я их просто неправильно использую? Подскажите... =)

Запустить/остановить процесс - имелось ввиду Event Processing (запуск процессинга эвента и остановка процессинга эвента).

3. Т.е. если я правильно понял, то ресурсы, которые входят в кластерную группу, можно мониторить ровно точно так же, как и обычные ресурсы, находящиеся на одиночной ноде? Но в таком случае на каком уровне нужно создавать DCI'и? На уровне кластера? Или на уровне каждой из нод? Прошу подсказать =).

4. Не работает, однозначно =).

По крайней мере с опросом дисков.

Если вопрос о последовательности создания кластера, то всё делалось по Вашему описанию, точь-в-точь. Если имеется ввиду создание DCI на уровне Кластера, то тут всё было сделано абсолютно точно также, как для обычной ноды.

Создал DCI типа Disk.FreePerc. Пробовал и для диска C: (есть на обеих нодах, понятное дело) и для диска S: (есть только на одной из нод). Обе ноды кластера- активные.

После создания (интервал опроса- 60 секунд) DCI ничего не получает. При попытке посмотреть данные через Data Collection -> Show Data получаю ошибку: Unable to retrievecollected data: Database failure.

И в таблице Collected Data в поле Value получаю единственную запись: ERROR LOADING DATA FROM SERVER.

Прошу помочь советом.

Прошу по возможности реализовать следующее в консоли:

1. Доделать отображение: нужен ещё один контейнер верхнего уровня, в котором находились бы абсолютно все ноды, не взирая на то, как они управляются (Агент или SNMP или вообще не управляются). А то сейчас приходится искать созданную ноду по разным спискам, если заранее не известно, что на ней стоит (Агент, SNMP или вообще ничего пока не стоит).

2. Позволить переносить уже существующие ноды на верхнем уровне из контейнера в контейнер. Т.е. если нода уже есть и она фигурирует в любом из списков (Agent, SNMP, Networks), то нужна возможность не пересоздавая перенести её в контейнер Кластера.

3. Прошу переделать Refresh мониторинга, чтобы при рефреше не сворачивались все контейнеры верхнего уровня..

с предыдущей проблемой разобрались: при внимательном осмотре нашего файла в коде был замечен regexp. очевидно NetXMS на может завернуть один regexp в другой (согласен- это очень-очень частный случай, не баг). и изза этого не отрабатывает как положено. пофиксили, убрав из кода страницы лишние элементы (указанные regexp'ы). всё отлично работает.

но в процессе дальнейшего углублённого тестирования столкнулись со следующей проблемой (правда, может это и не проблема а наш собственный косяк, но тогда нужен совет Мастера):

1. мы мониторим веб-страницу при помощи запроса
ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*<html.*red.*")

2. для обработки ответов сервера на DCI созданы Event'ы, WWW_NOK (Not OK, слово "red" обнаружено, нода переводится в статус Warning) и WWW_OK (слово "red" не обнаружено, нода переводится в статус Normal).

и у нас возникла проблема с процессингом:

условия:

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

- мы НЕ ХОТИМ реагировать на кратковременные ошибки-всплески (в общем случае, при следующем обращении к тестовой странице на ней уже всё хорошо)

- мы НЕ ХОТИМ, чтобы почта отправлялась сразу же после обнаружения на странице слова "red" и перевода ноды в статус Warning (Event = NOK)

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

в соответствии с документацией, мы решили задействовать поле Timeout в Processing Policy и решить данную задачу с его помошью.

для этого мы:

- создали ещё один Event, WWW_WARN (статус - Normal), и прописали его в Procrssing Policy, где для этого Event'а мы указали в Action акцию "mailto" (заранее созданная операция по отправке почтового извещения оператору).

- для Event'а WWW_NOK в поле Seconds ставим значение 300 а в поле Event мы выбираем WWW_WARN

я ведь правильно понимаю, что указав в поле Seconds "300" и указав в поле Event наше событие "WWW_WARN" мы должны получить тот эффект, что при наступлении события WWW_NOK наш DCI с запросом помечается как проблемный, почта отправлена не будет (для WWW_NOK не указана Action), а вот при истечении указанных 300 секунд должно быть обработано событие WWW_WARN и тогда почта будет отправлена?

соответственно, мы должны получить нужный эффект: если в течение указанных 300 секунд статус DCI вернётся к состоянию Normal при помощи события "WWW_OK" , то почта о сбое вообще не будет отправлена, так как согласно нашей логике срабатывание на ошибку будет выглядеть как СЛУЧАЙНОЕ срабатывание на кратковременную проблему (пиковую загрузку) и ошибка сама рассосалась в пределах 300 секунд. Соответственно, ручное вмешательство оператора не требуется. но в логах обнаружение проблемы будет отмечено.

мм... надеюсь понятно объясняю... да-с.

так вот. а что мы имеем на самом деле?

1. при задании в поле Seconds любого значения, не равного "0" срабатывание происходит мгновенно, без указанной отсрочки.

2. какой бы Event мы бы не указывали в поле Event, ВСЕГДА в Event Log'е появляется сообщение, что сработало событие именно SYS_ALARM_TIMEOUIT. и как я уже сказал- срабатывание происходит мгновенно, без учёта поля Seconds.

складывается впечатление, что не срабатывают поля:
Seconds- не даёт отсрочки по запуску ДОПОЛНИТЕЛЬНОГО Event'а
Event - не запускает указанное в нём событие на обработку

соответственно, мы не можем добиться нужного эффекта "ОТЛОЖЕННОГО" извещения (которое не будет выслано, если проблема сама рассосалась в указанные временные рамки в поле Seconds).

дальше-больше =)

пробовал привязать отправку сообщения к этому событию SYS_ALARM_TIMEOUIT, но опять же получаю мгновенную отправку сообщения, а не отложенную на 300 секунд.

кроме того, прошу обратить внимание на то, что для использования поля Timeout обязательно необходимо включить в Alarm'е поле "generate New Alarm", а тогда нода помечается как Outstanding. вопрос в том, как потом ВЫВЕСТИ её из этого состояния? ведь нам нужна только операция по запуску дополнительного события, а не пометка ноды, как сбойной...

А так же есть проблема с ALARM_TIMEOUT: этот Event помечает ноду как Outstanding, а вот автоматического способа вернуть ноду из Outstanding в состояние Normal для этого Event'а мы не нашли...

Прошу помочь разобраться, в чём именно моя ошибка и каким образом можно добиться эффекта "Отложенного" извещения, которое высылается только если проблема не рассосалась в течение указанных 300 секунд...

Тестирование кластерного монитора произведено...
Работает и работает хорошо, я бы даж сказал отлично! =)

Правда по мере тестирования возникли следующие вопросы:

1. Почему уже созданные ноды нельзя переносить под объект кластера? Ведь для этого нужно только Parent-объект сменить у ноды.. Так? =)
2. Если мы правильно поняли, то DCI, занимающийся мониторингом кластера, встроен в движок NetXMS (поскольку в списке субагентов нет ничего, даже отдалённо похожего на мониторинг кластеров).

Почему возник вопрос? Дело в том, что в случае, если какая-то из нод не доступна, а потом снова поднимается, то сначала генерится Warning, а потом нода автоматом переводится в состояние Normal. Это понятно. А вот с переездом ресурсов с ноды на ноду- вот тут странно. Если Event типа Resource_Moved имеет состояние Warning (это- по умолчанию), то нет никакой возможности вернуть статус ноды в Normal (TimeOut не помогает, поскольку он очевидно действительно additional, и не оверрайдит текущий статус ноды... И получается что нода постоянно висит в состоянии Outstanding (если использовать дефолтный Event "Resource_Moved"). И вернуть статус кластера в Normal можно только вручную.

Ну да не суть. Из положения мы вышли, отказавшись от генерации аларма при перемещении ресурсов кластера с ноды на ноду. Оставили только mailto в Actions. Т.е. событие перемещения регистрируется со статусом Warning, но при этом нода не помечается как сбойная (и не требуется прерывание текущей обработки).

И к началу темы: поскольку опрос (DCI) встроен в движок NetXMS, мы не можем процессить ответы Агента с кластера.  А значит не можем запустив процесс Alram'ом потом его остановить... Не знаю, удобно ли это.... Ну, в общем, это под вопросом.

3. По поводу глубины и точности мониторинга. Возник такой вопрос: мы сейчас можем мониторить только ресурсы типа Групп. А как быть с ресурсами, входящими в группы? Предположим, что их там не один и не два. И некоторые из них могут отваливаться... И получается, что сейчас невозможно отследить состояние упавших ресурсов. Только состояние Групп... Можно это как-то доработать? Чтобы мониторинг был более аккуратен? Пожааалуйста. =)

4. DCI на уровне объекта кластера создать можно, но вроде как они не работают. По крайней мере, точно не работает определение свободного места на диске C. Я понимаю, почему оно не работает, но тогда зачем оставлена такая возможность (добавлять DCI'и)?

По логике вещей, или нужно оставить возможность добавлять только КЛАСТЕРНЫЕ DCI, или совсем отключить возможность добавления DCI на уровне объекта кластера... Где-то так...

* * * * *

К кластеру отношения не имеет, но что бы не плодить темы: можно ли убрать из Win GUI сворачивание всех узлов при нажатии на F5 (Refresh)? Довольно неудобно... =) Пусть они не сворачиваются. Можно так сделать?

question about nxget: is it something like SNMP GET?
and i can get only one value, but can't get the list?

looks like an SNMP commands: "get" and "walk".

is it possible to do "walk" with nxget.exe for query lists of available values form nodes?

Your test query: WMI.Query(root\CIMV2,SELECT * FROM Win32_Processor,Name) - it works for me! =)

Please, need more information about syntax (root\CIMV2,SELECT * FROM Win32_Processor,Name): what is red-lighted parameter and how about other parameters?

I need to execute this queries, but i can't to do it (always have "500 internal error")

select DatabaseNodeMemory from Win32_PerfFormattedData_DNS_DNS
select DynamicUpdateQueued from Win32_PerfFormattedData_DNS_DNS
select TotalQueryReceived from Win32_PerfFormattedData_DNS_DNS
select TotalResponseSent from Win32_PerfFormattedData_DNS_DNS

Виктор, спасибо!
Буду экспериментировать.

Off: очень ждём новую версию и новые функции, особенно работу с логами, которой к сожалению не предполагается в новой версии =).