MS WEC

✔️ Рекомендуется - Рекомендуемый способ сбора для этого источника событий

Настройка сбора событий с устройств Windows при помощи Агента KUMA (WEC).

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.ru/kuma/4.0/248413

Описание схемы работы

Сбор событий Windows с использованием Windows Event Collector (WEC) позволяет централизованно собирать события с множества устройств Windows в сети. В основе данного способа лежит технология Windows Event Forwarding (WEF), которая обеспечивает передачу событий с источников (рабочие станции и серверы) на центральный сервер-коллектор (WEC). Этот подход упрощает мониторинг и управление событиями в масштабах всей сети, обеспечивая единую точку сбора данных.

Компоненты схемы:

image.png

В данном примере мы рассмотрим вариант Source-initiated subscriptions (режим Push) ввиду того, что этот режим более предпочтителен из-за отсутствия необходимости настройки «прослушивания» входящих соединений службой WinRM на источниках событий.

Подробнее о Windows Event Collector и технологии Windows Event Forwarding:
https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector
https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection

Рекомендации для сервера WEC

  • Один WEC-сервер на 2000-4000 источников событий (хосты Windows)
  • 4-8 CPU и 16 ГБ RAM для обработки событий с 2000-4000 источников, зависит от обширности профиля аудита (при рекомендуемых MS Common ID событий - до 1500 устройств)
  • Для сбора событий с контроллеров домена также использовать схему с WEC-сервером.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/admin-development/configure-eventlog-forwarding-performance

Настройка политики аудита

По умолчанию на устройствах Windows аудит событий не осуществляется.

Рекомендуется настраивать политику аудита Windows, исходя из перечня событий аудита, которые нужны для работы «коробочных» правил корреляции KUMA (например, вход в систему, запуск процессов и т.д.). При необходимости перечень журналируемых событий аудита в дальнейшем можно расширить.

Перечень событий аудита Windows, используемых в "коробочных" правилах корреляции:
https://support.kaspersky.ru/kuma/4.0/250594

Настройка политики аудита на отдельной рабочей станции/сервере

Windows Event Log Powershell

Чтобы настроить аудит событий, связанных с выполнением команд и скриптов в PowerShell на отдельной рабочей станции/сервере:

image28.png

image29.png

image30.png

image31.png

image32.png

image33.png

image34.png

Windows Event Log Security

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

image28.png

image29.png

image.png

image.png

image.png

image.png

При использовании Расширенной политики аудита необходимо включить параметр "Аудит: принудительное переопределение параметров категории политики аудита параметрами подкатегории политики аудита (Windows Visa или более поздние версии) в целях переопределения параметров, указанных в  Политике аудита.

image.png

Дополнительно необходимо включить журналирование команд, выполняемых в командной строке (cmd):

image.png

image37.png

В данном статье не рассматривается настройка аудита событий доступа к объектам (ветки реестра, папки и файлы и т.д.) и событий доступа к службе каталогов.

Windows Event Log System

Дополнительные настройки для журнала System не требуются.

Windows Event Log Defender

Дополнительные настройки для журнала Microsoft-Windows-Windows Defender/Operational не требуются.

Настройка политики аудита для группы рабочих станций/серверов средствами GPO

При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов настройки.

Чтобы настроить политику аудита для группы рабочих станций/серверов средствами GPO:

image38.png

Если предполагается сбор событий с контроллеров домена, в таком случае, контроллеры домена можно не добавлять в созданную группу компьютеров, добавив отдельно в Фильтр безопасности при настройке GPO

image39.png

Windows Event Log Powershell

Чтобы настроить аудит событий, связанных с выполнением команд и скриптов в PowerShell:

image40.png

image31.png

image32.png

image33.png

image41.png

Windows Event Log Security

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

image.png

image.png

image.png

image.png

При использовании Расширенной политики аудита необходимо включить параметр "Аудит: принудительное переопределение параметров категории политики аудита параметрами подкатегории политики аудита (Windows Visa или более поздние версии) в целях переопределения параметров, указанных в  Политике аудита.

image.png

Дополнительно необходимо включить журналирование команд, выполняемых в командной строке (cmd):

image.png

image37.png

В данном статье не рассматривается настройка аудита событий доступа к объектам (ветки реестра, папки и файлы и т.д.) и событий доступа к службе каталогов.

Windows Event Log System

Дополнительные настройки для журнала System не требуются.

Windows Event Log Defender

Дополнительные настройки для журнала Microsoft-Windows-Windows Defender/Operational не требуются.

image44.png

image45.png

image46.png

auditpol.exe /get /category:* | Select-String -Pattern "Успех"

image.png

Настройка WEC-сервера

Настройка службы Windows Event Collector (WEC)

Test-WSMan

Вывод в случае если служба WinRM запущена:

image.png

Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы»,  запустите на WEC-сервере службу WinRM с помощью следующей команды в PowerShell:

winrm qc

При применении команды согласитесь с выполнением изменений. После включения службы WinRM WEC-сервер начнет «прослушивать» соединения на порт TCP/5985 от источников событий.

image.png

Команда winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:

winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен
wecutil qc

При включении службы сборщика событий Windows в Windows Firewall автоматически создается разрешающее правило для входящих соединений по TCP/5985.

Настройка подписки на WEC-сервере

Чтобы настроить подписку на WEC-сервере:

image.png

image51.png

image52.png

В качестве альтернативы вместо группы компьютеров можно добавить необходимые рабочие станции/серверы по отдельности.

Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно добавить как отдельный доменный компьютер

image.png

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-PowerShell/Operational">
    <!-- Windows Event Log Powershell (4103, 4104) -->
    <Select Path="Microsoft-Windows-PowerShell/Operational">*[System[(EventID=4103 or EventID=4104)]]</Select>
  </Query>
  <Query Id="1" Path="Security">
    <!-- Windows Event Log Security -->
    <Select Path="Security">*[System[(EventID=1102 or EventID=4624 or EventID=4625 or EventID=4656 or EventID=4657 or EventID=4663 or EventID=4672 or EventID=4688 or EventID=4697 or EventID=4720 or EventID=4722 or EventID=4723 or EventID=4724 or EventID=4725 or EventID=4726 or EventID=4731 or EventID=4732 or EventID=4733 or EventID=4734 or EventID=4735 or EventID=4738 or EventID=5140 or EventID=5145)]]</Select>
  </Query>
  <Query Id="2" Path="System">
    <!-- Windows Event Log System -->
    <Select Path="System">*[System[(EventID=7036 or EventID=7045)]]</Select>
  </Query>
  <Query Id="3" Path="Microsoft-Windows-Windows Defender/Operational">
    <!-- Windows Event Log Defender -->
    <Select Path="Microsoft-Windows-Windows Defender/Operational">*[System[(EventID=1006 or EventID=1015 or EventID=1116 or EventID=1117 or EventID=5001 or EventID=5010 or EventID=5012 or EventID=5101)]]</Select>
  </Query>
</QueryList>

image54.png

Рекомендации по настройке аудита событий Windows:
https://kb.kuma-community.ru/books/kuma-how-to/page/poleznye-ssylki-po-ib

image55.png

В одну подписку можно добавить не более 22 уникальных Event ID (кодов событий). Если указать больше, то на стороне источников событий (Журналы приложений и служб/Microsoft/Windows/Eventlog-ForwardingPlugin/Operational) появится ошибка "Не удается создать подписку <Наименование подписки>. Код ошибки: 5004.", при этом события от источников перестанут поступать на WEC-сервер.

Поэтому, если стоит задача собирать большое количество разных типов событий, в таком случае создайте несколько подписок, в каждой из которых будет свой уникальный набор Event ID.

Если в подписке не задан фильтр по Event ID, то есть используется значение по умолчанию "<Все коды событий>", ограничение в 22 уникальных Event ID отсутствует и выполняется сбор всех журналируемых событий.

При наличии одинаковых Event ID в разных подписках, события будут дублироваться, как на WEC-сервере, так и в KUMA. Поэтому при создании нескольких подписок проверьте наличие дубликатов Event ID.

image.png

Настройка WinRM и подписки на источниках событий

Для отдельной рабочей станции/сервера

Настройка службы WinRM
Test-WSMan

 Вывод в случае, если служба WinRM запущена:

image.png

Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на рабочей станции/сервере службу WinRM с помощью следующей команды в PowerShell:

winrm qc

При применении команды согласитесь с выполнением изменений, кроме «Служба WinRM не настроена на разрешение удаленного управления компьютером. Разрешите исключение брандмауэра WinRM».

image.png

После включения службы WinRM рабочая станция/сервер начнет «прослушивать» соединения на порт TCP/5985. Для отключения данного listener’а (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента) выполните следующую команду в PowerShell:

Remove-WSManInstance winrm/config/Listener -SelectorSet @{Address="*";Transport="http"}

Команда winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:

winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен

На источнике событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»):

image57.png

Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'

Настройка подписки

Чтобы настроить подписку:

Server=http://<FQDN WEC-сервера>:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) источников событий к WEC-серверу за новыми инструкциями по пересылке журналов.

Microsoft рекомендует настраивать параметр Refresh в зависимости от частоты внесения изменений в подписки. Если подписки изменяются нечасто, для параметра Refresh можно установить значение в несколько часов, например, Refresh=43200 (обновление раз в 12 часов).

Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts


image58.png

image59.png

Restart-Service -Name WinRM

Для группы рабочих станций/серверов средствами GPO

Настройка службы WinRM

При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов.

Чтобы настроить службу WinRM для группы рабочих станций/серверов средствами GPO:

image.png

image.png

image.png

image.png

image.png

image.png

Также на источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»):

При добавлении члена локальной группы введите NETWORK SERVICE и нажмите ОК.

image.png

Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:

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

Test-WSMan

Вывод в случае, если служба WinRM запущена:

image.png

Убедитесь, что WinRS отключен с помощью следующей команды:

winrm get winrm/config | findstr ‘AllowRemoteShellAccess’

image.png

Убедитесь, что порт TCP/5985 не «прослушивается» (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента):

netstat -aon -p TCP  # выполнить в cmd

Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'

Настройка подписки

Чтобы настроить подписку для группы рабочих станций/серверов средствами GPO:

Server=http://<FQDN WEC-сервера>:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) источников событий к серверу за новыми инструкциями по пересылке журналов.

Microsoft рекомендует настраивать параметр Refresh в зависимости от частоты внесения изменений в подписки. Если подписки изменяются нечасто, для параметра Refresh можно установить значение в несколько часов, например, Refresh=43200 (обновление раз в 12 часов).

Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts

image.png

image.png

Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:

Проверка поступления событий

Убедитесь, что на WEC-сервер поступают события с рабочих станций/серверов:

image.png

Для MS Server 2016 и 2019 в случае если события не пересылаются, выполнить шаги по этой инструкции. При добавлении разрешения для URL-адреса с помощью netsh http add urlacl добавьте кавычки "..." в параметре SDDL:
netsh http delete urlacl url=http://+:5985/wsman/ netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)" netsh http delete urlacl url=https://+:5986/wsman/ netsh http add urlacl url=https://+:5986/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"

В случае если события определенного журнала не отправляются с источника событий проверьте на данном источнике в журнале Microsoft/Windows/Event_forwardingPlugin/Operational наличие событий с кодом 5004 (ошибка отправки журналов на WEC-сервер).
При наличии событий с кодом 5004 выполните рекомендации из статьи:
https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/system-management-components/security-event-log-forwarding-fails-error-0x138c-5004

Настройка коллектора и агента KUMA

Создание коллектора KUMA

Для создания коллектора в веб-интерфейсе KUMA:

image70.png

В поле URL можно указать только порт при инсталляции All-in-one.

image71.png

На вкладке Дополнительные параметры для шифрования передаваемых данных между агентом и коллектором выберите Режим TLS - С верификацией.

image72.png

image73.png

image74.png

image75.png

image76.png

image77.png

image78.png

image79.png

Установка коллектора KUMA

Чтобы установить коллектор KUMA:

image80.png

# Пример для firewalld
firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp|udp –permanent
firewall-cmd –reload

# Пример для ufw
ufw allow <порт, выбранный для коллектора>/tcp|udp
ufw reload

image81.png

Создание сервисной учетной записи

Для функционирования агента KUMA предварительно необходимо создать доменную сервисную учетную запись, с помощью которой будет выполняться запуск службы агента KUMA и обеспечиваться доступ к журналам событий, полученных от рабочих станций/серверов Windows (журнал Forwarded Events). 

image82.png

В качестве более безопасной альтернативы обычной пользовательской учетной записи рекомендуется использование управляемой учетной записи службы (MSA). См. Приложение А. Использование Managed Service Accounts (MSA)

Добавление сервисной учетной записи в группу "Читатели журнала событий"

Для доступа агента KUMA к журналу Forwarded Events добавьте созданную сервисную учетную запись в локальную группу Читатели журнала событий на WEC-сервере.

Чтобы добавить учетную запись в локальную группу Читатели журнала событий:

image83.png

image84.png

Назначение прав входа в качестве службы

Разрешите сервисной учетной записи вход в качестве службы (Log on as a service) на WEC-сервере. Это необходимо, чтобы учетная запись могла использоваться для запуска и работы служб (сервисов). В данном случае для запуска и работы службы агента KUMA.

Чтобы разрешить учетной записи вход в качестве службы:

image85.png

image86.png

Дополнительно убедитесь, что соответствующая сервисная учетная запись отсутствует в свойствах политики Отказать во входе в качестве службы.

image87.png

Создание ресурса агента KUMA

Для создания ресурса агента в веб-интерфейсе KUMA:

image88.png

image89.png

image90.png

image91.png

Дополнительные параметры точки назначения (например, Разделитель и режим TLS) должны совпадать с дополнительными параметрами коллектора, с которым вы хотите связать агент.

Точек назначения может быть несколько. Их можно добавить с помощью кнопки Добавить точку назначения.

Публикация агента KUMA

Когда ресурс агента создан, можно перейти к созданию сервиса агента в KUMA.

Чтобы создать сервис агента в веб-интерфейсе KUMA:

image92.png

image93.png

image94.png

Установка агента KUMA

Перед установкой агента KUMA убедитесь, что для WEC-сервера, где предполагается установка, открыты следующие сетевые доступы:

Также убедитесь, что на WEC-сервере, где предполагается установка агента KUMA, «резолвится» DNS-имя сервера KUMA (для распределенной инсталляции DNS-имя сервера Ядра и сервера коллектора KUMA). При необходимости добавьте соответствующие записи в файл hosts на WEC-сервере, либо создайте A-записи на DNS-сервере организации.

Чтобы установить агент KUMA на WEC-сервер:

image95.png

kuma agent --core https://<полное доменное имя сервера ядра KUMA>:<порт, используемый сервером ядра KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса агента, созданного в KUMA> --user <имя пользователя, под которым будет работать агент, включая домен, в формате domain\username> --install

Пример:
kuma agent --core https://kuma.example.com:7210 --id XXXXX --user domain\username –install

image96.png

Если агент устанавливается из-под доменной учетной записи пользователь указывается в формате <домен>\<имя учетной записи>, например, demo\user

kuma.exe license --show

Если вы хотите принять лицензионное соглашение, выполните команду и нажмите y:

kuma.exe license

image97.png

После установки сервис (служба) агента запускается автоматически. Сервис также настроен на перезапуск в случае сбоев. Агент можно перезапустить из веб-интерфейса KUMA, но только когда сервис активен. В противном случае сервис требуется перезапустить вручную на устройстве Windows.

image98.png

Далее перейдите в веб-интерфейс KUMA и убедитесь в успешности запуска агента - статус сервиса агента KUMA WEC должен измениться на ВКЛ с зеленой индикацией. 

image99.png

Чтобы удалить агент KUMA с WEC-сервера по окончании тестирования продукта:

kuma.exe agent --id <идентификатор сервиса агента, созданного в KUMA> --uninstall

Проверка поступления событий Windows в KUMA

image100.png

image101.png

Приложение А. Использование Managed Service Accounts (MSA)

Управляемые учетные записи служб (Managed Service Accounts – MSA) - это специальный тип учетных записей служб в Active Directory (AD), предназначенный для повышения безопасности и упрощения администрирования.

Создаваемая учетная запись службы (MSA) ассоциируется с определенным сервером. Эта учетная запись имеет автоматически генерируемый сложный пароль (120 символов) и поддерживается устройством без ручного вмешательства. Таким образом, MSA обеспечивает безопасный и удобный способ запуска служб на устройствах Windows.

Обычные сервисные учетные записи, которые используются для запуска служб (например, DOMAIN\ServiceAccount) создают административные сложности:

  1. Ручное управление паролями: Администратор должен регулярно вручную менять пароль, а затем обновлять его в настройках службы на всех серверах, где она работает. Это трудоемко и чревато простоями, если пароль не сменить вовремя.

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

  3. Принцип одного сервера: Одна учетная запись не должна использоваться на нескольких серверах одновременно по соображениям безопасности (сложность аудита и отзыва).

Основные особенности MSA:

Типы MSA:

Настройка sMSA

Предварительные требования:

Шаги по настройке:

Действия на контроллере домена

New-ADServiceAccount -Name "Имя sMSA" -Description "Описание учетной записи" -Enabled $true -RestrictToSingleComputer

image.png

$Identity = Get-ADComputer -identity "Имя WEC-сервера"
Add-ADComputerServiceAccount -Identity $identity -ServiceAccount "Имя sMSA"

image.png

Get-ADComputer -Identity "Имя WEC-сервера" -Properties msDS-HostServiceAccount

image.png

После создания учетная запись появится в контейнере Managed Service Accounts вашего домена. Чтобы увидеть его в оснастке "Пользователи и компьютеры Active Directory" (ADUC), необходимо включить просмотр расширенных функций (View -> Advanced Features).

image.png

Действия на WEC-сервере

sMSA должен быть "установлен" на сервере, где он будет использоваться. Это сообщает системе, что данный сервер имеет право использовать эту управляемую учетную запись.

Add-WindowsFeature RSAT-AD-PowerShell

image.png

Install-ADServiceAccount -Identity "Имя_sMSA"
Test-ADServiceAccount -Identity "Имя_sMSA"

Если команда выполняется без ошибок, значит sMSA успешно установлен на сервере. Результат в случае успеха: True

image.png

При установке через Install-ADServiceAccount права Вход в качестве службы (Log on as a service) назначаются автоматически

Add-LocalGroupMember -Group "Event Log Readers" -Member "UserName"

image.png

Оставьте поле User password пустым

image.png

Полезные ссылки

https://techcommunity.microsoft.com/blog/askds/managed-service-accounts-understanding-implementing-best-practices-and-troublesh/397009

Приложение B. Отказоустойчивый сбор событий с WEC-сервером

События на контроллерах домена хранятся очень мало – ротация примерно через 3-5 минут. Поэтому чтобы гарантировать доставку, если по какой-то причине WEС не доступен, предлагается следующая схема:
  • использовать 2 WEC сервера
  • все DC отправляют события не на один, а на 2 WEC сервера (события обоих WEC дублируются)
  • на каждом WEC сервере установлены KUMA Agent
  • оба KUMA Agent отправляют события в ОДИН и тот же коллектор Windows (это важный момент)
  • на коллекторе Windows настраивается агрегация события, чтобы дубли событий с обоих WEC серверов были агрегированы в одно событий
С этим одним событием, прошедшее через такую сложную цепочку и работает KUMA. Это позволит выполнять обслуживание, перезагружать WEC коллекторы (но не одновременно), без потери потока данных с контролеров.
Revision #58
Created 2023-09-29 16:58:58 UTC by Dmitry Borisov
Updated 2026-01-19 08:19:29 UTC by Boris Rzr