Хабр, привет! На связи Виктор Никуличев, руководитель продукта R-Vision SIEM. В этом материале хочу рассказать про один из самых ярких моментов этой весны — и, пожалуй, про самый запоминающийся четверг за последние месяцы.
9 апреля на площадке TAU в Москве состоялась уже четвёртая конференция R-EVOlution Conference 2026. Программа получилась насыщенной: выступления, обсуждения, встречи, много сильных спикеров и партнёров. Но лично для меня одним из главных эпизодов конференции стала зона SIEM Lounge — новый формат для R-EVOlution Conference, который мы впервые реализовали в этом году. Здесь гости могли принять участие в практических воркшопах по расследованию инцидентов, а кто быстрее всех правильно выполнил задание — получил в подарок мерч R-Vision SIEM.
Именно в этой зоне мы и решили провести открытое нагрузочное тестирование R-Vision SIEM в реальном времени: без заранее записанных роликов, без «красивой демки» и без возможности что-то незаметно поправить за кадром. Только живой стенд, реальная нагрузка и метрики на экранах — прямо на глазах у участников конференции.
Смотрелось это, надо сказать, довольно завораживающе. Люди останавливались у больших экранов, всматривались в графики, пытались понять, что именно происходит, задавали вопросы. Со стороны это, наверное, выглядело как какие-то «непонятные дашборды» .
На самом деле за этими экранами стояла вполне конкретная задача: мы в реальном времени показывали, как R-Vision SIEM ведет себя под серьезной нагрузкой.
Что именно мы хотели проверить
Для себя мы поставили цель выйти на 300 тысяч EPS на одной физической машине на разнородном трафике из реальной инфраструктуры и с полным конвейером обработки, включая корреляцию.
Конфигурация у нас была такой:
-
1 master для Kubernetes — 4 vCPU, 8 GB RAM
-
1 воркер — 128 CPU, 54 GB RAM
-
1 нода ClickHouse — два шарда по 32 CPU, 32 GB RAM, 1,5 TB SSD
-
1 отдельная машина с генератором нагрузки, той самой “пушкой”
При этом вся работа коллектора и всей SIEM-системы была сосредоточена на одном воркере.
Почему для нас была важна именно “живая” нагрузка
Отдельно расскажу про генератор нагрузки, потому что это один из самых важных моментов во всей истории.
Когда речь идет о нагрузочном тестировании, очень легко получить красивый, но мало что значащий результат. Достаточно взять слишком удобный, слишком однородный или слишком искусственный поток событий — и цифры будут выглядеть отлично, но к реальной эксплуатации это будет иметь слабое отношение.
Мы пошли другим путем.
Чтобы результаты были максимально приближены к реальности, мы использовали дамп трафика из живой инфраструктуры. Для нас было принципиально важно сохранить разнообразие событий: по типам, форматам, размерам, протоколам отправки. Не менее важно было и то, чтобы в потоке были события, которые действительно участвуют в работе правил корреляции: и проходят через фильтры, и приводят к срабатыванию условий.
Это критично, потому что каждый из этих факторов напрямую влияет на целевой показатель нагрузки.
В нашем наборе источников были:
-
Endpoint
-
VMware vCenter
-
VMware ESXi
-
Linux Auditd
-
KSMG
-
OpenVPN
-
Windows
-
Mikrotik
Фактически “пушка” брала этот живой трафик, масштабировала его до нужного EPS и отправляла на нагрузочный стенд R-Vision SIEM.
А на стороне SIEM в это время шел полный цикл обработки — с нормализацией и полным пакетом правил корреляции для этих источников.
Как мы наблюдали за экспериментом
Чтобы все это не превращалось в “ну вроде графики двигаются, значит все хорошо”, мы собрали отдельные информационные панели (дашборды), которые показывали состояние системы с разных сторон.
Мы выделили четыре основных экрана.
Первый — состояние Kubernetes-кластера:
-
общие метрики кластера,
-
лимиты и запросы,
-
количество запущенных workload’ов (сервисов, подов),
-
состояние нод.
Второй — состояние коллектора:
-
входящий и исходящий EPS,
-
трафик (в байтах) во времени (за прошлое),
-
утилизация ядер по компонентам системы,
-
утилизация ядер по компонентам системы во времени,
-
утилизация ядер и оперативки коллектором.
Третий — состояние worker-ноды:
-
строка обзора ноды: время онлайн, число используемых ядер, объем используемой памяти,
-
объем трафика в сети во времени,
-
процент утилизации ядер и оперативки в worker.
Четвертый — состояние ClickHouse:
-
время онлайн (без падения и перезагрузок),
-
заполненность дисков,
-
топ-10 запросов по частоте использования.
И, конечно, был мастер-дашборд с самой важной информацией в одном окне:
-
входящий и исходящий EPS,
-
утилизация ядер по компонентам систем,
-
EPS во времени (за прошлое),
-
утилизация ядер и оперативки коллектором,
-
утилизация сети.
Именно эти панели и видели участники конференции на больших экранах в SIEM Lounge.
Где оказалось узкое место
На первых прогонах мы довольно быстро увидели, что сам сервер способен стабильно выдавать более 400 тысяч EPS.
Но, как это часто бывает, уперлись не туда, куда изначально смотрели. Узким местом в нашей конфигурации оказался ClickHouse. В текущей схеме он уверенно выдерживал постоянный поток примерно до 360 тысяч EPS.
Поэтому для длительного прогона мы выбрали более безопасный и стабильный режим — 350 тысяч EPS.
После этого вечером в среду оставили стенд работать и, честно говоря, скрестили пальцы: чтобы сеть, инфраструктура и вся обвязка не подвели в течение дня.
Чем все закончилось
В итоге эксперимент завершился безоговорочным успехом. Стенд не просто «отработал», а стал точкой притяжения: к нему постоянно подходили участники, останавливались, обсуждали, задавали вопросы.
За более чем 25 часов непрерывной работы под постоянной нагрузкой не подвело ни одно звено. Система выдержала и запланированные сценарии, и живой интерес аудитории.
Люди следили за метриками, активно взаимодействовали с интерфейсом SIEM, а некоторые даже запускали собственные запросы в базе. Это добавляло нагрузку на ClickHouse и привносило в эксперимент ту самую живость, которую невозможно смоделировать заранее.
И именно в этом была настоящая проверка, и она была пройдена.
В течение дня у нас было две кратковременные просадки по пропускной способности: при тяжелых запросах ClickHouse на несколько секунд снижал скорость примерно до 250 тысяч EPS. Но после этого система быстро восстанавливалась, и поток возвращался к исходной производительности.
Если смотреть на итоговые показатели, то в полном цикле обработки — от сбора до корреляции и записи — R-Vision SIEM показал:
-
среднюю нагрузку за день — 342 тысячи событий в секунду,
-
пики на входе — до 364 тысяч EPS,
-
пиковую запись в БД — в районе 396–402 тысяч EPS.
Последняя цифра может выглядеть неожиданно, но объяснение простое: помимо базовых событий, в результате корреляции появляются дополнительные корреляционные события и события внутреннего аудита SIEM — они тоже записываются в базу. В нашем случае это давало примерно еще до 10% EPS сверху.
Почему для нас это было важно
Для меня ценность этого эксперимента не только в самих цифрах.
Гораздо важнее то, что это был открытый тест вживую. Не лабораторный прогон “для своих”, не аккуратная демонстрация заранее подготовленного кейса, а реальная нагрузка, реальные метрики и реальное поведение системы у всех на виду.
На конференциях обычно показывают презентации, интерфейсы, сценарии использования. Мы решили показать еще и то, как система ведет себя под серьезной нагрузкой. Честно, без ретуши.
И именно поэтому этот четверг мне и запомнится надолго.
ссылка на оригинал статьи https://habr.com/ru/articles/1028522/