А, вот. 100к епс это сколько суммарно по весу в сутки индексов получается?

Если событие 2000 байт, то это 200Мбайт в секунду, или 1.6Гбит/с, то есть нужен 10Гбит интерфейс на устройстве и RAID из SSD.

По мотивам одного красного СИЕМ: 25-30К EPS = 1,2 ТБ сутки при дефолтном сжатии в ES

А причем тут размер индекса и пропускная способность сетевого интерфейса SIEM-кластера?

из тех замеров что я видел 25-30К EPS = 800-900 Мб/с

данные жмутся при передаче

не пытайтесь трафик перегнать в место на диске

Видимо я туплю, но как размер индекса, создаваемого для ускорения поиска данных, связан с пропускной способностью?

при сохранении происходит индексация и появляются доп структуры.

никак

Выдохнул

Я в своем сообщении намекал на то, что EPS не просто так ограничен в лог коллекторах. И тем более в SIEM.
И причины тут приходят из законов физики
- Часто Log collector использует Ethernet интерфейсы 1 Гбит/с, которые не могут слушать трафик быстрее, чем 1 Гбит/с. 1 Гбит/с это 125 мегабайт/с. Поделите на размер транзакции. Если это SYSLOG, то из Cisco ISE я получал размер транзакции больше чем 2500 байт. Его никто не сжимает по пути. То есть даже если это 2500, то из ISE чисто физически влезет 50000 транзакций по 2500 байт. Это если не считать накладных расходов на заголовки транспортного уровня. И это если больше не тратить канал ни на что другое. Для других типов источников: RADIUS серверов, WAF, NGFW IPS, Windows хостов и серверов, EDR, VPN шлюзов, роутеров, свитчей будут другие размеры транзакций и их частота в секунду.
- Бывает, что каждое событие заключено внутрь SSL и внутри сжимается, и это еще и на процессор сервера дает нагрузку. И он может не потянуть генерацию 50000 SSL транзакций в секунду и архивацию каждого. Есть надежда, что несколько событий будут в одном SSL соединении, но слабая.
*Поэтому в мощных лог коллекторах стоят уже 10 Гбит/с интерфейсы, мощные процессоры и диски RAID и SSD не только для надежного хранений, а для быстрой записи. А ведь на сервере еще и другие процессы идут - то же создание индексов в базе данных.
*И при выборе SIEM - вы должны спросить вендора: а вот этот EPS посчитан с шифрованием или без.*

Неспроста для перехода с EPS 30000 на EPS 60000 в Positive SIEM 6.2 применена гибридная схема хранения - индексы пишутся на SSD, как описано в этой статье https://www.ptsecurity.com/ru-ru/about/news/maxpatrol-siem-teper-obrabatyvaet-do-60-000-sobytij-v-sekundu/

900000000/8/30000 = 3750 байт длиной каждое событие.. ммм... а что там за события такие были по 3750 байт? что за источник?

скорее всего в тестах вы упирались в скорость 1 Гбит/с интерфейса, а не возможности процессора или дисков. Подвох любых тестов прозводительности - задержки в сети и ошибки передачи (вызывающие повторную отправку пакета). Если задержки большие, то ваш 1 Гбит или 10 Гбит канал может быть утилизирован лишь на частично..

я выше ответил. они никак не связаны.

вот, например, типовой калькулятор вендора SIEM для подбора размера диска и общего EPS. Он правда кривоват, потому что 240 событий в секунду для NGFW в сети из 500 Windows станций и всего 2 EPS для VPN во времена когда все 500 на удаленке - возможно лишь, когда там журналирование выключено ) Но это хороший пример как считается хранилка для лог коллектора в SIEM. В больших компаниях приходится ставить несколько лог коллекторов.

Есть еще один подвох в SIEM.
* EPS измеренный во время приема событий лог коллектором и EPS который тянет движок корреляции - разные. *
Допустим приходит 5000 событий  в лог коллектор - потом они должны попасть в движок корреляции и затем отобразиться аналитику в самом SIEM. Либо это будет 1 инцидент (DDoS атака), либо это будет 5000 инцидентов. Движок корреляции может успеть обработать за секунду только 4000 событий. А 1000 перенесется на вторую секунду. Но во вторую секунду придет ведь еще 5000 событий.. и тут уже вопрос - что будет делать ваш движок? ) спросите вендора 😉 Возможно он напишет в логе: и еще было каких-то 1000 событий, но мы не успели посмотреть... либо ничего не напишет 😉 И это значит, что реальный максимальный EPS - 4000.

1.2 tb normalized/raw/normalized+raw?

изменения механизмов хранения в новых версиях ES (7.10+) все старые оценки делают неверными)