0.2.23-rc3
-
отличная новость!! мы очень этого ждали! спасибо!
о проблемах: не разлистывается каталог - https://www.netxms.org/download/rc
а точное имя файла не известно... как ж его скачать?
- вопрос: нельзя ли коротЕнько обрисовать, как именно работает (алгоритм) модуль парсинга логов?
я имею в виду что меня интересует следующее:
- SysLog - мы ловим все поступающие на порт сообщения от лог-демонов, сравниваем с нашим шаблоном (условием) и если получаем именно то что ищем, то можно запускать процессинг...
т.е. в данном случае (при условии что мы ждём сообщение, указывающее на сбой\превышение\понижение) спокойно реализуема стандартная политика типа "получили совпадающее с шаблоном сообщение от удалённого syslog = есть проблема -> нода помечается как сбойная -> запомнили, что с конкретного сервера (устройства) приходило сообщение о проблеме -> ждём, когда придёт сообщение не совпадающее с шаблоном -> сообщение пришло (проблема рассосалась), сбойный статус ноды очищается". так, я правильно мыслю?
- 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"? это тоже, так, мысли вслух...
И ЕЩЁ РАЗ ОГРОМНОЕ СПАСИБО Вам за вашу работу!
-
@anth0ny said in 0.2.23-rc3:
о проблемах: не разлистывается каталог - https://www.netxms.org/download/rc
а точное имя файла не известно... как ж его скачать?ispravil
-
@anth0ny said in 0.2.23-rc3:
- вопрос: нельзя ли коротЕнько обрисовать, как именно работает (алгоритм) модуль парсинга логов?
я имею в виду что меня интересует следующее:
- SysLog - мы ловим все поступающие на порт сообщения от лог-демонов, сравниваем с нашим шаблоном (условием) и если получаем именно то что ищем, то можно запускать процессинг...
т.е. в данном случае (при условии что мы ждём сообщение, указывающее на сбой\превышение\понижение) спокойно реализуема стандартная политика типа "получили совпадающее с шаблоном сообщение от удалённого syslog = есть проблема -> нода помечается как сбойная -> запомнили, что с конкретного сервера (устройства) приходило сообщение о проблеме -> ждём, когда придёт сообщение не совпадающее с шаблоном -> сообщение пришло (проблема рассосалась), сбойный статус ноды очищается". так, я правильно мыслю?
Pochti tak. Esli ja hochu pomechat' nodu kak sbojnuju pri problemah i ubirat' otmetku kogda problema ischezla, eto budet vigljadet' tak:
- sozadt' shablon 1 dlja soobschenija ob oshibke, vibrat' sobitie kotoroe budet generitsja (EVENT_ERROR naprimer)
- sozdat' shablon dlja soobschenija o tom, chto problemi bol'she net, vibrat' sobitie kotoroe budet generitsja (EVENT_OK naprimer)
- dal'she kak obichno dlja threshold sobitij: delaem dva pravila v event policy, na EVENT_ERROR sozdaem alarm s kljuchom, na EVENT_OK terminiruem alarm s takim kljuchom.
ostal'nie otveti zavtra
-
-
Sorry, получилось "послезавтра"...
@anth0ny said in 0.2.23-rc3:
- Windows Event Logs - мы парсим логи на серверах и при обнаружении искомых комбинаций, подходящих под наши шаблоны, запускаем процессинг эвентов.
вот тут возникает вопрос: будет ли сервер мониторинг запоминать, в какое время в Event log'е Windows было сгенерировано найденное сообщение об ошибке? нужно для того, что бы чётко понимать, что следующее по времени сообщение, относящееся к тому же сервису\программе но уже с пометкой Info, указывает на то что проблема была решена.
см. объяснение про syslog - работает так-же.
@anth0ny said in 0.2.23-rc3:
так же крайне важно, что бы парсер ставил где-то у себя отметку о ДАТЕ\ВРЕМЕНИ последней обнаруженной АБСОЛЮТНО ЛЮБОЙ записи в логе, для того, что бы при следующем цикле не производилось сканирование системного лога РАНЕЕ этой обнаруженной записи. т.е. делается ли сейчас такой timestamp? логи не сканируются с начала?
Сейчас парсер просто ждет появления новых сообщений, то, что было на момент запуска - не сканируется. В будущем я планирую это сделать, хотя спорный вопрос - надо ли это делать всегда. Ведь если запись в логе была оставлена задолго до запуска парсера, то возможно что она уже не актуальна.
@anth0ny said in 0.2.23-rc3:
и если на сервере в процессе парсинга EL (Event Log) парсер натыкается сначала на одно сообщение об ошибке (нода помечается сбойной), потом на другое, потом на третье (и т.д.), будут ли эти обнаруженные ошибки добавляться к текущему набору проблем ноды?
т.е. если например будут обнаружены (последовательно, но в разные по времени циклы опроса)...
а) сбой или появление проблемы в работе нужного сервиса, причём что ВАЖНО: мы обнаруживаем не просто остановку, падение или проблему сервиса, а можем (должны мочь) определять, что конкретно с сервисом произошло.
б) проблема с аппаратной частью сервера, например сбой какого-то из контроллеров или HDD
в) системные сообщения о проблемах (возникших на уровне самой ОС)... то будут ли эти обнаруженные проблемы добавлены в список проблем ноды? точнее сказать, будет ли в этом случае список проблем ноды содержать все эти записи?
каждая запись, которая соответствует шаблону, вызывает создание события - а дальше все зависит от event processing policy - как напишете, так и будет.
@anth0ny said in 0.2.23-rc3:
ещё вопрос: как происходит обработка логов Windows? Используется regexp? можно ли привести более подробный пример именно для обработки логов Windows?
да, regexp.
@anth0ny said in 0.2.23-rc3:
по сути нас интересует большинство полей, причём в совокупности:
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-поиска конкретных деталей пришествия.
пока-что это только regexp на description - потом добавлю и остальные поля.
@anth0ny said in 0.2.23-rc3:
Так вот, к чему я...
Нельзя ли создать формализованную форму для поиска данных (шаблон сравнения) в логах Windows? Для заполнения через графический интерфейс? Т.е. форму, в целом полностью повторяющую внешний вид окна "Event Properties" Windows? Каждое из полей формы можно было бы заполнять данными, которые бы В СУММЕ участвовали в regexp-запросе... Если нет (возможности или желания) - ну и ладно, не важно, это был просто вопрос....
GUI для настройки мониторинга логов обязательно будет, но не сразу и скорее всего уже в новой консоли.
@anth0ny said in 0.2.23-rc3:
Кстати, Виктор, вопрос, нельзя ли как-то разграничить Windows Event Logs и NetXMS Event Logs более конкретными названиями? а то чем дальше, тем больше будет путаницы (имхо) если употреблять короткое "Event Logs". если раньше проблем не было только в силу того, что NXMS не работал с логами Windows, то теперь придётся постоянно уточнять ЧТО имеется в виду в каждом конкретном контексте. Может быть имеет смысл логи NetXMS переименовать в просто "NetXMS Logs"? это тоже, так, мысли вслух...
В NetXMS много разных логов - event log, snmp trap log, syslog, audit log - так-что просто NetXMS Logs не подходит...
-
@victor said:
см. объяснение про syslog - работает так-же.
секундочку... не совсем понял... Вы имеете в виду, что агент не просто смотрит Windows Event Log'и и сам сравнивает с заданнымы шаблонами, а транслирует записи из логов по мере появления на сервер мониторинга, который уже непосредственно занимается разбором полученного и сравнением, на подобии syslogd...? в реальном времени? я что-то уже запутался... разъясните технический момент плиз...
@victor said:
Сейчас парсер просто ждет появления новых сообщений, то, что было на момент запуска - не сканируется. В будущем я планирую это сделать, хотя спорный вопрос - надо ли это делать всегда. Ведь если запись в логе была оставлена задолго до запуска парсера, то возможно что она уже не актуальна.
это опять же отсылает меня к предыдущему ответу... каков механизм работы парсера windows-логов?
@victor said:
каждая запись, которая соответствует шаблону, вызывает создание события - а дальше все зависит от event processing policy - как напишете, так и будет.
да-да, это понятно
@victor said:
да, regexp.
стандартный regexp? можно ссылочку на документацию, если Вас не затруднит
@victor said:
пока-что это только regexp на description - потом добавлю и остальные поля.
опа... это означает, что мы сейчас не можем искать данные (в проверяемых логах) в полях Date, Time, Source, Type и Event ID? только в поле описания, Description? Если да, то это сильно сужает возможности парсера...
![😕](https://forum.netxms.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f615.png?v=72b86a538fc ":-\")
@victor said:
GUI для настройки мониторинга логов обязательно будет, но не сразу и скорее всего уже в новой консоли.
чтож, это не так важно сейчас, но будет замечательно потом
@victor said:
В NetXMS много разных логов - event log, snmp trap log, syslog, audit log - так-что просто NetXMS Logs не подходит...
ну... тогда даже и не знаю. значит придётся всегда указывать полные названия..
-
@anth0ny said in 0.2.23-rc3:
@victor said:
см. объяснение про syslog - работает так-же.
секундочку... не совсем понял... Вы имеете в виду, что агент не просто смотрит Windows Event Log'и и сам сравнивает с заданнымы шаблонами, а транслирует записи из логов по мере появления на сервер мониторинга, который уже непосредственно занимается разбором полученного и сравнением, на подобии syslogd...? в реальном времени? я что-то уже запутался... разъясните технический момент плиз...
Я имел ввиду что принцип тот-же - проверяем каждую новую запись на соответствие шаблону, и если соответствует - генерируем новое событие. Обработка логов производится агентом, на сервер отсылаются события.
@anth0ny said in 0.2.23-rc3:
@victor said:
да, regexp.
стандартный regexp? можно ссылочку на документацию, если Вас не затруднит
http://en.wikipedia.org/wiki/Regular_expression
NetXMS использует POSIX extended regular expressions.
@anth0ny said in 0.2.23-rc3:
@victor said:
пока-что это только regexp на description - потом добавлю и остальные поля.
опа... это означает, что мы сейчас не можем искать данные (в проверяемых логах) в полях Date, Time, Source, Type и Event ID? только в поле описания, Description? Если да, то это сильно сужает возможности парсера...
не все сразу
это пока-что бета-код, я его выложил чтобы народ его тестировал параллельно с дальнейшей разработкой. -
-
@anth0ny said in 0.2.23-rc3:
Виктор, приветствую
Как там насчёт релиза?Доделываю log parsing и еще разные мелочи.
-
-
Конечно планируется
Я думаю что в следующем релизе уже будет.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login