Как вы знаете, большинство «нормальных» приложений записывают свои события в журнал событий Windows (Application Event Log). Это отличное место для централизованного хранения и просмотра событий приложений, однако зачастую при возникновении необходимости журналировать события от определенного приложения в данном журнале, мы можем столкнуться с тем, что из-за большого количества и чрезмерной подробности событий, работать со стандартным журналом приложений Windows становится очень неудобно. В данном случае было бы удобно создать собственный журнал событий для данного приложения, и для него настраивать различные параметры, такие как размер журнала, фильтры и т.д., а стандартный журнал Application можно использовать как обычно, не засоряя его ненужной информацией. В ОС семейства Windows присутствует функция, позволяющая создать собственный журнал событий.
Сначала создадим новый файл журнала. Сделать это можно при помощи реестра. Запустите редактор реестра regedit и перейдите в ветку:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog
Щелкните правой кнопкой по узлу Eventlog и создайте новый ключ (New > Key)
Имя ключа в этом случае будет являться и именем нового журнала. По умолчанию новый журнал (файл .evt) создается тут:
C:\WINDOWS\System32\Config\New Key #1.evt
Его можно переименовать, изменив строковый параметр в реестре по своему усмотрению.
Далее нужно добавить источники (Sources) событий для нового журнала. Создайте новый ключ типа Multi-String с именем “Sources”, в качестве параметров укажите имена всех приложений, который будут использовать данный журнал (каждое приложение с новой строки).
Затем нужно перенести ассоциации ваших приложений из стандартного журнала Application в ваш новый журнал. Разверните ветку “Application”, находящуюся по адресу:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\Application
И скопируйте все ветки, которые относятся к интересуемым Вами приложениям в новый ветку реестра нового журналa:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\CustomLog
Т.к. команда скопировать/вставить в редакторе реестра не работает, их можно пересоздать вручную (если их немного), или же можно осуществить перенос при помощи процедуры экспорта/импорта веток реестра с ручным редактирование .reg файла. Убедитесь, что после переноса вы удалили ключи реестра ваших приложений из ветки Application, иначе Windows не поймет, что нужно писать события в новый журнал. В том случае, если вы используете новый источник событий для журнала, нужно будет создать параметр типа DWORD с именем CustomSource и значением равным 1:
В моем примере, я создал собственное приложение .NET 2.0, причем я хочу, чтобы оно записывало события в созданный нами журнал. Для этого я создам новый ключ реестра EventMessageFile и укажу в нем путь к библиотеке журналирования.NET 2.0:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
Затем нужно перезагрузить Windows, а после загрузки системы вы увидите новый журнал событий в разделе Event Viewer-а. В том случае, если ваше приложение по какой-либо причине не пишет событий в новый журнал, можно протестировать его работу вручную, откройте командую строку и перейдите в каталог:
CD C:\WINDOWS\system32
Затем наберите:
eventcreate /l CustomLog /t Information /so Application1 /id 1 /d "Test message"
В том случае, если вы все сделали правильно должно появиться окно, сообщающее о том, что событие было успешно записан в журнал, либо сообщение об ошибки и причины ее появления.
Update:
Небольшое обновление статьи по письмам читателей:
Вышеприведенная инструкция по созданию собственного журнала ориентирована на серверные ОС семейства Microsoft. Более общий способ, который должен работать в большинстве Windows следующий (отличаются пути в реестре и ключи):
Создаем новый раздел в реестре (имя раздела — имя создаваемого журнала), путь к созданному будет таким:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\NewEventLog , в котором нужно создать следующие ключи:
- «AutoBackupLogFiles» — тип DWORD, создавать или нет резервные копии журнала (0 — не создавать)
- «MaxSize» -тип DWORD, максимальны размер журнала в байтах, значение должно быть кратным 64Кб
- «Retention» — тип DWORD, время хранения записей в случае переполнения журнала.
- «File» — тип REG_EXPAND_SZ, строка, в которой содержится путь к логу журнала на жестком диске, например %SystemRoot%\System32\config\NewEventLog.evt)
- «Sources»- тип REG_MULTI_SZ, здесь указан список источников событий, чьи логи должны попадать в этот журнал, каждый источник с новой строки
Резюме: Microsoft Scripting Guy, Ed Wilson рассказывает о создании и использовании нового журнала событий посредством Windows PowerShell.
Использование PowerShell для создания нового журнала событий
Одна из замечательных вещей, которые можно делать с помощью Windows PowerShell – это создание собственного журнала событий. Здесь я говорю о классическом журнале событий (примеры таких журналов – это System, Security и Applcation). Windows PowerShell позволяет свободно читать, записывать, архивировать и очищать такие виды журналов.
Создаем журнал событий
Для создания нового журнала событий я воспользуюсь командлетом New-EventLog. Для этого мне понадобятся три вещи:
1. Открыть консоль Windows PowerShell с административными правами – в противном случае при попытке создания нового журнала будет возвращено сообщение об ошибке.
2. Имя создаваемого журнала.
3. Также мне будет нужно указать источник событий нового журнала.
Следующая команда создает новый классический журнал событий с именем ScriptingGuys и указывает источник событий с именем scripts.
New-EventLog -LogName ScriptingGuys -Source scripts
При запуске команды на экран не выводится никакой информации. Чтобы убедиться, что команда отработала должным образом, я воспользуюсь командлетом Get-EventLog с параметром –List.
C:\> Get-EventLog -List
Max(K) Retain OverflowAction Entries Log
------ ------ -------------- ------- ---
20,480 0 OverwriteAsNeeded 18,504 Application
20,480 0 OverwriteAsNeeded 0 HardwareEvents
512 7 OverwriteOlder 0 Internet Explorer
20,480 0 OverwriteAsNeeded 0 Key Management Service
10,240 0 OverwriteAsNeeded 4 Lenovo-Customer Feedback
512 7 OverwriteOlder 2 Lenovo-Lenovo Patch Utility/Admin
128 0 OverwriteAsNeeded 30 OAlerts
512 7 OverwriteOlder 0 ScriptingGuys
Security
20,480 0 OverwriteAsNeeded 21,437 System
15,360 0 OverwriteAsNeeded 10,059 Windows PowerShell
Конфигурируем новый журнал событий
Одна из вещей, которую я заметил при проверке создания журнала, это то, что его размер установлен в 512 KB, а срок сохранения событий равен 7 дням. Мне же нужно, чтобы размер журнала не превышал 64 KB, и события очищались по мере заполнения журнала. Мне казалось, что для этого подошел бы командлет Set-EventLog, однако командлета с таким именем не оказалось. Нужный командлет – Limit-EventLog. Просматривая файл справки, я заметил, что он обладает только одним набором параметров. Мне нужно установить параметр –OverflowAction в OverWriteAsNeeded, поэтому я предположил, что –RetentionDays нужно установить в 0. Я попробовал запустить следующую команду, но, как видите, появилось сообщение об ошибке.
C:\> Limit-EventLog -OverflowAction OverWriteAsNeeded -RetentionDays 0 -MaximumSize 64KB
Limit-EventLog : Cannot validate argument on parameter 'RetentionDays'. The 0 argument is less than the minimum allowed range of 1. Supply an argument that is greater than or equal to 1 and then try the command again. At line:1 char:65 + Limit-EventLog -OverflowAction OverWriteAsNeeded -RetentionDays 0 -MaximumSize + ~ + CategoryInfo : InvalidData: (:) [Limit-EventLog], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.LimitEventLogCommand
Тогда я попробовал запустить команду без параметра –RetentionDays, и это сработало.
Limit-EventLog -OverflowAction OverWriteAsNeeded -MaximumSize 64KB -LogName scriptingguys
Теперь я воспользуюсь командлетом Get-EventLog, чтобы убедиться, что изменения внесены. Вывод команды указывает на то, что внесение изменений произошло успешно.
C:\> Get-EventLog -list | ? log -eq scriptingguys
Max(K) Retain OverflowAction Entries Log
------ ------ -------------- ------- ---
64 0 OverwriteAsNeeded 0 ScriptingGuys
Я не могу обратиться к пустому журналу событий
Довольно интересно, что я не могу обратиться к журналу, не содержащему записей. Я пытаюсь получить содержимое журнала посредством командлета Get-EventLog и получаю следующую ошибку.
C:\> Get-EventLog -LogName scriptingguys
Get-EventLog : No matches found At line:1 char:1 + Get-EventLog -LogName scriptingguys + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (:) [Get-EventLog], ArgumentException + FullyQualifiedErrorId : GetEventLogNoEntriesFound,Microsoft.PowerShell.Commands.GetEventLogCommand
Запись в журнал событий
Для записи события, мне понадобится следующая информация:
1. Имя журнала событий (в нашем случае – это ScriptingGuys)
2. Источник события (scripts)
3. EventID (я начну с 1)
4. Тип записи (Information, Warning, Error)
5. Сообщение (то, что я хочу записать)
В следующем примере я добавляю в журнал событий новую запись.
Write-EventLog -LogName ScriptingGuys -Source scripts -Message "Dude, it works ... COOL!" -EventId 0 -EntryType information
Теперь я снова воспользуюсь командлетом Get-EventLog, чтобы получить только что записанное событие.
C:\> Get-EventLog -LogName scriptingguys
Index Time EntryType Source InstanceID Message
----- ---- --------- ------ ---------- -------
1 Jan 29 10:27 Information scripts 0 Dude, it wor...
Автор:
Ed Wilson, Microsoft Scripting Guy
Оригинал:
http://blogs.technet.com/b/heyscriptingguy/archive/2013/02/01/use-powershell-to-create-and-to-use-a-new-event-log.aspx
Страницы в социальных сетях:
Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell
С выходом Windows Vista в механизмах журналов Windows многое изменилось. В Windows 7 и Windows Server 2008 R2 эти механизмы получили дополнительное развитие. Теперь администраторы могут значительно упростить себе жизнь и сократить расходы на ИТ для небольшого предприятия, в разумных пределах, конечно. С некоторой натяжкой новые возможности можно назвать распределенным мониторингом «для бедных». Давайте рассмотрим эту тему несколько подробнее
. Сначала поговорим о системе журналирования в целом.
Компоненты системы журналирования
Прежде всего, как и в предыдущих версиях Windows, частью этой системы является служба журнала событий. Это, можно сказать, классический механизм журналирования, известный со времен Windows NT. Он обеспечивает поддержку нескольких стандартных журналов, в которые система и приложения могут писать различные сообщения при помощи специального API. Однако с появлением Windows Vista/Windows server 2008 этот механизм был значительно расширен. Наиболее значительным нововведением, на мой взгляд, является реализация поддержки технологии Event Tracing for Windows (ETW). Благодаря этой функциональности система журналирования научилась получать данные от провайдеров ETW, как системных, так и пользовательских. То есть появилась возможность расширять список отслеживаемых провайдеров за счет тех, которые могут предоставляться используемыми приложениями. Кроме того, теперь вы можете выполнять свой сценарий или приложение в ответ на определенное событие. Это может помочь в автоматизации работы системы.
Следующим расширением является встроенная возможность автоматически собирать данные журнала событий других компьютеров сети. Для этого в системе предусмотрена служба Windows Event Collector. Она создает и поддерживает подписки на события, которые регистрируются на удаленных машинах. Каждая подписка может подключаться к нескольким удаленным компьютерам, которые, в свою очередь, служат источниками событий. Любая подписка может иметь фильтр. Это помогает ограничить количество сообщений, которые будут доставляться с удаленных источников. Подписки могут быть нескольких типов. Тип подписки — это способ, которым будут собираться данные.
- Source-initiated subscriptions — события отправляются источником. Этот тип позволяет создать подписку на компьютере, который будет собирать события с удаленных источников. При этом удаленные компьютеры должны быть настроены при помощи глобальной политики таким образом, чтобы они отправляли свои события в единую точку. Такие подписки могут использоваться для сбора данных как с доменных машин, так и с машин, не входящих в ваш домен. Для проверки подлинности последних можно использовать сертификаты.
- Collector-initiated subscriptions — события собираются приемником. Если вы знаете список систем, с которых хотите собирать события, то вы можете настроить компьютер для сбора данных с систем, входящих в домен. При этом приемник будет самостоятельно опрашивать нужные системы и собирать с них данные. Этот тип подписки применим только в рамках домена.
Для работы в сети служба использует еще одну технологию — WS-Management, что накладывает определенные требования на компьютеры, которые могут служить источниками событий.
В дополнение к этим службам, к подсистеме журналирования событий условно можно отнести и службу планировщика заданий. Задания, которые вы создаете как реакции на различные события, исполняются в рамках этой службы.
Event Tracing for Windows
Сам по себе механизм Event Tracing for Windows имеет очень большие возможности. Основная его идея состоит в том, что многие компоненты как самой операционной системы, так и пользовательских приложений могут при помощи специального API отправлять сообщения о своем состоянии этому механизму по запросу. Компоненты, которые реализуют передачу событий, называются провайдерами событий. При этом нагрузка на систему во время сбора данных растет незначительно: на 20000 событий/с приходится примерно 5% процессорных ресурсов. Основным назначением данной системы является не очень длительная диагностика состояния системы, приложений и взаимодействия между ними. Сама по себе она не заменяет обычный журнал событий. Но другие внешние приложения, например служба журнала событий, могут подписываться на любые события, предоставляемые ETW через провайдеры событий. Для этого существуют так называемые каналы журнала событий, которые могут предоставляться провайдерами. То есть не все провайдеры предоставляют каналы для журнала событий. Именно эти каналы и провайдеры вы можете увидеть в журнале приложений и служб журнала событий (экран 1).
|
| Экран 1. Каналы и провайдеры для журнала событий |
Кроме того, список провайдеров можно получить при помощи двух утилит командной строки: xperf и wevtutil. Утилита xperf (экран 2) является частью пакета Microsoft Windows Performance Toolkit, и здесь мы не будем ее рассматривать, а утилитой wevtutil (экран 3) займемся немного позднее.
|
|
| Экран 2. Утилита xperf |
|
|
| Экран 3. Утилита wevtutil |
Следующей составляющей инфраструктуры событий можно считать планировщик заданий. Теперь эта служба используется системой очень активно, достаточно посмотреть на список заданий, существующих в системе по умолчанию. Теперь, например, можно привязать задание к определенному журналу или событию в журнале. А значит, реагировать на различные события в системе стало проще. Для этого требуется всего лишь выбрать нужное событие в журнале и, щелкнув правой кнопкой мыши, выбрать соответствующий пункт меню (экран 4).
|
|
| Экран 4. Привязка задания к определенному журналу или событию в журнале |
В результате появится окно мастера, в котором можно выбрать нужное действие, как на экране 5.
|
|
| Экран 5. Мастер создания задачи |
Свойства созданной задачи можно будет увидеть после ее создания, в самом конце процедуры, или в самом планировщике заданий. Как мы видим, задание запускается при появлении события с заданным EventID в журнале Application. Проверить это можно при помощи простой утилиты:
eventcreate/T error/id 1000/l application /d "test event"
Данная команда создаст запись с необходимыми нам параметрами в нужном журнале, и мы сразу увидим сообщение, сгенерированное планировщиком заданий (экран 6).
|
|
| Экран 6. Cообщение, сгенерированное планировщиком заданий |
Кроме того, задание можно создать и из командной строки, следующим образом:
SCHTASKS/Create/TN EventLog/TR "msg */server: localhost Message" /SC ONEVENT/EC Application /MO * [System/EventID=999]
Эта функция планировщика заданий тоже основана на ETW.
Служба журнала событий
Теперь перейдем непосредственно к службе журнала событий и ее возможностям. Служба eventlog запускается в процессе svchost и принадлежит к группе служб LocalServiceNetworkRestricted. Права доступа к ней показаны на экране 7.
|
|
| Экран 7. Права доступа к службе eventlog |
Получить SDDL — строки, описывающие права доступа к службе, можно при помощи утилиты sc:
sc qtriggerinfo eventlog
В задачи службы входит регистрация событий, как в стандартных, так и в расширенных журналах. Кроме того, она может подписываться на различные каналы провайдеров ETW.
Служба поддерживает несколько основных каналов: «Система», «Приложение», «Установка» и «Безопасность». Каждому из этих каналов соответствует один журнал, который можно просматривать при помощи Event Viewer. Каналы «Система» и «Приложение» предназначены для журналирования различных событий. Канал «Установка» предназначен для сообщений, связанных с установкой и настройкой, а «Безопасность» — для сообщений, связанных с безопасностью.
Расширенные функции и дополнительные журналы находятся в разделе журналов приложений и служб. Представленные в нем журналы разделены на несколько типов: административный, журнал операций, аналитический и отладочный журналы. События, содержащиеся в административном журнале, предназначены в первую очередь для конечных пользователей, администраторов и служб технической поддержки. Кроме самого описания проблемы, такой журнал предоставляет администратору всеобъемлющую информацию о способах ее решения. Такие события либо подробно описаны в документации, либо с ними связаны сообщения с четкими инструкциями по устранению проблемы. Записи в журнале операций служат для анализа и диагностики проблем или событий. Они могут использоваться для запуска средств или задач при возникновении соответствующих проблем или событий. Примером события в журнале операций является добавление или удаление устройства из системы. Аналитический и отладочный журналы не предназначены для повседневного использования. Мало того, для событий, которые регистрируются в отладочных журналах на конечной системе, может не быть метаданных для их интерпретации. Эти журналы предназначены для анализа производителями приложений и службы поддержки Microsoft. Там же можно создать собственные журналы событий при помощи powershell:
new-eventlog -source TestApp -logname TestLog
Каналы провайдеров ETW можно найти в папке Microsoft в этом разделе. Тут же вы найдете и примеры описанных выше типов журналов. Чтобы увидеть отладочные и аналитические журналы, нужно выбрать соответствующую настройку (экран 8).
|
|
| Экран 8. Включение просмотра отладочных и аналитических журналов |
После этого можно включить эти журналы для сбора событий своего провайдера, щелкнув правой кнопкой мыши по журналу и выбрав пункт «Включить журнал». Для того чтобы включить аналитический журнал из командной строки, можно сделать следующее:
wevtutil sl logname/e: true
Производители приложений могут предоставлять свои провайдеры для службы журнала событий. Для этого они должны разработать описание своего поставщика событий в виде XML документа — манифеста, затем откомпилировать этот манифест при помощи специальных утилит и импортировать его в журнал событий во время инсталляции продукта.
Отдельно стоит отметить журнал перенаправленных событий. Сюда по умолчанию сохраняются события, перенаправленные с других компьютеров сети. Об этом журнале мы поговорим позже.
Основной утилитой командной строки при работе с журналами является wevtutil. Некоторые примеры ее применения мы уже рассмотрели выше. Хочу обратить ваше внимание еще на некоторые ключи и результаты, позволяющие лучше понять нововведения в механизмах журналирования.
Как можно узнать, с каким поставщиком событий связан тот или иной журнал? Посмотрите на экран 9 и обратите внимание на выделенные строки. Параметр owningPublisher указывает на поставщика событий для этого журнала. Характерно, что для классического журнала «Приложение» этот параметр пуст. Кроме того, обратите внимание на тип файла журнала. В случае расширенного журнала это файл с расширением etl — event trace. В таких файлах сохраняются события ETW при их сборе утилитой xperf.
|
|
| Экран 9. Работа с wevtutil |
Следующая интересная функция — возможность делать выборки из журналов прямо из командной строки при помощи упрощенного запроса xpath. Например, используя стандартную утилиту wevtutil, можно выбрать все события с EventID=1000 из журнала «Приложение»:
wevtutil qe application "/q:* [System [(EventID=1000)]]"/f: text
Можно сделать то же самое, используя другой подход — сценарий на Powershell. В Powershell 2.0 появились команды, предназначенные для работы с расширенными возможностями службы журналирования. Одна из них — get-winevent. С ней запрос будет выглядеть вот так:
Get-WinEvent -LogName application -FilterXPath"* [System [(EventID=1000)]]"
Если вы хотите получить все ошибки и предупреждения, можно поступить так:
Get-WinEvent -LogName application -FilterXPath "* [System [(Level=1 or Level=2)]]»
Для того чтобы упростить себе задачу при написании таких запросов, можно пойти на хитрость. Графический интерфейс встроенного просмотровщика событий позволяет фильтровать представления журнала по определенным параметрам. В том же окне фильтра есть вкладка XML, на которой заданный вами фильтр будет представлен в виде XML. В таком виде его можно использовать для команды get-winevent с параметром -FilterXml или, взяв только запрос в квадратных скобках, можно применять его как в параметре -FilterXPath команды, так и в wevtutil.
Подписка на события
Перейдем, наконец, к самой интересной части — к подписке на события. За эту функцию отвечает служба Windows Event Collector. Запускается она со следующей командной строкой: C:\Windows\system32\svchost.exe -k NetworkService.
При помощи этой службы вы можете превратить свой сервер в единую точку сбора журналов событий с удаленных компьютеров. Однако для этого компьютеры должны удовлетворять некоторым требованиям.
WS-Management. Для сбора данных используется инфраструктура Windows remote management. Отсюда и вытекают все требования. Инфраструктура построена на протоколе ws-management, который в свою очередь использует HTTP, SOAP over HTTP (WS-I profile), SOAP 1.2, WS-Addressing, WS-Transfer, WS-Enumeration и WS-Eventing. Таким образом, для того чтобы можно было собирать события с удаленных источников, необходимо, чтобы на клиентах и сервере работала эта инфраструктура. Что для этого нужно? Необходим WinRM http://support.microsoft.com/kb/968929 — компонент, реализующий Windows remote management для Windows. Отсюда вытекают следующие требования.
WinRM 2.0 и PowerShell 2.0. Вы должны тем или иным способом установить и настроить WinRM на всех своих клиентских машинах, с которых будут собираться данные. Отрадно, что в Windows Server 2008 R2 и Windows 7 эти компоненты, как и необходимая для наших целей оболочка Powershell, уже есть.
После установки вам потребуется настроить WinRM. Для этого существует два способа. В первом случае можно использовать сценарий winrm.vbs, он же утилита winrm, во втором — Powershell. При первом способе настройка сводится к выполнению команды winrm quickconfig. Эта команда настроит сетевой экран, и, самое главное, создаст так называемый слушатель (Listener), который обеспечивает возможность подключения и сетевого взаимодействия с инфраструктурой. Слушатель по умолчанию создается для протокола HTTP по порту 5985. Для диагностических целей важно знать, как проверить наличие слушателя и его настроек. Для проверки настроек и наличия слушателя можно указать следующую команду:
C:\Windows\system32>winrm enumerate winrm/config/listener Listener Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 5.91.237.210, 10.10.5.45, 127.0.0.1,: :1, 2002:55b:edd2::55b:e dd2, fe80::100:7f:fffe%16, fe80::5efe:10.10. 5.45%12, fe80::200:5efe:5.91.237.210 %14, fe80::292f:e14a:be33:76c%11
Косвенно проверить, открыт ли и слушается ли нужный порт, можно командой netstat -an. С другой стороны, при помощи powershell эта задача выполняется следующим образом: настройка winrm — командой Set-WSManQuickConfig, а проверка слушателей протокола HTTP — вызовом get-wsmaninstance winrm/config/listener -selectorset @{Address=»*»; Transport=»http»}. Слушателей при необходимости можно создать вручную.
Для корректной работы сборщика событий на сервере и клиентах winrm должен быть настроен.
После этого для доменных конфигураций мы должны сделать следующее:
- Настроить на сервере сбора службу сбора событий.
- Создать политику пересылки данных для клиентов.
- Создать подписку соответствующего типа на сервере.
- Создать нужные правила для брандмауэра.
Для настройки службы выполним команду wecutil qc. В качестве примера создадим простейшую политику. Для этого во вновь созданном объекте групповой политики в разделе административных шаблонов выберите пункт Event Forwarders. В нем нужно указать сервер назначения в правильном формате. Формат настроек указан в пояснении к политике. В конечном виде настройка выглядит так, как показано на экране 10.
|
|
| Экран 10. Настроенная политика пересылки событий |
Следующий этап — создание подписки. Этот шаг делается на сборщике событий в оснастке просмотра журналов событий. На первом этапе выбирается тип подписки. Тут вы принимаете решение исходя из того, каким образом события будут собираться в конечной точке. Либо их будет собирать сам сервер, либо, как в нашем случае, клиенты будут присылать события сами. На втором шаге указываются группы компьютеров или отдельные компьютеры, которые будут иметь право отправлять сообщения. В данном окне речь идет только о правах, обратите на это внимание.
На третьем шаге выбираем фильтр событий, которые будут доставляться на сервер. Отдельный интерес представляет вкладка XML, о которой я упоминал ранее, в контексте фильтрации событий в журналах. На этой вкладке при помощи упрощенного XPath запроса можно задать свой специфический фильтр. Подписываться можно только на классические журналы и на административный и операционный каналы. Подписаться на каналы отладки нельзя.
На последнем шаге нам предстоит выбрать параметры доставки сообщений.
- Обычная. Данный параметр обеспечивает надежную доставку событий без попыток экономии пропускной способности сети. Это правильный выбор, когда не требуется жестко контролировать использование полосы пропускания или обеспечить максимально возможную скорость доставки событий. Применяется режим доставки pull и передача пакетов по пять событий с периодом задержки 15 минут.
- Уменьшенная пропускная способность. Этот параметр обеспечивает строгий контроль использования полосы пропускания для доставки событий. Подходящий выбор, если требуется ограничить частоту сетевых подключений для доставки событий. Используется режим доставки push и передача пакетов с периодом задержки 6 часов. Кроме того, используется интервал подтверждения соединения в 6 часов.
- Уменьшенная задержка. Этот параметр обеспечивает доставку событий с минимальной задержкой. Подходящий вариант при сборе оповещений или критических событий. Используется режим доставки push и передача пакетов с периодом задержки 30 секунд.
Обращаю ваше внимание, что режимы доставки в данном случае — это не то, каким образом будут передаваться данные. Это параметры API, которые отвечают за методы реакции сервера на полученные сообщения:
- модель push проталкивает события асинхронно путем вызова функций обратного вызова;
- модель pull использует обработчик событий, созданный в специальном объекте событий для того, чтобы уведомить вас о том, что поступили события, соответствующие вашему фильтру. После этого список полученных событий вы обрабатываете вручную.
На данном этапе также можно выбрать протокол доставки. В нашем случае это HTTP. Для использования HTTPS нужно дополнительно создать слушателей этого протокола.
Для того чтобы использовать параметр custom, при указании настроек доставки сообщений придется задействовать утилиту wecutil. При этом можно использовать как параметры командной строки, так и специально подготовленный XML-файл с конфигураций подписки. В рамках такого рода подписок можно изменять количество событий в пакете, отправляемом серверу, время между отправками, heartbeat-интервал, который используется как индикатор доступности источника данных.
Если все сделано правильно, то в журнале ForwardedEvents начнут появляться выбранные вами события с удаленных компьютеров.
Андрей Вернигора (eosfor@gmail.com) — администратор баз данных и системный администратор на одном из предприятий компании «Укртранснафта». Имеет сертификат MCP
on April 23, 2012
If you want to log an event in any of the event log files, then you can do that using eventcreate command. Logging an event helps the system administrators to trace out things if something has not worked in an expected way. Using this command, we can create a custom event with custom id and description. And we can log the event in any of the event log files(System, Application, Security etc). This post attempts to explain the usage of the eventcreate command.
EventCreate syntax
We need to pass certain parameters while creating an event. The basic ones are listed below.
/Id : Event id
/D : Event description
/T: Event type(can be any of error, information, success or warning)
/L : Event log file name
The syntax for creating an event from windows command line is as follows.
eventcreate /Id eventid /D eventDescription /T eventType /L eventLogfileName
Example:
Create an event in System log file with an id 500 and with the description – ‘windows auto update failed. Could not download the install files’
C:\>eventcreate /Id 500 /D “windows auto update failed. Could not download the install files” /T ERROR /L system
SUCCESS: An event of type ‘ERROR’ was created with ‘system’ as the log.
C:\>
After running the command, I find the below entry in the system log in event viewer(eventvwr.msc)
Specify source for the event:
You can specify how the event is generated by adding source information. This can be specified using /SO option. In the above example, if we want to specify the event source as ‘Windows update’, the command would be as below.
C:\>eventcreate /SO "Windows Update" /Id 500 /D "windows auto update failed. Could not download the install files" /T ERROR /L system
Create events on a remote system:
We can use eventcreate command to log events on remote computers also. We can specify the remote system details with /S (remote computer name/IP), /U (username) /p (password).
Example:
The below command creates an event on the system ‘10.192.10.10’.
C:\>eventcreate /S 10.192.10.10 /U administrator /P password /SO "Windows Update" /Id 500 /D "windows auto update failed. Could not download the install files" /T ERROR /L System SUCCESS: An event of type 'ERROR' was created in the 'System' log with 'Windows Update' as the source. C:\>
Related Posts:
Command line event viewer
How to clear or Backup Windows event log files?
Добрый день, уважаемый читатель!
Не буду тянуть резину, кратко и быстро расскажу основную последовательность действий, которые помогут тебе или твоей команде отображать кастомные логи в виндовом журнале событий для вашего приложения. Разберем на примере:
Дано: У нас есть некоторое приложение, для которого мы создаем оснастку yyyy: «Windows Event Viewer\Application and Services Logs\уууу».
Неудачный фактический результат. При работе приложения и записи логов в данную оснастку мы увидим ошибки вида:
Это означает, что источник событий yyyy не содержит в себе необходимый набор ID и Description.
Решение. Для того, чтобы исправить данную ситуацию, необходимо:
1. Открыть regedit по следующему пути: «HKLM\SYSTEM\CurrentControlSet\Services\EventLog» и убедиться в существовании вашего раздела.
2. Создать eventMessage.txt в который необходимо поместить ваши параметры, пример с msdn, сохранить в необходимой кодировке Windows-1251 или Unicode и формате eventMessage.mc.
Примечание: при наполнении eventMessage вашими ID и description всегда после описания необходимо ставить точку с новой строки, и после нее переводить каретку на новую строку. Если не учесть данной особенности, то могут быть непредвиденные ошибки во время компиляции.
Пример:
MessageId=0x1
SymbolicName=CAT_1
Language=English
OutDescription for your application
.
MessageId=0x2
3. Запустить терминал (cmd).
4. Выполнить команду: «mc.exe -u C:\SomeFolder\eventMessage.mc -r C:\SomeFolder\result» , где SomeFolder — некоторый каталог, в котором сохранили файлы из пункта 2.
Примечание: mc.exe, в частном случае, находится в «C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86» вместо формата -u (Unicode) можно использовать -A (W-1251 или ANSI, данный формат по умолчанию), а параметр -r является выходным расположением, куда будут сохранены файлы после компиляции.
5. После выполнения команды (пункт 4)будут созданы: бинарный файл и файл eventMessage.rc в «C:\SomeFolder\result».
6. Выполнить команду: «rc.exe C:\SomeFolder\result\eventMessage.rc».
Примечание: rc.exe находится в том же каталоге, где и mc.exe.
7. После команды компиляции (пункт 6) будет создан файл eventMessage.res, который необходим для создания динамической библиотеки (.dll).
8. Выполнить команду: «link.exe -dll -noentry /out:C:\SomeFolder\result\OurMessageSet.dll C:\SomeFolder\result\eventMessage.res».
Примечание: link.exe находится, в частном случае, в «C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\SDK\ScopeCppSDK\VC\bin».
9. Поздравляю, мы создали с Вами долгожданную библиотеку, но это еще не все. Заходим в regedit к нашему каталогу из пункта 1. В поле каталога создаем строковый параметр (string value), именуя сиё творение в EventMessageFile, а в значении указываем путь до нашей библиотеки: «C:\SomeFolder\result\OurMessageSet.dll».
Пример:
10. Запускаем приложение, наслаждаемся логами в нашей оснастке: «Windows Event Viewer\Application and Services Logs\уууу».
Инфо. Рассмотренные инструменты: mc.exe, rc.exe, link.exe.