Я собираюсь развернуть WEF в одном из наших новых лесов, и мне было интересно, как лучше всего структурировать журналы получения и подписки. В настоящее время у меня всего 4 журнала, которые я создал с помощью https://blogs.technet.microsoft.com/russellt/2016/05/18/creating-custom-windows-event-forwarding-logs/ (Контроллеры домена, серверы, рабочие станции, компьютеры вне домена) и имеют чуть более 10 подписок, каждая из которых является категорией событий, например События брандмауэра Windows, события активности учетных записей и групп и т. Д.
Это лучший способ сделать это? Было бы лучше, чтобы журналы назначения затеняли подписки? Может быть, нет правильного или неправильного пути, но, может быть, кто-то находится в похожей на меня ситуации и обладает некоторыми жемчужинами мудрости?
Чтобы дать вам представление о том, на что будет похожа эта среда - у нас есть в общей сложности 4 сайта, каждый с примерно 100–150 рабочими станциями и серверами. У меня будет сборщик на каждом сайте, который собирает события для всех компьютеров на сайте.
Спасибо вам за помощь
Я не видел особой ценности в структурировании настраиваемых пересылаемых журналов событий сборщика для соответствия подпискам. Такая нестандартная конфигурация и связь потребуют обслуживания и станут головной болью.
Журналы пересылаемых событий предназначены для использования в качестве временных промежуточных областей, в которых события обрабатываются автоматически после сбора для сохранения в базе данных и / или сигналов тревоги / уведомления. Они также могут быть огромными - десятки ГБ, не влияя на обработка производительность, поскольку они представляют собой циклические двоичные журналы. Единственным исключением для производительности является графический просмотрщик событий, но пересылаемые журналы не предназначены для использования графического просмотра событий.
Пользовательский код PowerShell Get-WindowsEvent или .NET для быстрого извлечения событий, необходимых в файл CSV или XML, на основе фильтрации по дате / времени и критериям событий с использованием фильтров запросов XML событий.
Я не вижу никаких инструкций по количеству подписчиков на одного сборщика, вероятно, потому, что это зависит от объема. Но у меня есть один сборщик и журнал пересылаемых событий по умолчанию с большим количеством подписчиков, чем описанный вами сценарий, который собирает миллионы событий в день и не близок к полной емкости.
Если разделение проблем действительно необходимо, я бы порекомендовал создать отдельный сборщик. Виртуальные серверы и хранилища стоят недорого.