NetXMS Support Forum

да тут я вручную писал... очепятка. 
в моём собственном файле всё ок.

да и это роли по сути не играет, так как ПО ЛЮБОМУ не выполняется третья директива: дописка в кастомный файл лога состояния сервиса после перезапуска.

@sc query spooler >>query.log

я кстати и с net start \ net stop пробовал- тоже нету эффекта =(((
файл не создаётся.

я так понимаю что он должен создаться в \var\ ?

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

Не могу понять, где я не прав.
Прошу помочь- разъяснить.

Версия - 0.2.22.

ОС сервера NetXMS - Windows 2008.
ОС с Агентом - Windows 2003

Ведь всё вроде просто: https://www.netxms.org/forum/index.php/topic,204.0.html
Действовал в точности с инструкцией.

1) Создал Action типа "Execute action on remote agent".
Remote host: %a
Action: ResetSpooler

(Сразу вопрос: а почему в поле Action сразу нельзя использовать команды windows-шелла? если например мне не нужно ничего кроме перезапуска сервиса, то почему сразу нельзя использовать простейшую конструкцию типа "net stop spooler && net start spooler", а приходится создавать ватник на сервере, на котором должна быть выполнены данные команды?)

2) На сервере, за спулером которого мы приглядываем, в подкаталоге VAR каталоге Агента NetXMS (C:\Program Files\NetXMS\var) создал файл reset_spooler.cmd следующего содержания:

(Я не нашёл конкретных рекомендаций в форуме и документации на тему, ГДЕ ЖЕ нужно хранить исполняемые скрипты, нашёл только упоминание про \VAR\)


@echo off
@sc stop spooler
@cs start spooler
@sc query spooler >>query.log


3) В конфиг Агента добавлена строка: ActionShellExec = ResetSpooler:reset_spooler.cmd. Агент перезапущен через редактор конфига (Save and apply).
4) Создан DCI, отслеживающий состояние сервиса Windows Spooler: System.ServiceState(spooler).
5) Используется стандартный Event типа SYS_SERVICE_DOWN (Last polled value - not equal - 0).
6) Используется стандартный обработчик Event Processing Policy для SYS_SERVICE_DOWN, к нему привязаны 2 Action'а, Mail to admin (тип - Send e-mail) и Reset service (тип - Execute action on remote agent)

Всё. Судя по Форуму, начиная с этого момента всё должно начать работать...
Однако ж нет, из двух указаных Action срабатывает только mail to (и прекрасно работает), а вот скрипт НИ В КАКУЮ выполняться не хочет...

И хуже всего то, что нет никакой отладочной информации, чтобы понять, в каком именно месте я ошибся. Если ошибся.
Прошу помочь разобраться с данной проблемой. Существует ли какой-нибудь способ понять, почему не выполняется скрипт? Можно ли как-то вызвать дополнительную отладочную информацию и с её помощь понять причину проблемы?

Victor, can you explain a second option too, "Execute command on management server"? How it works and what's a different from "Execute action on remote agent"?

Please.

СПАСИБО!
Отличная и очень полезная работа!
Когда ждать релиза 0.2.23?

... не полностью Виктор, не полностью =)))
https://www.netxms.org/forum/index.php/topic,483.msg2426.html#msg2426

Использование "Data collection error" не помогло... нет никакого эффекта.
Сегодня добавил MaxSessions.

Посмотрим на результат...

Quote from: Victor Kirhenshtein
см. объяснение про syslog - работает так-же.

секундочку... не совсем понял... Вы имеете в виду, что агент не просто смотрит Windows Event Log'и и сам сравнивает с заданнымы шаблонами, а транслирует записи из логов по мере появления на сервер мониторинга, который уже непосредственно занимается разбором полученного и сравнением, на подобии syslogd...? в реальном времени? я что-то уже запутался... разъясните технический момент плиз...

Quote from: Victor Kirhenshtein
Сейчас парсер просто ждет появления новых сообщений, то, что было на момент запуска - не сканируется. В будущем я планирую это сделать, хотя спорный вопрос - надо ли это делать всегда. Ведь если запись в логе была оставлена задолго до запуска парсера, то возможно что она уже не актуальна.

это опять же отсылает меня к предыдущему ответу... каков механизм работы парсера windows-логов?

Quote from: Victor Kirhenshtein
каждая запись, которая соответствует шаблону, вызывает создание события - а дальше все зависит от event processing policy - как напишете, так и будет.

да-да, это понятно =)

Quote from: Victor Kirhenshtein
да, regexp.

стандартный regexp? можно ссылочку на документацию, если Вас не затруднит =)

Quote from: Victor Kirhenshtein
пока-что это только regexp на description - потом добавлю и остальные поля.

опа... это означает, что мы сейчас не можем искать данные (в проверяемых логах) в полях Date, Time, Source, Type и Event ID? только в поле описания, Description? Если да, то это сильно сужает возможности парсера... 

Quote from: Victor Kirhenshtein
GUI для настройки мониторинга логов обязательно будет, но не сразу и скорее всего уже в новой консоли.

чтож, это не так важно сейчас, но будет замечательно потом =)

Quote from: Victor Kirhenshtein
В NetXMS много разных логов - event log, snmp trap log, syslog, audit log - так-что просто NetXMS Logs не подходит...

ну... тогда даже и не знаю. значит придётся всегда указывать полные названия.. =)

Виктор, я всё ещё тут =)
Очень жду продолжения марлезонского балета =))

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

2 - имеется в виду Condition типа "Data collection error"?
т.е. если я выставлю Data collection error = 2 consecutive samples, то при двух ушедших и не вернувших значения запросах я получу срабатывание трешолда?

получено ещё одно подтверждение: мне сообщили что сервис Яндекса обделался ~20 минут назад, я проверил консоль мониторинга- всё ок. НО в архиве ответов агента серверу образовался провал, который как раз начинается с момента падения сервиса Яндекса и длился он (я специально проверил) до тех пор, пока я вручную не рестартовал этот сервис...

интересно вот что: сервис Яндекса зависает не полностью, а как бы чего-то ждёт... т.е. сразу отлупа при заходе на порт сервиса не происходит, а появляется стандартное Page loading, please wait... но запрошенная страница так и не появляется.

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

=(

т.е. в этом случае, я так думаю, нужно очевидно применить какой-то из вариантов стандартного ServiceCheck.HTTP но ждать не конкретного ответа, а любого ответа и ТОЛЬКО НЕ БОЛЕЕ ЧЕМ за указанный период времени (таймаут).

это возможно реализовать? =)

Виктор, обнаружил дополнительную информацию, которая возможно объясняет возникновение ранее описанной проблемы с перерывами в получении данных!

Просмотрел системный лог сервера, Агент которого ЯКОБЫ не отвечал. И обнаружил тьму однотипных записей (причём что ОЧЕНЬ интересно: ВСЕ записи представлены по ДВА раза), которые приходятся как раз на этот проблемный период и я так подозреваю что КАЖДАЯ ЗАПИСЬ = 1 ЦИКЛУ ОПРОСА (парные записи иду с одинаковым временем и интервалом ровно в 1 минуту):


Event Type: Warning
Event Source: NetXMS Win32 Agent
Event Category: None
Event ID: 13
Date: 05.10.2008
Time: 20:22:01
User: N/A
Computer: MYSERVER1

Description:
Too many communication sessions open - unable to accept new connection


Может быть мы имеем дело со своеобразным переполнением буфера в Агенте?
Если опрашиваемый мной сервис по какой-то причине начинает отвечать с бОльшими задержками, чем может переварить Агент и все последующие запросы (включая ежеминутные запросы о статусе Агента) начинают накапливаться в очереди, возможен такой эффект?

Т.е. не прошедшие запросы создают своего рода "пробку".
При этом Агент считается Сервером вполне работающим.

отличная новость!! мы очень этого ждали! спасибо!

о проблемах: не разлистывается каталог - https://www.netxms.org/download/rc
а точное имя файла не известно... как ж его скачать? =)

+ вопрос: нельзя ли коротЕнько обрисовать, как именно работает (алгоритм) модуль парсинга логов?

я имею в виду что меня интересует следующее:

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

т.е. в данном случае (при условии что мы ждём сообщение, указывающее на сбой\превышение\понижение) спокойно реализуема стандартная политика типа "получили совпадающее с шаблоном сообщение от удалённого syslog = есть проблема -> нода помечается как сбойная -> запомнили, что с конкретного сервера (устройства) приходило сообщение о проблеме -> ждём, когда придёт сообщение не совпадающее с шаблоном -> сообщение пришло (проблема рассосалась), сбойный статус ноды очищается". так, я правильно мыслю?

2) Windows Event Logs - мы парсим логи на серверах и при обнаружении искомых комбинаций, подходящих под наши шаблоны, запускаем процессинг эвентов.

вот тут возникает вопрос: будет ли сервер мониторинг запоминать, в какое время в Event log'е Windows было сгенерировано найденное сообщение об ошибке? нужно для того, что бы чётко понимать, что следующее по времени сообщение, относящееся к тому же сервису\программе но уже с пометкой Info, указывает на то что проблема была решена.

так же крайне важно, что бы парсер ставил где-то у себя отметку о ДАТЕ\ВРЕМЕНИ последней обнаруженной АБСОЛЮТНО ЛЮБОЙ записи в логе, для того, что бы при следующем цикле не производилось сканирование системного лога РАНЕЕ этой обнаруженной записи. т.е. делается ли сейчас такой timestamp? логи не сканируются с начала?

и если на сервере в процессе парсинга EL (Event Log) парсер натыкается сначала на одно сообщение об ошибке (нода помечается сбойной), потом на другое, потом на третье (и т.д.), будут ли эти обнаруженные ошибки добавляться к текущему набору проблем ноды?

т.е. если например будут обнаружены (последовательно, но в разные по времени циклы опроса)...

а) сбой или появление проблемы в работе нужного сервиса, причём что ВАЖНО: мы обнаруживаем не просто остановку, падение или проблему сервиса, а можем (должны мочь) определять, что конкретно с сервисом произошло.
б) проблема с аппаратной частью сервера, например сбой какого-то из контроллеров или HDD
в) системные сообщения о проблемах (возникших на уровне самой ОС)

... то будут ли эти обнаруженные проблемы добавлены в список проблем ноды? точнее сказать, будет ли в этом случае список проблем ноды содержать все эти записи?

ещё вопрос: как происходит обработка логов Windows? Используется regexp? можно ли привести более подробный пример именно для обработки логов Windows?

по сути нас интересует большинство полей, причём в совокупности:

Date - удобное поля для фиксации таймштампа возникновение проблемы. ведь проблема возникла не тогда когда её нашёл парсер, а именно тогда, когда она была зафиксирована в системном логе.
Time - относится к Date.
Source - источник возникшей проблемы (программа\служба\система)
Type - отличное поле для определения статуса события
Event ID - ОЧЕНЬ важное поле. позволяет нам различать, ЧТО ЖЕ ИМЕННО произошло со службой\системой\etc.

Я не знаю, в курсе ли народ, но всё равно хочу порекомендовать: www.eventid.net - прекрасный ресурс по ошибкам, генерируемым Windows и способам их решений. ОЧЕНЬ рекомендую. зачастую помогает значительно быстрее (больше вариантов решений), нежли родной мелкомягкий http://support.microsoft.com/.

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

Вот типичная ссылка:

http://www.eventid.net/display.asp?eventid=X&source=Y
где можно автоматом подставлять вместо X - Event ID, вместо Y - Source.

Пример: если ищем Source: Application Error и EventID: 1000
Строка: http://www.eventid.net/display.asp?eventid=1000&source=Application+error

В полученной форме нужно открыть пункт Details (Comments and links for event id 1000 from source Application Error).

И не просто выдавать отдельной строкой, мол "возможное здесь (ссылка) Вы найдёте решение этой проблемы" (интерактивно, при просмотре NetXMS Alarm Browser'а), а дать возможность вставлять такие готовые ссылки в письма-извещения, с той же припиской).

это размышления в слух... прошу не бить... =)


Description - отличное поле для regexp-поиска конкретных деталей пришествия.

Так вот, к чему я...

Нельзя ли создать формализованную форму для поиска данных (шаблон сравнения) в логах Windows? Для заполнения через графический интерфейс? Т.е. форму, в целом полностью повторяющую внешний вид окна "Event Properties" Windows? Каждое из полей формы можно было бы заполнять данными, которые бы В СУММЕ участвовали в regexp-запросе... Если нет (возможности или желания) - ну и ладно, не важно, это был просто вопрос.... =)

Кстати, Виктор, вопрос, нельзя ли как-то разграничить Windows Event Logs и NetXMS Event Logs более конкретными названиями? а то чем дальше, тем больше будет путаницы (имхо) если употреблять короткое "Event Logs". если раньше проблем не было только в силу того, что NXMS не работал с логами Windows, то теперь придётся постоянно уточнять ЧТО имеется в виду в каждом конкретном контексте. Может быть имеет смысл логи NetXMS переименовать в просто "NetXMS Logs"? это тоже, так, мысли вслух...


И ЕЩЁ РАЗ ОГРОМНОЕ СПАСИБО Вам за вашу работу!

как только обсёр случится, я пришлю логи с агентов...

Спасибо! =)

на всякий случай вот данные с других версий.

Windows 2003 R2: Date: Tue, 07 Oct 2008 10:25:24 Russian Daylight Time
Windows XP SP2: Date: Tue, 07 Oct 2008 10:28:05 Russian Standard Time