Централизованный сбор журналов событий с множества компьютеров через пересылку в Windows

Когда машин в сети больше десятка, разбирать их журналы событий по одной становится пыткой. Чтобы понять, не случилось ли где сбоя, приходится подключаться к каждому компьютеру, открывать просмотрщик, листать записи. На пятидесяти машинах это уже не работа, а каторга. Встроенная в Windows пересылка событий решает задачу элегантно: один компьютер назначается сборщиком, и все остальные сами отправляют ему свои события по сети. Администратор смотрит единый журнал на сборщике и видит картину со всего парка машин разом, не обходя их поодиночке. Самое ценное, что для этого не нужно ни единого агента или сторонней программы: вся механика встроена в систему и работает на родных протоколах.

Пересылка событий строится на двух ролях. Сборщик - это компьютер, куда стекаются события со всех остальных, он хранит их в специальном журнале пересланных событий. Источники - это машины, отправляющие свои события сборщику. Связь между ними задаётся подпиской, описывающей, какие события и с каких источников собирать. Под капотом всё работает на встроенном протоколе удалённого управления. Задача настройки - подготовить сборщик, разрешить источникам отправку и создать подписку, связывающую их.

Подготовка компьютера-сборщика событий

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

wecutil qc

Команда выполняет сразу несколько действий: включает канал пересланных событий, переводит службу сборщика событий в автоматический запуск и стартует её. После выполнения команда спрашивает подтверждение, и сборщик готов принимать события. Эта одна команда заменяет ручную настройку нескольких компонентов, делая подготовку сборщика быстрой. Параллельно убеждаются, что на сборщике работает служба удалённого управления, через которую и пойдёт доставка событий. Проверка её состояния делается запросом службы, и при необходимости её запускают. Правильно подготовленный сборщик - фундамент всей схемы, потому что без работающей службы сбора события просто некуда будет складывать, как бы исправно их ни отправляли источники. Стоит заранее прикинуть и нагрузку на сборщик: при сотнях источников поток событий бывает велик, и журналу пересланных событий заранее задают увеличенный размер, чтобы он не переполнялся и не вытеснял свежие записи раньше времени. На крупный сбор сборщик выделяют отдельной машиной с запасом по диску, а не нагружают этой ролью попутно занятый сервер.

Разрешение отправки событий на компьютерах-источниках

На каждой машине-источнике, с которой собирают события, включают службу удалённого управления и дают сборщику право читать журнал. Включение службы удалённого управления делается командой быстрой настройки:

winrm quickconfig

Команда настраивает службу удалённого управления, открывает нужные правила защитного экрана и запускает приём подключений. Это базовый шаг, без которого источник не сможет общаться со сборщиком. Дальше учётной записи сборщика дают право читать журнал событий источника, добавив её в соответствующую локальную группу. Право на чтение журнала необходимо, иначе сборщик не сможет забирать события, даже когда связь установлена. В доменной сети эти настройки удобнее раздать централизованно через групповую политику сразу на множество машин, чем настраивать каждую вручную. Подготовка источника сводится к двум вещам: открыть канал связи службой удалённого управления и дать сборщику разрешение на чтение журнала, и только когда обе выполнены, источник готов отдавать события.

Создание подписки на сборе событий

Сердце схемы - подписка, описывающая, какие события и откуда собирать. Её создают на сборщике. Подписки бывают двух типов по тому, кто инициирует связь: сборщик сам опрашивает источники или источники сами шлют события сборщику. Для большой сети удобнее второй вариант, где источники инициируют отправку. Создание подписки удобнее всего делать через графический интерфейс просмотрщика событий, где в разделе подписок мастер проводит по всем шагам: задаётся имя, выбирается тип, указываются источники и фильтр событий.

Тонкую настройку подписки выполняют служебной командой. Просмотр существующих подписок делается так:

wecutil es

Команда выводит список всех настроенных подписок. Детали конкретной подписки смотрят отдельной командой с её именем. Через эту же служебную команду меняют параметры подписки, недоступные в графическом интерфейсе, например частоту доставки событий. Подписка - это договор между сборщиком и источниками о том, что именно собирать: можно тянуть все события, а можно только ошибки определённого журнала, экономя сеть и место. Правильно настроенный фильтр подписки отсекает информационный шум ещё на источнике, и сборщик получает только то, что действительно нужно для наблюдения.

Управление частотой и объёмом пересылки

По умолчанию пересылка работает с компромиссными настройками, но их подстраивают под задачу. Готовые режимы доставки различаются частотой: обычный режим собирает события с задержкой ради экономии сети, режим минимальной задержки шлёт их почти сразу, что важно для срочных событий безопасности. Выбор режима задаётся при создании подписки. Графический интерфейс предлагает готовые режимы, а тонкую частоту настраивают служебной командой. Изменение параметров подписки делается командой настройки с указанием имени подписки и нужных значений.

Частота - это всегда компромисс между свежестью данных и нагрузкой на сеть. Минимальная задержка даёт почти мгновенную доставку, но грузит сеть постоянным потоком, а обычный режим экономит сеть ценой задержки в доставке. Для наблюдения за безопасностью выбирают минимальную задержку, чтобы тревожные события приходили сразу, а для рутинного сбора статистики хватает обычного режима. Отдельный важный параметр - максимальное число событий в одной отправке, ограничивающее размер пачки. Понимание этих настроек позволяет настроить пересылку под конкретную нагрузку, не перегружая сеть и не теряя свежести там, где она критична.

Массовая настройка источников через групповую политику

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

Преимущество такого подхода в масштабе: добавили строку в одну политику, и все машины, на которые она распространяется, начинают слать события сборщику без всякой ручной настройки на каждой. Новый компьютер, попавший в область действия политики, автоматически становится источником, как только применит политику. Это снимает главную головную боль большой сети, где настраивать сотни машин поодиночке немыслимо. После задания политики на машинах принудительно обновляют её применение командой обновления политик, чтобы не ждать планового цикла. Через групповую политику раздают и права на чтение журнала, и настройки службы удалённого управления, так что вся подготовка источника сводится к попаданию машины в нужную группу. Это превращает развёртывание сбора событий на весь парк из многодневного труда в разовую настройку одной политики, после которой система сама подключает к сбору каждую новую машину.

Фильтрация пересылаемых событий для экономии ресурсов

Слать сборщику все подряд события со всех машин расточительно: сеть забивается, журнал сборщика пухнет, а в потоке тонут действительно важные записи. Поэтому в подписке задают точный фильтр, отбирающий только нужное. Фильтр описывается на языке запросов событий, том же, что и для обычного поиска по журналу. Например, подписка может собирать только ошибки и предупреждения системного журнала, игнорируя информационный шум, или только события безопасности определённых кодов, важные для наблюдения за входами в систему.

Грамотный фильтр - ключ к работоспособности всей схемы в большой сети. Без него сборщик захлебнётся в потоке ненужных записей, а с ним получает только то, что действительно требует внимания. Фильтр задают при создании подписки, и его легко изменить потом, подстроив под меняющиеся нужды наблюдения. Особенно важна фильтрация для событий безопасности: их генерируется огромное количество, и собирать все нет смысла, нужны лишь ключевые коды входов, отказов доступа и изменений прав. Продуманный фильтр экономит и сеть, и место на сборщике, и внимание администратора, который не вынужден просеивать тонны рутинных записей в поисках важного. Это превращает централизованный сбор из источника информационной перегрузки в точный инструмент наблюдения, доставляющий ровно те события, что нужны для контроля над сетью.

Проверка работы и разбор типичных проблем

После настройки убеждаются, что события действительно поступают. Их смотрят в специальном журнале пересланных событий на сборщике через обычные средства просмотра. Запрос пересланных событий делается командой оболочки PowerShell:

Get-WinEvent -LogName "ForwardedEvents" -MaxEvents 20

Команда показывает последние события, пришедшие от источников. Если события идут, схема работает. Если журнал пуст, проблему ищут по цепочке. Чаще всего виноваты базовые вещи, а не сама подписка: источник не видит сборщик по имени из-за разрешения имён, не совпадает время на машинах, не хватает прав на чтение журнала, или групповая политика ещё не применилась на источнике. Проверяют связь источника со сборщиком по имени и доступность службы удалённого управления. Полезны и собственные журналы служб пересылки и удалённого управления на обеих машинах, где видны ошибки доставки. Методичная проверка этой цепочки почти всегда находит причину, потому что сама пересылка работает надёжно, а сбои случаются на подготовительных условиях.

Отдельного внимания заслуживает синхронность времени на машинах. Если часы источника и сборщика расходятся, пересланные события получают неверные временные метки, и хронология в журнале сборщика рассыпается: событие, случившееся раньше, может оказаться позже по времени. В доменной сети время обычно синхронизируется автоматически, но в смешанных средах за этим следят отдельно. Расхождение времени коварно тем, что пересылка вроде работает, события приходят, но их порядок врёт, и анализ инцидента по такой искажённой ленте уводит в ложном направлении. Поэтому перед запуском сбора убеждаются, что все машины сверяют часы с единым источником времени, иначе вся ценность централизованной хронологии теряется.

Централизованная пересылка событий превращает разрозненный парк машин в единую наблюдаемую систему. Вместо обхода десятков компьютеров администратор смотрит один журнал на сборщике и видит всё сразу. Настройка укладывается в три шага: подготовить сборщик одной командой инициализации, разрешить источникам отправку через службу удалённого управления и права на чтение, создать подписку с нужным фильтром и частотой. Главная ценность подхода в том, что он не требует ни агентов, ни сторонних программ, целиком опираясь на встроенные механизмы. Освоив эту настройку, администратор поднимает наблюдение за журналами на новый уровень: проблема на любой машине сети всплывает в едином журнале сборщика, и её замечают, не подключаясь к источнику. Это особенно ценно в больших сетях, где ручной обход машин физически невозможен, а централизованный сбор событий становится единственным способом держать руку на пульсе всего парка одновременно.