. Сначала поговорим о системе журналирования в целом.

Компоненты системы журналирования

Прежде всего, как и в предыдущих версиях 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 должен быть настроен.

После этого для доменных конфигураций мы должны сделать следующее:

  1. Настроить на сервере сбора службу сбора событий.
  2. Создать политику пересылки данных для клиентов.
  3. Создать подписку соответствующего типа на сервере.
  4. Создать нужные правила для брандмауэра.

Для настройки службы выполним команду 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