Сбор логов Windows: Event Log, Winlogbeat и Vector. Полное руководство 2026

Зачем централизовать логи Windows и что вы получите на выходе

Централизованный сбор логов Windows закрывает три задачи. Безопасность: входы, назначение привилегий, создание процессов и очистка журналов видны на всех хостах в одном окне, без поездок по RDP с Event Viewer на каждый сервер. Эксплуатация: события служб и приложений ложатся на единую временную шкалу, и инцидент, задевший несколько машин, разбирается за минуты. Комплаенс: срок хранения задаёте вы, а не размер локального журнала.

Коротко о решении: на Windows-хост ставится агент (Winlogbeat или Vector), он читает выбранные каналы Event Log, фильтрует шум и отправляет события по TLS в приёмник (Elasticsearch, OpenSearch, Graylog или Grafana Loki), где их ищут, визуализируют и алертит. Агент работает как Windows Service, читает журналы через Event Log API (функции EvtQuery и EvtSubscribe), держит очередь и переживает недоступность приёмника. Локальный журнал перезаписывается по кругу: на активном сервере записи старше нескольких дней исчезают безвозвратно.

Чек-лист «нужен ли мне пайплайн». Больше десяти серверов или рабочих станций? Есть требования расследовать инциденты и проходить аудит? Нужно сопоставлять события с разных машин по времени? Планируете алерты на 4625, 4720 или 1102? Два ответа «да» и больше означают, что связка агент плюс приёмник окупает время на настройку. Один домашний сервер с чтением логов раз в месяц закрывается локальным Event Viewer.

Типовая ошибка на старте: включить все каналы без фильтрации. Security на контроллере домена выдаёт десятки тысяч событий в час, хранилище забивается шумом за недели, а затраты на хранение растут. Ограничивайте поток на агенте: так вы экономите трафик, CPU приёмника и место на дисках.

Active Directory остаётся одной из основных целей при атаке на корпоративную инфраструктуру. Получив обычную доменную учётку, злоумышленник ищет учётные записи с большими правами, и цепочка «неудачные входы, успешный вход, назначение привилегий, создание новой учётной записи» собирается только из Security и Sysmon в одном хранилище.

Приёмник выбирают под задачи: Elasticsearch или OpenSearch для полнотекстового поиска и SIEM, Graylog для быстрого старта с готовым интерфейсом, Grafana Loki для недорогого хранения с индексацией по меткам. Разместить его можно на собственном железе или в облаке: Timeweb Cloud даёт серверы, VDS/VPS и Kubernetes, на которых Elasticsearch, OpenSearch или Graylog поднимаются без покупки физических машин.

Какие каналы Event Log действительно стоит собирать

Сбор логов Windows - это не один журнал, а десятки каналов. Базовый набор для сервера:

• Security: 4624 (успешный вход), 4625 (неудачный вход), 4672 (назначение специальных привилегий), 4688 (создание процесса), 4720 (создана учётная запись), 4726 (учётная запись удалена), 4728, 4732 и 4756 (изменение состава групп), 1102 (журнал очищен).
• System: запуск и остановка служб, ошибки драйверов, неожиданные перезагрузки.
• Application: события приложений и служб, которые пишут в этот канал.
• Microsoft-Windows-Sysmon/Operational: создание процессов с командной строкой, сетевые соединения, загрузка драйверов.
• Microsoft-Windows-PowerShell/Operational: 4103 (логирование модулей) и 4104 (логирование блоков скриптов).
• Microsoft-Windows-TerminalServices-LocalSessionManager/Operational: RDP-сессии, подключения и отключения.
• Microsoft-Windows-TaskScheduler/Operational: создание и запуск задач, излюбленный способ закрепления в системе.
• Microsoft-Windows-Windows Defender/Operational: 1116 (обнаружение) и 1117 (действие по угрозе).

Sysmon устанавливается отдельно, по умолчанию его канала в системе нет. Именно Sysmon даёт полную командную строку процесса, идентификатор родительского процесса и хеши файлов. Без него событие 4688 показывает имя процесса и не всегда аргументы запуска: включите аудит создания процессов с командной строкой через GPO в разделе Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking.

Ориентиры по объёму нужны, чтобы планировать хранилище. Файловый сервер средней загрузки: 1-5 тыс. событий в час в канале Security. Контроллер домена при интенсивной аутентификации: 10-50 тыс. событий в час. Sysmon на активном сервере добавляет 5-20 тыс. событий в час. События 4634 (выход из системы) и 5156 (разрешение сетевого соединения) в больших объёмах дают шум, а польза для расследований низкая.

Целевая архитектура: агент на хосте и приёмник в центре

Рабочий пайплайн состоит из пяти слоёв:

1. Агент запущен как Windows Service с автоматическим стартом и переживает перезагрузку.
2. Чтение каналов идёт через Windows Event Log API: EvtQuery выбирает нужные записи, EvtSubscribe оформляет подписку на новые.
3. События попадают в очередь. Vector умеет держать очередь на диске, Winlogbeat держит её в памяти, а неотправленные записи остаются в самом журнале.
4. Доставка идёт батчами по TLS до приёмника.
5. Приёмник индексирует записи и применяет политику хранения: ILM в Elasticsearch, ISM в OpenSearch, ротацию индексов в Graylog, retention в Loki.

Требование к агенту одно: не терять позицию чтения. Winlogbeat хранит отметку последнего прочитанного события в реестре Windows, ветка HKEY_LOCAL_MACHINE\SOFTWARE\Elastic\Beats. Vector сохраняет позицию в checkpoint-файле. Перезапуск службы в обоих случаях не приводит к повторному чтению всего журнала.

Разбор архитектуры и сравнение компонентов есть в статье Централизованный сбор и анализ логов в 2026.

Winlogbeat или Vector: что выбрать под вашу задачу

Оба агента читают Windows Event Log, работают службами и умеют фильтровать события. Разница в экосистеме, наборе приёмников и языке обработки. Выбор сводится к двум вопросам: какой у вас приёмник и нужна ли обработка на стороне агента.

Winlogbeat написан на Go и входит в семейство Beats. Он отправляет события в Elasticsearch, Logstash, Kafka, Redis и файл. Фильтрация выполняется параметрами источника (event_id, level) и процессорами (drop_event, include_fields). Конфигурация короткая: каналы, фильтры, output. Если Elastic или OpenSearch уже развёрнуты, Winlogbeat запускается за 15 минут.

Vector написан на Rust и работает агентом и агрегатором в одном бинарнике. Источник windows_event_log читает каналы, трансформации на VRL дают полноценный язык обработки, набор sinks покрывает Elasticsearch, OpenSearch, Loki, GELF для Graylog, ClickHouse, Kafka и S3. Один поток разветвляется на несколько приёмников: события безопасности уходят в SIEM, отладочный поток идёт в Loki.

Практическое правило. Elastic-стек уже стоит, обработка минимальна: берите Winlogbeat. Нужны Loki, Graylog, ClickHouse или два приёмника одновременно: берите Vector. Парк перевалил за сотню хостов и нужен единый пульт управления конфигурацией: смотрите в сторону Elastic Agent, учитывая его вес и привязку к Elastic.

Сравнение стеков по стоимости, сложности и сценариям собрано в статье Системы сбора и анализа логов в 2026: выбираем стек.

Сравнительная таблица: ресурсы, форматы, приёмники

Цифры по памяти - ориентиры для одного сервера с потоком до 5 тыс. событий в час, не гарантия. На потребление влияют число каналов, объём потока и настройки батчинга, поэтому замер на пилотном хосте обязателен.

Когда Elastic Agent оправдан, а когда избыточен

Elastic Agent управляется через Fleet: конфигурация, обновления и интеграции приходят с сервера, локальные файлы не правятся руками. Схема удобна, когда хостов сотни и есть команда, которая занимается Elastic-стеком ежедневно. Ограничения: агент тяжелее, пайплайн сложнее кастомизировать, отправка только в Elastic.

Для парка из 10-30 серверов Fleet добавляет лишний компонент. Winlogbeat без Fleet проще отлаживать, а конфиг раскатывается через Ansible или GPO. Elastic Agent раскрывается в крупных инсталляциях с централизованной безопасностью и единым UI.

Настройка Winlogbeat: каналы, фильтры, отправка

Конфигурации из этой статьи рассчитаны на актуальные версии Windows Server и Windows 10/11; синтаксис агента сверяйте с вашей версией. Установка занимает пару минут: MSI-пакет создаёт службу автоматически.

msiexec /i winlogbeat-8.x.msi

Файл конфигурации лежит в C:\Program Files\Winlogbeat\winlogbeat.yml. Минимальный рабочий набор для сервера выглядит так:

winlogbeat.event_logs:
  - name: Security
    event_id: 4624, 4625, 4672, 4688, 4720, 4726, 4732, 1102
    ignore_older: 72h
  - name: System
    level: warning
  - name: Application
    level: warning
  - name: Microsoft-Windows-Sysmon/Operational
  - name: Microsoft-Windows-PowerShell/Operational
    event_id: 4103, 4104

output.elasticsearch:
  hosts: ["https://srv-es01.local:9200"]
  protocol: https
  username: "winlogbeat_writer"
  password: "${ES_PASSWORD}"
  ssl.certificate_authorities: ["C:/certs/ca.crt"]
  index: "winlogbeat-%{[agent.version]}-%{+yyyy.MM.dd}"

logging.level: info

Проверка перед запуском: winlogbeat test config валидирует YAML, winlogbeat test output проверяет соединение с приёмником и права. Обе команды запускайте от администратора, иначе получите ложные ошибки доступа.

Права. Служба по умолчанию работает под LocalSystem и читает канал Security. Если политика запрещает LocalSystem, назначьте отдельную учётную запись и добавьте её в группу Event Log Readers. Этого хватает для чтения журналов, права администратора домена агенту не нужны.

Фильтрация событий: event_id, XPath и processors

Фильтрация на агенте снижает трафик, нагрузку на приёмник и стоимость хранения. У Winlogbeat три уровня фильтрации.

Первый: параметры источника. Поля event_id, level и provider превращаются в XPath-запрос, который Windows выполняет на своей стороне. Отсечение идёт до чтения записей, CPU и диск расходуются минимально.

Второй: процессоры. drop_event выбрасывает события по условию, include_fields оставляет только нужные поля, add_fields добавляет метки окружения и роли.

processors:
  - drop_event.when.equals:
      winlog.event_id: 4634
  - drop_event.when.equals:
      winlog.event_id: 5156
  - add_fields:
      target: ""
      fields:
        env: prod
        role: dc
  - include_fields:
      fields: ["@timestamp", "winlog.event_id", "winlog.channel", "winlog.computer_name", "winlog.event_data.TargetUserName", "winlog.event_data.IpAddress"]

Третий уровень: обработка на приёмнике, ingest pipeline в Elasticsearch или extractors в Graylog. Она гибче, но объём уже оплачен: событие доехало до хранилища и только там отброшено. Приёмнику оставляйте то, что требует контекста: обогащение по справочникам, корреляцию, разметку.

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

Отправка в Elasticsearch и OpenSearch

Блок output.elasticsearch разобран выше. hosts принимает список адресов, protocol фиксирует HTTPS, ssl.certificate_authorities указывает CA, которой подписан сертификат приёмника. Пара username и password годится для быстрого старта, в продакшене используйте api_key со строкой формата id:api_key и правами только на запись в нужные индексы. Секреты держите в keystore: winlogbeat keystore create, затем winlogbeat keystore add ES_PASSWORD.

Шаблоны и хранение: при первом запуске Winlogbeat ставит индекс-шаблон. Дальше политику задаёт ILM: hot-фаза на быстрых дисках, warm и cold на медленных, удаление по сроку. В OpenSearch аналог называется ISM. Без политики индексы растут до заполнения диска, и сбор встаёт.

OpenSearch: официальной сертификации с Winlogbeat нет, связка работает при совпадении версий API. Для продакшена надёжнее Vector: его elasticsearch sink проверен с OpenSearch, а Logstash с плагином вывода OpenSearch закрывает сценарии, где нужна промежуточная обработка. Совместимость проверяйте на одном хосте до раскатки.

Отправка в Graylog и Loki

Здесь Winlogbeat упирается в ограничения, и их лучше знать до начала работ.

Graylog: Winlogbeat не умеет отправлять GELF напрямую. Рабочих путей два: поставить между агентом и Graylog Logstash с плагином graylog GELF output, либо заменить агент на Vector с gelf sink. Прямая отправка в Beats-вход Graylog возможна, но зависит от версий и не покрывает все поля Winlogbeat.

Loki: Winlogbeat не поддерживает Loki. Для Windows-хостов берите Vector с sink loki или Grafana Alloy. Promtail снят с поддержки, закладывать его в новые установки не стоит. Помните про кардинальность меток: в метки идут host, job и level, а event_id остаётся в теле записи и фильтруется через LogQL. Метка с идентификатором события порождает тысячи потоков и резко снижает производительность Loki.

Настройка Vector: сбор Event Log и маршрутизация

Vector ставится MSI-пакетом и работает службой. Конфигурация - файл vector.toml, путь по умолчанию задаёт установщик. Минимальный конвейер: source читает каналы, transform чистит и обогащает события, sinks отправляют их в приёмники.

[api]
enabled = true

[sources.win_event]
type = "windows_event_log"
channels = ["Security", "System", "Application", "Microsoft-Windows-Sysmon/Operational"]
read_from = "beginning"
# параметр checkpoint поддерживают актуальные версии, сверьте с вашей
checkpoint_path = "C:\\ProgramData\\Vector\\checkpoints"

[transforms.clean]
type = "remap"
inputs = ["win_event"]
source = '''
.event_id = to_int(.EventID) ?? 0
.severity = to_string(.Level) ?? "info"
if .event_id == 4634 || .event_id == 5156 {
  abort
}
'''

[sinks.es]
type = "elasticsearch"
inputs = ["clean"]
endpoints = ["https://srv-es01.local:9200"]
username = "vector_writer"
password = "${ES_PASSWORD}"
tls.ca_file = "C:/certs/ca.crt"
bulk.index = "winlogbeat-%Y.%m.%d"

[sinks.loki]
type = "loki"
inputs = ["clean"]
endpoint = "http://srv-loki01.local:3100"
labels.host = "{{ host }}"
labels.job = "windows_event_log"
encoding.codec = "json"

Проверка: vector validate с путём к конфигу. Оперативная диагностика: vector top показывает метрики по компонентам, vector tap позволяет увидеть отдельные события на выходе трансформации. Обе команды требуют включённого API (блок [api] в конфиге выше).

Source windows_event_log: каналы и позиционирование

Параметр channels перечисляет журналы. read_from задаёт стартовую позицию при первом запуске: beginning читает журнал с начала и забирает историю, end берёт только новые записи. checkpoint_path сохраняет позицию между перезапусками. Без контрольной точки рестарт опирается на read_from, и возможны пропуски или дубли: при beginning агент перечитает журнал, при end потеряет накопленное за время простоя. Если ваша версия Vector не поддерживает checkpoint для этого source, обновляйте службу в окно низкой нагрузки и следите за размером журналов.

Для каналов с насыщенным EventData проверьте через vector tap, в каком виде приходят поля: структура зависит от версии source, и VRL-правила пишутся под фактические имена.

VRL-трансформации: парсинг, обогащение, фильтрация

VRL выполняет обработку на агенте до отправки, снимая нагрузку с приёмника и уменьшая объём. Типовые задачи: привести EventID к числу, вытащить пользователя и IP, отбросить шум, добавить метки окружения и роли.

[transforms.enrich]
type = "remap"
inputs = ["win_event"]
source = '''
.event_id = to_int(.EventID) ?? 0
.user = to_string(.EventData.TargetUserName) ?? to_string(.EventData.SubjectUserName) ?? "unknown"
.ip = to_string(.EventData.IpAddress) ?? ""
.env = "prod"
.role = "domain-controller"
if .event_id == 4688 {
  .process_name = to_string(.EventData.NewProcessName) ?? ""
}
if .event_id == 4625 {
  .alert = "failed_logon"
}
'''

Проверяйте логику через vector tap на конкретной трансформации: видно, какие поля реально приходят с канала. Пути полей угадывать не стоит, особенно в EventData у разных провайдеров.

Sink в Elasticsearch, OpenSearch, Graylog (GELF) и Loki

Elasticsearch и OpenSearch: sink elasticsearch, endpoints со схемой https, аутентификация username и password или api_key, tls.ca_file для проверки сертификата сервера. Для OpenSearch проверьте bulk API на тестовом конфиге: различия версий видны в ответах на пакетную запись.

Graylog: sink gelf, endpoint вида tcp://graylog.local:12201. Используйте TCP вместо UDP: UDP теряет пакеты при перегрузке, для аудита такие потери недопустимы.

Loki: sink loki, endpoint на порт 3100, метки через labels с шаблонами. В метки идут host, job и level, event_id остаётся в теле записи.

Разветвление потока: один transform питает несколько sinks. Пример: Security и Sysmon уходят в Elasticsearch для SIEM, Application и System идут в Loki для отладки. Такой fan-out настраивается в одном конфиге, без второго агента и промежуточного брокера.

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

Диагностика: почему логи не доходят и как найти задержки

Диагностика идёт по этапам пайплайна, от агента к приёмнику. Так проблема локализуется за минуты, а не перебором гипотез.

1. Служба запущена? Get-Service winlogbeat или Get-Service vector: состояние Running, тип запуска Automatic.
2. Агент читает канал? winlogbeat test output для Winlogbeat, vector top для Vector: метрики source должны расти.
3. Соединение с приёмником: Test-NetConnection srv-es01.local -Port 9200, затем curl -k https://srv-es01.local:9200.
4. TLS: срок сертификата, соответствие имени хоста (SAN), цепочка до CA.
5. Backpressure: растёт очередь или метрика not_acked, значит приёмник не успевает принимать.
6. Задержка: сравните время события и время записи в приёмнике; разница в минуты и часы означает отставание отправки.

Логи самого агента: где смотреть и что искать

Winlogbeat по умолчанию пишет файлы в C:\ProgramData\winlogbeat\logs. Для детальной диагностики включите logging.level: debug на 15-30 минут, снимите симптомы и верните info: на потоке в десятки тысяч событий отладочный режим сам создаёт нагрузку. В журнале ищите строки publish, retry, connection refused, x509.

Vector на Windows не заводит отдельный канал Event Log. Оперативная картина видна в vector top: по каждому компоненту отображаются полученные и отправленные события, ошибки, размер буфера. Если Vector работает агрегатором на Linux, журнал доступен через journalctl -u vector.

Задержки доставки: backpressure, буфер и сеть

Механика задержки простая. Агент читает журнал быстрее, чем приёмник принимает батчи. Очередь растёт, отправка отстаёт на минуты и часы, а при переполнении буфера события теряются или агент перестаёт забирать новые записи из журнала.

Что проверить и настроить:

• Метрики очереди: events_not_acked у Winlogbeat, buffer_events и component_errors_total у Vector. Устойчивый рост означает отставание.
• Батчинг: увеличить размер и интервал батча, чтобы снизить накладные расходы на запросы.
• Фильтрация: убрать 4634 и 5156 на агенте и снизить поток в разы.
• Буфер: у Vector включить дисковый буфер (секция buffer в sink). У Winlogbeat очередь в памяти: при долгой недоступности приёмника записи остаются в Event Log, пока не сработает ротация журнала. Проверьте размер журналов: если Security ограничен 20 МБ, история перезапишется за часы.
• Приёмник: CPU, heap и скорость индексации. Часто узкое место - один индекс на все каналы и отсутствие ILM.

Типовые ошибки и быстрые фиксы

• Access is denied при чтении Security: добавьте учётную запись службы в группу Event Log Readers или выдайте привилегию Manage auditing and security log.
• x509: certificate signed by unknown authority: укажите CA в ssl.certificate_authorities или tls.ca_file, проверьте цепочку и срок сертификата.
• Connection refused или timeout: проверьте порт и firewall на приёмнике, правило между подсетями. Test-NetConnection даёт ответ за секунду.
• Index not found или 403: проверьте права writer-роли, индекс-шаблон и имя индекса в output.
• Дубликаты событий: сброшена позиция чтения. У Winlogbeat проверьте ветку реестра, у Vector - checkpoint-файл. Дубликаты часто возникают после копирования конфигов между хостами.
• Пропуски после рестарта: read_from = end без контрольной точки либо перезапись журнала по размеру.

Если ошибка нетипичная, а текст на английском, разобрать её можно с ИИ-ассистентом. AiTunnel даёт единый API к GPT, Gemini и Claude без VPN и с оплатой в рублях: удобно для перевода сообщений об ошибках и поиска причин по незнакомому коду.

Контроль состояния агента и базовый мониторинг

Агент может работать и при этом ничего не отправлять: приёмник недоступен, кончилось место, журнал повёрнут. Мониторить нужно поток событий, состояние службы - вторичный сигнал.

Метрики Winlogbeat и Vector: что смотреть в первую очередь

Winlogbeat: включите HTTP-эндпоинт через http.enabled: true, http.host: localhost и http.port: 5066. Метрики отдаются в JSON на /stats. Ключевые значения: events_acked (доставлено), events_not_acked (в очереди), pipeline.events.retry (повторы публикации).

Vector: добавьте source internal_metrics и sink prometheus_exporter, направьте метрики в Prometheus.

[sources.internal_metrics]
type = "internal_metrics"
scrape_interval_secs = 15

[sinks.prometheus]
type = "prometheus_exporter"
inputs = ["internal_metrics"]
address = "0.0.0.0:9598"

Минимальный набор метрик Vector: component_received_events_total, component_sent_events_total, component_errors_total, buffer_events. Разница между полученными и отправленными событиями за 5 минут показывает, копится ли поток внутри агента.

Алерты: как узнать, что логи перестали идти

Базовое правило: алерт на остановку потока важнее алерта на падение службы.

- alert: VectorNoEventsSent
  expr: rate(component_sent_events_total[5m]) == 0
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Vector не отправляет события 10 минут"

Для Winlogbeat эндпоинт /stats проверяется через blackbox_exporter (HTTP probe на http://localhost:5066/stats) или коротким PowerShell-скриптом, который сравнивает events_acked с прошлым замером. Службу контролируйте через windows_exporter: состояние службы плюс алерт на stopped. Добавьте проверку места на диске под буфер и индексы.

Безопасность и производительность: как не сломать прод

Канал доставки несёт чувствительные сведения: имена пользователей, IP-адреса, командные строки процессов. Защищайте его как любой административный трафик.

Права учётной записи агента: минимум, который нужен

Чтение Security требует членства в Event Log Readers или привилегии Manage auditing and security log. Остальные каналы читаются с обычными правами. Запускать агент под Domain Admin нельзя: компрометация хоста с таким агентом даёт атакующему лишние возможности. Для отправки используйте сервисную учётку или API-ключ с правом записи только в нужные индексы.

Транспорт: TLS обязателен, mTLS желателен. При mTLS приёмник проверяет клиентский сертификат, и украденный пароль не поможет подключиться с чужой машины. Сертификаты выпускайте внутренним CA с коротким сроком и автоматическим продлением. Пароли держите в keystore или переменных окружения, не в открытом YAML.

Оценка нагрузки: сколько ест агент на реальном сервере

Порядок цифр для планирования. Поток 5 тыс. событий в час: Winlogbeat занимает 50-150 МБ памяти и доли процента CPU. Поток 50 тыс. событий в час на нагруженном контроллере домена: 100-300 МБ памяти и несколько процентов CPU. Vector на тех же объёмах обычно скромнее. При 50+ тыс. событий в час с Sysmon планируйте диск под буфер и полосу сети: узким местом чаще становятся они, а не процессор.

Контроллеры домена проверяйте на пилотном хосте. Аудит создания процессов с командной строкой на DC с высокой нагрузкой заметно расходует CPU, а Sysmon добавляет нагрузку на диск.

Политику хранения продумайте до раскатки: без ILM или retention индексы займут диск за месяцы. Практические конфиги и схемы hot/warm/cold собраны в статье Хранение и ротация логов для production-сред.

Массовое развёртывание и обновление агента

GPO и Ansible: два рабочих подхода

Через групповые политики: положите MSI в сетевую папку, доставьте конфиг через Computer Configuration → Preferences → Windows Settings → Files, установку выполните startup-скриптом (Computer Configuration → Policies → Windows Settings → Scripts → Startup) с командой msiexec /i \\fs01\share\winlogbeat-8.x.msi /qn. Изменения применяются при перезагрузке, для парка из сотен машин это нормальный режим.

Ansible даёт версионирование и точечные раскатки: win_package ставит MSI, win_copy кладёт конфиг, win_template подставляет параметры (роль, окружение), win_service перезапускает службу. Конфиги храните в git: видно, кто и что менял, есть откат. Chocolatey и SCCM/Intune закрывают те же задачи, если уже приняты в инфраструктуре.

Обновление конфигурации без простоя сбора

Оба агента переживают рестарт без потери позиции: Winlogbeat хранит отметку в реестре, Vector - в checkpoint-файле. Порядок безопасного обновления: проверить конфиг (winlogbeat test config, vector validate), раскатать на 2-3 пилотных хоста, убедиться в росте метрик отправки, затем расширять волну. Vector перезагружает конфиг командой vector reload при включённом API, Winlogbeat требует рестарта службы.

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

Итог и чек-лист запуска

Чек-лист, по которому сверяют пайплайн перед раскаткой на весь парк:

1. Агент выбран под приёмник: Winlogbeat для Elastic, Vector для Loki, Graylog, ClickHouse и мульти-выходов.
2. Список каналов зафиксирован: Security, System, Application, Sysmon, PowerShell, RDP, Task Scheduler, Defender.
3. Фильтрация работает на агенте: event_id, level, processors или VRL.
4. Output или sink работают по TLS, права учётной записи минимальны, секреты не лежат в открытом виде.
5. Доставка проверена на пилотной группе: test output, vector top, тестовые события.
6. Метрики и алерты настроены: остановка потока, ошибки, место на диске.
7. Конфиги в git, раскатка через GPO или Ansible, обновления волнами.
8. Политика хранения документирована: ILM, ISM или retention.

Смежные темы: сравнение стеков Elastic, Loki и Graylog, критерии отбора событий, отправка в ClickHouse, хранение и ротация логов. Пайплайн, собранный по чек-листу, даёт главное: события с любой машины доступны для поиска через секунды после записи, а расследование опирается на сохранённые факты.