NetXMS Support Forum

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
)

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

есть маршрутизатор (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 Объекта?
По аналогии с шаблонами.

Если в контейнере Templates создать подконтейнер My templates (как Template group) и перенести в этот подконтейнер шаблоны @SYSTEM.SNMP и @SYSTEM.AGENT, то все новые добавляемые ноды не подпадают под действие этих шаблонов АВТОМАТИЧЕСКИ.

Это так, информация к размышлению.
Не уверен, что предполагались такие телодвижения.

Очевидно это побочный эффект.

ждёмс, оченно ждёмс...

Виктор, какие известия с фронта?

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

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

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

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

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

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

Приветствую!

Возник следующий вопрос: предположим, что нужно мониторить состояние не одного, отдельно взятого сервиса или показателя производительности, а их совокупность. И состояние системы тоже определяется совокупностью состояний сервисов и показателей производительности.

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

Какой из текущих инструментов, входящих в NetXMS позволяет это сделать?

Какие самые общие рекомендации при реализации такого рода комплексного опроса?

Пример 1: определяем состояние и здоровье MS SQL сервера.

\SQLServer:Buffer Manager\Buffer cache hit ratio
(процент запросов на получение страницы, которые
выполняются без обращения к жесткому диску).

\SQLServer:Buffer Manager\Page reads/sec
(среднее число страниц в секунду, которое SQL-сервер
читает с дисковой системы).

\SQLServer:SQL Statistics\Batch Requests/sec
(среднее число пакетных запросов в секунду).

\SQLServer:SQL Statistics\SQL Re-Compilations/sec
(среднее число рекомпиляций в секунду).

\Process(sqlservr)\% Processor Time
(утилизация процессоров, создаваемая процессом SQL-сервер).

\Process(sqlagent)\% Processor Time
(утилизация процессоров, создаваемая процессом SQL-агент).

\SQLServer:Locks(_Total)\Average Wait Time (ms)
(среднее время ожидания выполнения запросов блокировки).

\SQLServer:Locks(_Total)\Lock Wait Time (ms)
(общее время ожидания выполнения запросов блокировки).

Пример 2: определяем состояние и здоровье MS DNS сервера.

\DNS\Database Node Memory;
(Память узлов в базе данных)

\DNS\Dynamic Update Queued;
(Поставлено в очередь динамических обновлений)

\DNS\Total Query Received/sec;
(Общее число полученных запросов/сек)

\DNS\Total Response Sent/sec;
(Отправлено всего ответов/сек)

\Process(dns)\% Processor Time;
(Процесс(dns)\% загруженности процессора)

\DNS\Recursive Query Failure/sec;
(Рекурсивных ошибок запросов/сек)

\DNS\Recursive TimeOut/sec;
(Рекурсивных таймаутов отправления/сек)

Всё прекрасно. Пашет как часы.
Но есть одна заковыка: DELL отдаёт температуру *10 (т.е. выдаёт не 25 градусов, а 250).

Можно ли какнибудь встроенными средствами DCI приводить данную цифру к нормальному виду? Т.е. делить на 10 перед дальнейшей обработкой? Плюс портятся температурные графики: разница на графике между 250 и 240 не так очевидна, как между 25 и 24.

Возможно ли как-то реализовать то, что я прошу? Встроенными средствами?

Приветствую!

Возникло некоторое непонимание с "ServiceCheck.HTTP".
Действовал согласно 2 части инструкции.

Привожу свою русскую интерпретацию (это не перевод):

QuoteМониторинг web-сервера возможен без добавления его в базу NetXMS как ноды (возможно, предполагается мониторить ресурс: на котором нет клиента NetXMS, который находится вне вашей сети или который находится не в вашем подчинении).

1) Для уже существующего в базе объекта-ноды (это может быть например сам сервер NetXMS) необходимо создать DCI (источник - агент NetXMS):

DCI: ServiceCheck.HTTP(server_ip_address,port,uri,host_header,response)

Замечание: При использовании метода "ServiceCheck.HTTP" невозможно использование URL, обязательно должен использоваться URI (в том числе для запроса к корню сайта), т.е.:

www.google.com - не правильно
www.google.com:/ - правильно

Далее в примерах вместо DNS-имени используется ip-адрес, но суть ограничения от этого не меняется.

Пример использования 1 (запрос к корню web-сервера):
ServiceCheck.HTTP(209.85.135.147,80,/,www.google.com,"^HTTP/1\.[01] 200.*")

Пример использования 2 (запрос к файлу test.html в корне сервера, файл должен существовать!):
ServiceCheck.HTTP(209.85.135.147,80,/test.html,www.google.com,"^HTTP/1\.[01] 200.*")

Пример использования 3 (запрос к файлу test.html в корне сервера, файл должен существовать, ищем на полученной странице слово "maps"):
ServiceCheck.HTTP(209.85.135.147,80,/test.html,www.google.com,"^HTTP/1\.[01] 200.*maps*")

Данный запрос может вернуть несколько значений:

0 - удача (соединение с сервером установлено и получен ожидаемый ответ)
1 - использованы неверные аргументы (в основном если неправильно написан RegExp)
2 - невозможно соединиться с сервером
3 - получен неправильный ответ сервера

Для процессинга ответов DCI, отличных от "0", можно создать threshold'ы.

Для сведения: для использования данного вида опросов на сервере NetXMS (если опрос идёт именно с него) требуется наличие субагента "portchecker". В случае с платформой Windows данный субагент уже присутствует и загружен по умолчанию. В случае с платформой UNIX вам нужно убедиться, что в конфиге агента NetXMS присутствует что-то вроде этого:

SubAgent = /usr/local/lib/libnsm_portCheck.so

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

Тут всё просто: мой web-сервер в процессе работы генерирует статическую страничку со списком пунктов, на которой html-тегами типа <red> и <green> (для пущей наглядности проверяющему) помечаются проблемы в работе сайта, существующие на момент генерации этого статического html-файла. И мне была поставлена задача в автоматическом режиме обнаруживать на этой страничке слово <red> средствами мониторинга NetXMS. Вроде судя по описанию, задачка проста.

Однако не тут-то было. Как я не изгалялся, получить адекватный результат мне так и не удалось. DCI всегда возвращает "0". Всегда, как бы не менялось содержимое проверяемой странички!

Мой DCI:

ServiceCheck.HTTP(10.200.1.100,80,/worktest.html,www.intwww.local,"^HTTP/1\.[01] 200.*red*")

Есть на странице слово "red" - получаю "0".
Нет на странице "red" - тоже получаю "0".

Складывается впечатление, что DCI возвращает не указанные ранее 4 значения, а просто отчёт о состоянии DCI (0 - выполнено успешно). Я ведь правильно понял, что в случае, если DCI не находит искомое слово на странице, я должен получить значение "3" (получен неправильный ответ сервера)?

Или как DCI должна отчитываться, что ответ от сервера отличается от заданного в RegExp'е запроса?

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

1. Добавить в настройку сервера параметр "Продолжительность" (Duration). Это позволит более продвинуто реагировать на тенденции при событиях типа "Счётчик "Х" на сервере "М" зарегистрировал событие "С", это событие повторилось "К" раз (или это событие продолжалось "В" секунд)".

Таким образом, можно будет более аккуратно реагировать на события и отслеживать не единичные срабатывания (например в случае с мониторингом температуры или загруженности процессора, при котором агент часто попадает на случайные пики активности при кратковременной повышенной активности), а реагировать на устойчивую тенденцию (например, в случае с загрузкой процессора это может быть 120 секунд или 2 цикла опроса, каждый по 60 секунд, т.е. если событие регистрировалось в течение 120 секунд или 2 раза в цикле опроса, то необходимо запустить Event и в дальнейшем реагировать согласно Event Processing'у).

2. Я конечно понимаю, что это выглядит как масло масленое, но всё же... Предлагаю в список Supported Agent Parameters добавить возможность локально работать с SNMP-запросами. Зачем? Как мне представляется, это было бы очень удобно с той точки зрения, что если мы, например, мониторим какую-то величину на сервере и ожидаем её повышения/понижения и хотим узнать только о том, что оно выросло/уменьшилось, то родной Агент в данном  случае имеет существенное преимущество: он отошлёт серверу сигнал только в том случае, если событие свершится. Всё остальное время канал сервера чист. А в случае с мониторингом SNMP-агента со стороны сервера мы постоянно имеем процесс "запрос-ответ". И при большом количестве серверов, на которых нужно в высокой точностью (очень небольшой период задержек между опросами) следить за указанной величиной, сервер только и будет заниматься тем, что рассылать SNMP-запросы. А так: событие, отслеживаемое локально агентом NetXMS через SNMP-запросы настало (величина изменилась) - агент NetXMS выслал серверу уведомление.

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

В случае одновременной работы с несколькими серверами (Win32) ничего из конфигурации не храниться на сервере локально? Всё хранится в базе?

Запрос: прошу если возможно рассмотреть вопрос об экспорте текущей конфигурации сервера (все ноды, DCI, Events). Вобщем всего того, что создаётся вручную после установки собственно сервера. Для последующего импорта на новом сервере.

Приветствую!

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

Можно для нубов, по шагам...? На абстрактном примере, кластер с двумя нодами.



Плиз.

Предлагаю реализовать следующее:

1. можно добавить возможность указывать в ком.строке при установке путь установки Агента (а то по умолчанию всегда ставится в корень)?

2. при ручной и команднострочной установке клиента было бы желательно иметь возможность указать доп. параметры типа "-M адрес_мастера_конфигураций" (т.е. иметь возможность указать Агенту что он полностью конфигозависим от сервера (серверов)). Кстати где хранится конфиг клиента при создании его средствами сервера? если в базе то отлично, никаких проблема рассинхронизации конфигураций при указании более чем одного мастер-сервера... опять же наверное можно реализовать таймаут по которому Агент будет при запросе конфига переходить от сервера к серверу если основной сервер недоступен.

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

Прошу рассмотреть возможность добавления я движок возможности использования в извещениях не только формата Text/Plain но и Text/HTML. Это не отвергает использования форматирования типа \t, \n и \\. Просто указанное форматирование можно использовать для Text/Plain, а для желающих использовать HTML-теги для подготовки письма можно ввести возможность переключения в альтернативный режим редактирования сообщения (открывать новое окно), где будет создаваться html (с изменяемым размером чтобы было удобно набирать и редактировать).

Спасибо!

Во-первых, хочу поблагодарить команду проекта за проделанную работу!
Честное слово, после OpenNMS я просто отдыхаю, настраивая мониторинг, сделанный вашими умелыми руками.
Мастера, прекрасная задумка и отличное воплощение! Так держать!

Теперь собственно к вопросам:

1. можно ли использовать в извещениях вместо "Text/Plain" формат "Text/HTML" дабы можно было использовать HTML-форматирование текста в письме?

2. при создании Event'ов мониторинга для контроля объёма свободного места на диске (3 степени: Warning, Minor & Major, в трэшхолде степени с параметрами расставлены в правильном порядке, я видел обсуждение подобной темы) с Event Log'ом всё прекрасно, т.е. если достигается значение Warning, то нода помечается как Warning.

Но как только подключаю Event Processing, начинается чудо: при заполнении диска до состояния, определённого мной как Warning, Event Log ловит состояние Warning, но нода почему-то помечается как Minor, и в дальнейшем сообщения-алерты приходят с Severity именно Minor, а не Warning.

Не могу понять в чём дело. Не страшно, но... Просто не понимаю.

3. Хочу поинтересоваться, как обстоит дело с написанием обработчика Win32 Event Log'ов? Очень полезная для меня (да думаю и не только для меня) вещь. Как только оно будет сделано, мониторинг имхо приобритёт функционально полностью завершённый вид. Так как в нём уже и так всё есть (по крайней мере всё, что именно мне нужно =) ). Останется только отлавливать мелкие баги (в чём мы вам чем сможем - поможем).

4. Можно ли штатными средствами переименовать Severity (я имею ввиду перевести на русский)? Чтобы можно было использовать что-то типа "Важно", "Для сведения", "Важно", "Критично" и т.п.

5. обнаружил, что в конфиге клиента отсутствует возможность привязать сервис к конкретному ip.
я плохо смотрел?

ситуация: прокси-сервер. один интерфейс внешний, другой - внутренний. не хочу что бы клиент слушал на обоих. как тут поступить?

6. Возможна ли (планируется ли) LDAP-авторизация для входа а админский графический интерфейс?

7. как правильно использовать "Agent Configurations"? я не нашёл конкретных упоминаний про него ни в документации, ни на форуме... Можно ли применить конфигурацию к уже установленным Агентам?

8. Насколько рабочей является фича "Agent Packages"? я всё сделал в настройках (согласно здравому смыслу), однако при запуске установки агента старый был приостановлен но дальнейших действий со стороны агента (собственно установки) не последовало (проверено- дистрибутив Агента на машину скачивается в var)...

И ещё раз большое спасибо вам за вашу работу!