Необходимость мониторинга журнала событий Windows не вызывает сомнений. На эту тему регулярно появляются статьи, в том числе и на Хабре. Однако, почему-то все примеры сводятся к мониторингу заранее определенных EventID. В своей утилите WinLogCheck я выбрал другой путь — получить отчет по EventLog, исключив события, которые регулярно появляются и не представляют для меня интереса.
Как оказалось, это не уникальный вариант, на таком же подходе основана утилита для Linux — logcheck. Но вполне возможно, что мое решение, все-таки, появилось чуть раньше.
В этой статье я постараюсь обойтись без технических подробностей. Немного об истории создания — по-моему, это позволит понять, почему и в каких условиях появилась эта утилита и где-когда ее лучше использовать. Далее краткое описание алгоритма работы и что-то похожее на инструкцию по применению.
Краткая история и кому может пригодится WinLogCheck
Это решение позволяет мне в настоящее время контролировать больше десятка Windows Server и помогает мне в работе с 1998 года. Первая версия была написана на ActiveState Perl для мониторинга трех серверов на Windows NT 4. Для Windows Server 2003 была написана оболочка для Logparser на JScript. Но с выходом Windows Server 2008 пришлось начать с нуля. Была попытка написать на Powershell, но, поскольку иногда я принимаю участие в разработке программ и немного знаю C#, для меня оказался удобным именно этот вариант.
Самая первая версия была предназначена для работы в домене — утилита запускалась на одном из серверов и формировался отчет по всем серверам в домене. Однако, уже в Windows Server 2003 запрос к журналу событий по сети стал выполнятся слишком долго (в причинах не разбирался), а на обслуживании появились сервера вне основного домена компании, в которой работаю. Поэтому использовать какое-либо готовое централизованное решение в некоторых случаях просто невозможно.
Когда несколько лет назад в моем “подчинении” появились сервера под управлением Linux я узнал о существовании аналога своей утилиты — logcheck. Для тех кто не в курсе — утилита упоминается и рекомендуется во многих материалах по безопасности Linux и FreeBSD, например, в Debian Security Guide. После этого было принято решение сделать свою утилиту более удобной в использовании и опубликовать под именем WinLogCheck (первоначально она называлась UnknownEvents).
В результате утилита еще больше стала похожа logcheck — у меня она запускается в 9:00 на каждом сервере и через 5-10 минут в моем почтовом ящике больше десятка сообщений с отчетами. Обычно мне достаточно пары минут, чтобы просмотреть все.
Я несколько раз пытался найти готовый инструмент мониторинга, но ничего удобного, простого и практичного так и не встретил. Возможно, все дело в привычке. Тем не менее, если у вас не очень большое количество серверов — попробуйте, возможно, вам понравится мой вариант.
Как работает Winlogcheck
Алгоритм основного режима работы:
- Получить список зарегистрированных журналов событий. Для обычного Windows Server 2008 — 7, для сервера с Active Directory — 10.
- Для каждого журнала событий формируется запрос — получить список событий за последние сутки (приблизительно), исключая события, указанные в файле исключений “pathtowinlogcheckexclude<eventlog_name>.conf
- Из полученного списка формируется отчет в HTML, который пишется во временный файл (на тот случай, если письмо с отчетом не дойдет).
- Отчет отправляется по почте.
Несмотря на то, что в .NET есть свои методы для получения списка событий, я использую WMI (подробнее WMI Tasks: Event Logs). Так проще работать с тестом сообщения. Единственный минус — задержка при выполнении запросов при большом количестве записей в журнале. Например, на одном из контролеров домена создание отчета занимает 5-6 минут.
Вначале рабочего дня по каждому серверу я получаю примерно такой отчет (это отчет с реально работающего Windows Server 2008 R2 with Hyper-V):
Все в порядке, разовая ошибка в DNS-Client не требует особого внимания. Обратите внимание на Subject сообщения — чаще всего письма даже не требуется открывать: обычно тема заканчивается фразой “errors=0, warnings=0, other=0”.
Как использовать WinLogCheck
Параметры командной строки
Утилита запускается из командной строки с правами администратора.
Обязательный параметр — режим работы: EXCLUDE или INCLUDE. Запуск в основном EXCLUDE-режиме:
winlogcheck -m exclude
Два опциональных параметра предусмотрены для INCLUDE-режима (для себя я его называю режим спецотчетов):
-l <eventlog_name> — для указания журнала по которому надо получить отчет
-f — имя фильтра в файле “pathtowinlogcheckinclude<eventlog_name>.conf
Например, для отдельного отчета по успешным подключениям к RAS серверу на этом сервере у меня есть файл “pathtowinlogcheckincludesystem.conf” с таким текстом (о формате файла с фильтром — ниже):
[General]
RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272
Запускается тоже раз в день:
winlogcheck -m include -l system -f RASconnects
Естественно, такой же фильтр есть и для режима EXCUDE — чтобы в общем отчете по серверу эти записи отсутствовали. Один из отчетов:
В режиме EXCLUDE опциональные параметры использую только для тестирования.
Параметры программы
Параметры хранятся в конфигурационном файле winlogcheck.ini. Файл небольшой, поэтому привожу полностью с дополнительными комментариями:
[General]
## Глубина запроса (в часах).
## По умолчанию: за 24 часа (за последние сутки)
##
#TimePeriod = 24
## Каталог для записи отчетов
## По умолчанию: 'pathtowinlogcheckreports'
## Если вы не хотите получать отчеты по почте, можете записывать
## их в каталог, доступный на внутреннем веб-сервере.
## Когда-то я использовал такой вариант.
##
#ReportPath = c:inetpubwwwrootwinlogcheckreports
## CSS оформление для отчета.
## В одну строку!
##
ReportCSS = h1 {margin:0;font-weight:400} .servername, .subhead {font-weight:700} table {width:100%;} td {padding:0.25em} th {border:1px 0} tr:nth-child(odd) td {padding-bottom:1.5em, border-bottom:1px} tr:nth-child(even) {background-color:rgb(248,248,248)} caption {font-size:120%;text-align:left;padding:10px;background:rgb(216,216,216)} .error, .failure {background:rgb(255,127,127)} .warning {background:rgb(255,233,127)}
## Настройка почты
## Если закомментировано - отчеты не посылаются.
## Я использую свой почтовый сервер, поэтому
## аутентификация не поддерживается.
##
#[Mail]
#SMTP_Server = localhost
#Mail_From = Winlogcheck SERVERNAME <administrator@example.com>
#Mail_To = Administrator SERVERNAME <administrator@example.com>
Мониторинг работы самой утилиты
В разработках нашей компании используется NLog, поэтому я не стал изобретать велосипед. Во включенном в пакет конфигурационном файле для NLog настроены вывод журнала выполнения на консоль и в файл “pathtowinlogchecklogswinlogcheck.log” с ротацией (каждый день новый файл, срок хранения — 10 дней).
Настройка фильтров
Переходим к самому интересному. Типичный экран Event Viewer на сервере с установленным IIS:
Наверное всем знакомы события:
- «Winlogon»: ID 7001 или 7002 — «User Logon/Logoff Notification for Customer Experience Improvement Program»
- «Service Control Manager»: ID 7036 или 7040 с сообщениями: «The WinHTTP Web Proxy Auto-Discovery Service service entered the running/stopped state» или «The start type of the WinHTTP Web Proxy Auto-Discovery service was changed from… to… „
С ними все ясно — нам в отчете они не нужны.
Фильтры записываются с использованием SQL синтаксиса, названия полей в журнале событий отличаются от того, что мы видим на экране. Для составления фильтра мы можем использовать:
- Имя журнала событий. В данном случае “System”, значит фильтр запишем в файл “pathtowinlogcheckexcludesystem.conf”.
- Уровень — EventType (integer). В самом журнале определяется числами:
- 1 — Error
- 2 — Warning
- 3 — Information
- 4 — Success
- 5 — Failure
- Идентификатор события — Eventcode (integer)
- Категория — CategoryString (string)
- Источник — SourceName (string)
А то, что мы видим в описании события, находится в поле Message.
Таким образом, чтобы исключить из отчета указанные выше события, необходимо сформировать файл “pathtowinlogcheckexcludesystem.conf” с текстом:
[General]
UserNotify : SourceName = 'Microsoft-Windows-Winlogon' AND ( EventCode = 7001 OR EventCode = 7002 )
WinHTTP : SourceName = 'Service Control Manager' AND (EventCode = 7036 OR EventCode = 7040) AND Message LIKE '%WinHTTP%'
Комментарии к формату файла с фильтрами
- Первоначально в файлах с фильтрами использовались встроенные в язык типы данных, например в версии на JScript — объект Dictonary. Потом пробовал JSON. Но во всех случаях легко допустить ошибку, поэтому был выбран формат ini-файлов.
- Имя фильтра обязательно, но в настоящее время используется только в INCLUDE-режиме при построении специальных отчетов.
- Строка условия — вопросов вызывать не должна.
- Как вы могли заметить — все примеры для английской версии Windows Server. Тем не менее все прекрасно работает и на русской версии. Для этого необходимо, чтобы файлы фильтров были в UTF-8. Значение полей SourceName и CategoryString переводятся в самом Event Viewer, поэтому в запросах необходимо использовать английские аналоги, а вот текст сообщения — на русском. Возможно, в следующее обновление программы включу пример для русской версии Windows Server.
Основные фильтры, которые я использую в своей работе, включены в архив с утилитой.
Особое отношение только к журналу безопасности — очень часто в нем очень много событий, поэтому действует фильтр по умолчанию: в отчет попадают только ошибки.
Последние замечания
- На Codeplex опубликованы архив с программой и исходные коды программы под лицензией LGPL (особо не разбирался). Поскольку я не являюсь профессиональным программистом — кодом не хвастаюсь.
- Утилита была написана специально для WIndows Server 2008, однако работает и на единственном доступном Windows Server 2003. На новой версии WIndows Server 2012 еще не проверял, но проблем быть не должно. Также должна работать на Windows XP / Vista / 7 / 8.
- Описание и краткая инструкция для Codeplex были подготовлены с помощью Google Translate. Готовый перевод был проверен знающими и признан похожим на настоящий английский.:-). Если у кого есть опыт переводов технической документации — буду рад услышать замечания и предложения.
Очень часто поднимается вопрос о мониторинге Active Directory. Мое решение вполне можно использовать для решения этой задачи. Однако, я уже давно не занимаюсь управлением “большими» доменами, поэтому вымышленных примеров для мониторинга событий AD придумывать не стал.
Это решение не претендует на универсальность, но, на мой взгляд, вполне может пригодится в любой сети с небольшим количеством серверов под управлением Windows.
Автор: nelsh
