NetXMS Support Forum

нет никаких предположений почему именно кластерный мониторинг отписывает каждый раз при рестарте сервиса мониторинга?

UP

очень жду патча.

Довольно долго пытался вникнуть в суть данного агента и так до конца и не понял как же он работает.

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

Я привык ориентироваться в документации на примеры и думаю мне вполне будет достаточно одного примера чтобы понять суть и способы применения...

Прошу помочь. =)

OMG спасибо за разъяснение! =)
Весьма элегантное решение! =)

А что слышно про патч для х64?

Оооооо...
Вон оно что...

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

Т.е. это система, которая не требует наличия DCI?

И работает такая логическая цепочка:

1) на агентской машине в логе появляется событие

нас это событие интересует и наш фильтр настроен на его отлов (пока по содержимому поля описания)

2) наш фильтр ловит это Событие и переправляет его КОД (который <event></event>) на сервер мониторинга, который постоянно ждёт прихода такого рода данных от агентов

у нас есть несколько Событий (Event'ов) на сервере мониторинга, номера которых совпадают с номерами из <event></event> в конфигах logwatch на Агентах

3) по приходу событий на сервер их номера сравниваются с номерами событий на сервере и если находится совпадение, то запускается процессинг

я правильно понял?
=)

=))) Виктор, да я не про то...

Я уже понял что всё что я написал- правильно.
Одного не могу понять: а КАК этим всем пользоваться??

ГДЕ ОНО, то самое волшебное место, где связываются События <event></event> от logwatch и события (Eventы) сервера?
Я вот чего пытаюсь добиться.

На текущий момент я вроде всё сконфигурил (и жду патча), но вот тупо не могу понять ГДЕ же это место в консоли?

Привожу полную цитату из https://www.netxms.org/forum/index.php/topic,483.0.html:

Quote
1. проверять сообщения, принимаемые встроенным syslog сервером на соответствия шаблонам и создавать события при соответствии;
2. через агента проверять записи в текстовых логах на соответствия шаблонам и создавать события при соответствии;
3. на Windows - то-же самое для Windows Event Log.

Для 1. надо обновить сервер, для 2 и 3 достаточно поставить новых агентов.

Как настраивать монтторинг логов через агента:

1. Создать необходимые события (через Control Panel -> Events);
2. В конфиге агента добавить загрузку субагента logwatch.nsm (libnsm_logwatch.so на UNIX);
3. Для каждого лога добавить запись вида Parser = config_file в секции LogWatch. Например так:

Code:

*LogWatch
Parser = /opt/netxms/etc/log_1.xml
Parser = /opt/netxms/etc/log_2.xml


4. Создать конфиги парсеров. Каждый конфиг - это отдельный XML файл следующего формата:

<parser>
   <file>file_name</file>
   <rules>
      <rule>
         <match>regexp</match>
         <event params="n">event_code</event>
      </rule>
      ...
   </rules>
</parser>

Таг <rule> можно повторять сколько необходимо. Аттрибут params в таге event указывает, сколько подстрок (обозначенных в regexp'e скобками) надо передать как параметры события (их потом можно использовать через макросы %1, %2, ...). Если параметров нет, то фттрибут events можно не указывать.
Для мониторинга Windows event logs вместо имени файла надо указывать *log_name, например *System

Я что-то не так понял или и для работы с логами Windows тоже нужно использовать встроенный syslog сервер?

А иначе я тупо не могу понять КАК работать с logwatch'ем.
Вроде всё почти сконфигурил а увидеть результаты где я смогу? Я же не могу создать DCI для запроса к logwatch, потому что именно Агент генерирует транзакцию. Так где в консоли искать это??

Ну... Скажем так:

есть сервер, на котором желательно мониторить логи (*System и *Application).
нужно в теле описания эвентов искать фразы типа "can not browse" (для Application) и "port browser stopped" (для System). жаль что пока нельзя искать по остальным атрибутам эвентов... очень ждём эту возможность.

что я сделал:

на Агенте

1. подключил в конфиге Агента субагента Logwatch


...
SubAgent = logwatch.nsm
...


2. создал 2 тестовых xml-конфига для субагента (s-watch.xml и a-watch.xml)

s-watch.xml


<parser>
   <file>*System</file>
   <rules>
      <rule>
         <match>port browser stopped</match>
         <event>100</event>
      </rule>
   </rules>
</parser>


a-watch.xml


<parser>
   <file>*Application</file>
   <rules>
      <rule>
         <match>can not browse</match>
         <event>101</event>
      </rule>
   </rules>
</parser>


3. Подключил оба конфига к Субагенту.


*LogWatch
Parser = C:\Program Files\NetXMS\etc\a-watch.xml
Parser = C:\Program Files\NetXMS\etc\s-watch.xml


на Сервере

4. Создал Event'ы (всего 4: активирующий и реактивирующий для каждого из 2 логов)
5. Создал Обработчики для всех 4ёх Event'ов.

6. Перезапустил Агента.

Дальше произошла ошибка о которой я сообщил в этом посте...
LogWatch: Cannot create parser from configuration file C:\Program Files\NetXMS\etc\a-watch.xml (Compiled without XML support)

И вот какая незадача: если честно, то я не совсем понимаю, а что же и где настраивать дальше?

Собственно это и есть проблема...

Благодарю =)

Ещё один вопрос по теме настроек: https://www.netxms.org/forum/index.php/topic,483.0.html

я, если честно, не понял, как именно настраивается обработка поступающих от Агентов эвентов?

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

а в данном случае с логами - как?

прошу разъяснить...

OS: Windows 2008 x64

Всё сделал как написано тут: https://www.netxms.org/forum/index.php/topic,483.0.html

После всех преготовлений перезапускаю Агента, и....
Получаю в System-логе вот такое сообщение:

LogWatch: Cannot create parser from configuration file C:\Program Files\NetXMS\etc\log_2.xml (Compiled without XML support)

Виктор, приветствую =)

Как там, планируется улучшать модуль парсинга windows-и файловых логов?
Меня лично весьма и весьма заботит и интересует именно парсинг windows-логов (всех полей: Date\Time\Source\Type\Event ID).

Ещё раз спасибо Вам за вашу работу!
=)

Thanks!

You have calmed me...

Hi Victor and 10x for your work! =)

One question:

I installed 0.2.24 over 0.2.23 (Windows). How can i manually check for fixed state of broken by 0.2.23 DB schema (what is it fixed now)?

=) благодарю за разъяснение

т.е. если я правильно понял, то как "реарм"-событие нужно в обоих трешолдах поставить DISK_CAPACITY_OK?

1) если MB < 2000 = Critical -> иначе Warning
2) если MB < 3000 = Warning -> иначе Normal

=)

это просто упрощённая формула слежения за диском (свободное место).

имеется в виду следующее: см. скрины

мониторим объём свободного места на диске. используем 2 порога: критический Critical (по достижении 2000 МБ) и предупредительный Warning (по достижении 3000 МБ). именно в таком порядке, что бы больший объём не перекрывал и не блокировал процессинг меньшего объёма на диске (чтобы трешолд меньшего объёма процессился раньше большего).

1) если DCI "Disk.Free(С:)" получает при опросе значение меньше или равно 2000 - значит запустить процессинг для события "DISK_CAPACITY_CRITICAL" и пометить DCI как "Critical".

Ждём, пока объём свободного места не станет меньше или равен 3000МБ, НО больше 2000.

Если это произошло, т.е. свободного места стало >2000 но <3000, то, согласно "When condition becomes False again ...", то мы генерируем событие DISK_CAPACITY_WARNING

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

второй трешолд сделан для того что бы очистить состояние DCI (перевести в Normal) сразу, как только свободного места станет >3000.

2) если DCI "Disk.Free(С:)" получает при опросе значение меньше или равно 3000 - значит запустить процессинг для события "DISK_CAPACITY_WARNING" и пометить DCI как "Warning".

Ждём, пока объём свободного места не станет больше 3000МБ.

Как только объём свободного места превысит пороговые (для Warning) 3000 - то переводим DCI в статус Normal.

Как-то так.

Несмотря на то что приходило извещение от багтрекера на тему закрытости вот этой проблемы, я снова получил сегодня подобную ошибку...

используется двойной трешолд в такой очерёдности:
(мониторится место на диске)

1) если MB < 1000 = Critical -> иначе Warning
2) если MB < 2000 = Warning -> иначе Normal

мой шаблон:

ПРЕДУПРЕЖДЕНИЕ: рекомендуется проверить состояние параметра "%2"! Текущее значение: %4 (пороговое значение: %3)

при достижении уровня Critical всё прошло нормально.
а вот что пришло при достижении (увеличилось место) уровня Warning:

ПРЕДУПРЕЖДЕНИЕ: рекомендуется проверить состояние параметра "Свободное место на диске T (Хранилище BESR) : (в MB)"! Текущее значение:  (пороговое значение: 0x000002D5)


и почему-то застрял процессинг... получаемое мониторингом значение свободного места уже превысило нужное для перехода в состояние Normal, а условие - не выполняется.... =( (не отрабатывает второй трешолд : если MB < 2000 = Warning -> иначе Normal)

это может быть связано с указанной ошибкой?