Серверы для SIEM/ELK: расчет дисков и ресурсов под нагрузку

С чего начинаются проблемы у SIEM и ELK на пилоте

Пилот чаще ломается не потому, что SIEM или ELK «плохие», а потому что реальная нагрузка оказывается другой. Перегруз обычно выглядит так: события приходят, но попадают в поиск с задержкой, дашборды начинают тормозить, а часть логов теряется или «догоняет» ночью.

Первый сигнал - растут очереди. Сначала копится буфер на сборе, затем на обработке (парсинг, нормализация), после чего упирается индексатор. Вы видите разрыв между «прилетело» и «стало доступно для поиска». Если разрыв увеличивается, пилот уже едет «в долг».

Чаще всего пилоты проваливаются из-за трех недооценок: реального EPS, сроков хранения и стоимости индексации.

EPS считают «по среднему», забывая про пики: утро понедельника, массовые обновления, инцидент, сканирование. Хранение оценивают как «сырые логи», хотя индекс и служебные данные заметно увеличивают расход диска. Индексацию воспринимают как «просто запись», хотя это еще и анализ полей, создание сегментов, слияния (merge) и кэш.

В типовой схеме почти всегда есть четыре части: сбор (агенты и коллекторы), обработка (пайплайны), поиск и аналитика (индексы и запросы), хранение (диски, реплики, бэкапы). Узким местом может стать любая из них, но первыми чаще сдаются диски и CPU на узлах индексации.

Перед пилотом стоит заранее договориться о базовых вещах: сколько узлов будет принимать и индексировать данные и как разделяются роли; какие диски выдержат непрерывную запись и фоновые операции без провалов; какая схема хранения нужна (горячие данные для быстрого поиска и более дешевое хранение для истории); как переживать отказ диска или узла (репликация, RAID, резервные копии).

Типичный сценарий: пилот в банке стартует с «пары источников», а через неделю добавляют VPN, AD, EDR и сетевые устройства. EPS вырастает в разы, и без запаса серверы начинают отставать по индексации даже при той же суммарной емкости дисков.

Какие входные данные нужны для расчета

Чтобы подобрать инфраструктуру под SIEM/ELK и не упереться в потолок уже на пилоте, сначала соберите несколько цифр. Без них расчет дисков и ресурсов превращается в угадайку.

Минимальный набор входных данных:

• EPS (events per second) по каждому типу источника: сетевые устройства, AD, EDR, серверы приложений, базы.
• Средний размер события (в байтах) и доля «тяжелых» логов (например, Windows Security, прокси, EDR).
• Сроки хранения: сколько дней нужно держать «горячие» данные для поиска и сколько можно убрать в «холодное».
• Нагрузка на поиск и аналитику: сколько пользователей, какие дашборды, как часто запускаются корреляции и отчеты.
• Окно восстановления: сколько времени система может быть недоступна без потерь, и нужен ли прием логов «в очередь».

EPS лучше не брать «с потолка». Его обычно получают одним из трех способов: смотрят статистику текущей SIEM (если она есть), снимают метрики с коллекторов и агентов за 7-14 дней или делают короткий замер на тестовом приемнике (syslog/agent) в часы пик. Важно фиксировать и среднее, и пики: пилоты чаще падают именно на пиковых значениях.

Размер события тоже плавает. Один и тот же источник может писать короткие системные строки и редкие, но очень большие события (ошибки приложений со stack trace, события EDR, DNS/Proxy с множеством полей). Полезно замерить медиану и 95-й процентиль размера.

По срокам хранения заранее определите, что считается «горячим». Частый компромисс - 7-14 дней для быстрого расследования, остальное в более дешевом хранилище. Отдельно уточните требования регулятора и внутренней безопасности.

Пример: в банке пилот стартует с 50 источников и 3 000 EPS в среднем, но в рабочие часы бывают пики до 10 000 EPS. Если SOC держит дашборды открытыми весь день, а корреляции запускаются каждые 5 минут, требования к CPU и быстрым дискам будут выше, чем при редких ручных поисках.

Расчет объема данных: от EPS до терабайт

Чтобы перейти от EPS к понятному объему хранения, начните с базовой оценки:

Объем в сутки = EPS x средний размер события (байт) x 86 400.

Например, 2 000 EPS при среднем размере 500 байт дадут: 2 000 x 500 x 86 400 = 86,4 ГБ в сутки (до учета накладных расходов).

На практике «чистые» байты логов - только начало. Объем растет из-за запаса под всплески, обогащения и накладных расходов самого стека. Проще считать коэффициентами и не пытаться «угадать точную цифру» заранее.

Что чаще всего увеличивает объем:

• пики нагрузки (аварии, сканы, обновления, инциденты);
• рост события после парсинга (добавленные поля, теги, гео, user-agent);
• накладные расходы индекса (структуры для быстрого поиска);
• служебные данные и журналы компонентов (Elasticsearch, Logstash/Beats, ОС).

Сжатие помогает, но на него нельзя опираться как на «идеальные 5 раз». Оно зависит от источников: однотипные события сжимаются хорошо, а разнообразные (audit, EDR, прокси) обычно хуже. Безопаснее считать диапазоном и закладывать консервативное значение.

Отказоустойчивость «съедает» место напрямую. Реплика 1 обычно означает примерно удвоение дискового пространства под данные, реплика 2 - утроение. Плюс нужен запас под переразмещение шардов при падении узла: кластер должен пережить отказ так, чтобы диски не улетели сразу в 90-95%.

Еще несколько вещей, которые часто забывают на пилоте: снапшоты (резервные копии индексов), временные файлы сегментов при слияниях, а также постоянное место под служебные индексы и системные логи. Даже если снапшоты хранятся отдельно, под них все равно нужны окна по времени и ресурсы, поэтому планировать их лучше сразу.

Индексация и поиск: что нагружает серверы сильнее всего

В SIEM/ELK чаще всего ломается не «хранилище как объем», а скорость обработки: данные нужно принять, разобрать, проиндексировать и сделать доступными для поиска почти сразу. Поэтому при выборе серверов важны не только терабайты, но и CPU, RAM и дисковая подсистема.

Индексация нагружает CPU и RAM, потому что Elasticsearch (и похожие движки) постоянно выполняет множество мелких операций: разбирает поля, строит структуры для поиска, пишет сегменты и затем склеивает их (merge). При всплесках событий или активных дашбордах это обычно выглядит как высокая загрузка CPU, рост потребления памяти под кэш и служебные структуры и очередь мелких записей на диске.

«Горячие» данные (последние часы или дни) почти всегда требуют скорости. Здесь IOPS и задержки важнее «чистых» терабайт: медленный диск с большим объемом быстро превращается в бутылочное горлышко, когда одновременно идут запись, merge и поисковые запросы.

Схема hot-warm-cold помогает, когда хранить нужно долго, а запросы к старым данным редкие. На пилоте она часто добавляет лишнюю сложность: появляются дополнительные узлы, правила перемещения индексов и больше мест, где можно ошибиться. Поэтому полезно начинать проще и добавлять уровни хранения, когда вы уже понимаете профиль нагрузки.

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

На производительность чаще всего давят:

• тяжелые запросы: много полей, агрегации, сложные дашборды;
• частые переиндексации и изменения парсинга «на лету»;
• слишком много шардов на узел;
• репликация на медленные диски;
• нехватка IOPS в горячем слое.

Про память: большой объем RAM полезен, но «просто увеличить heap» не всегда спасает. Если отдать слишком много под heap, останется мало места под файловый кэш, и чтений с диска станет больше. Часто правильнее сначала сбалансировать CPU и IOPS, а RAM наращивать уже по реальной картине запросов.

Выбор дисков: скорость, надежность, цена

В SIEM/ELK дисковая подсистема часто становится ограничением раньше, чем CPU. Прием событий идет непрерывно, а индексация и поиск создают много мелких операций. Поэтому важны не только емкость, но и задержки, и IOPS.

Практичная модель - разделить данные на горячие и холодные.

Горячий слой принимает свежие логи, активно индексирует и отвечает на частые запросы. Здесь SSD обязательны, а лучше NVMe: низкая задержка снижает риск роста очередей записи и «захлеба» на пиках.

Холодный слой хранит старые индексы, куда почти не пишут и редко ищут. Там допустимы HDD, если вас устраивает более медленный поиск по архиву.

NVMe часто используют как горячий буфер на 7-30 дней: свежие данные ищутся быстро, а затем по политике хранения индексы переносятся на более дешевый слой. Это дает хороший баланс цены и скорости, особенно когда EPS нестабилен.

RAID выбирайте от задачи: скорость, емкость или выживаемость при отказе диска. Чаще всего встречаются три варианта: RAID 10 (предсказуемые задержки и запись, но половина емкости уходит на зеркалирование), RAID 6 (больше полезной емкости и переживает отказ двух дисков, но запись и восстановление тяжелее), RAID 0 (быстрый, но подходит только для временных буферов, где потеря данных допустима).

Чтобы не упереться в «бутылочное горлышко», проверьте не только тип дисков, но и весь путь записи. Проблемы часто появляются из-за контроллера или HBA, из-за сети между узлами, из-за большого количества шардов и мелких сегментов, а также из-за работы на почти заполненном диске (когда фоновые операции начинают резко просаживать производительность).

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

Серверная схема: узлы и роли без усложнений

Даже если вы подбираете конфигурацию «под пилот», начните со схемы узлов. Частая ошибка - собрать все роли на одном-двух серверах, а потом получать потери событий и задержки в поиске.

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

Минимум узлов, который обычно переживает рост

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

• 3 узла, где роли совмещены (быстро стартовать, но масштабирование сложнее);
• 5 узлов: 3 master (управление кластером) + 2 data (хранение и индексация);
• 6-7 узлов: добавляются 1-2 ingest (прием и парсинг) и при активных дашбордах 1 coordinator (поиск и агрегации).

Master-узлы не должны таскать тяжелые данные. Их задача - стабильность кластера. Data-узлы обычно самые нагруженные: диск, CPU и память под индексацию. Ingest полезен, когда много источников, нормализация, обогащение и нужна очередь приема. Coordinator помогает, когда пользователи активно ищут и строят отчеты, чтобы запросы не «душили» data-узлы.

Сеть: что проверить до закупки

Проблемы с сетью часто маскируются под «не хватает дисков». Перед стартом проверьте фактическую пропускную способность между узлами и до коллекторов логов, задержки и потери пакетов в часы пик, а также то, как разделен трафик приема логов и трафик поиска (хотя бы логически). Полезно сразу иметь запас по портам и коммутации под будущие узлы и понимать, где будет стоять балансировка приема, если источников много.

Отдельный сервер под менеджмент и мониторинг нужен, когда вы не хотите отбирать ресурсы у индексации. Метрики, алерты, бэкапы, обновления и тестовые задачи лучше выносить из кластера.

Пошаговая методика подбора конфигурации

Чтобы система не уперлась в потолок уже на пилоте, считайте конфигурацию от нагрузки и правил хранения, а не от ощущения «примерно хватит». Эту методику обычно реально пройти за 1-2 встречи ИБ и ИТ.

1. Зафиксируйте средний и пиковый EPS по каждому источнику и суммарно.

2. Оцените размер события. Для грубой прикидки часто берут 0,8-1,5 КБ на событие и добавляют запас на обогащение и накладные расходы индекса.

3. Переведите поток в объем хранения: EPS x размер x 86 400. Затем добавьте коэффициент запаса (часто 1,3-2,0), чтобы учесть пики и рост.

4. Разложите хранение по слоям и срокам. Например: 7 дней hot, 30 дней warm, 180 дней cold. Если слои пока не нужны, начните с одного горячего и честно ограничьте срок хранения на пилоте.

5. Учтите реплики и накладные расходы индексов. На практике к «чистым» данным часто добавляют еще +30-50%.

6. Разведите роли узлов. На пилоте особенно опасен один «универсальный» сервер, который одновременно принимает, парсит, индексирует и обслуживает поиск.

7. Сделайте нагрузочный тест. Сымитируйте пиковый EPS хотя бы 1-2 часа и проверьте задержку доставки, скорость индексации, рост очередей. Если видите троттлинг, всплески merge, rejected в threadpool или нехватку памяти под кэш, корректируйте конфигурацию: добавляйте hot-узлы, меняйте диски, пересматривайте сроки хранения и размер шардов.

Типичные ошибки при расчетах и пилотировании

Главная причина провала пилота - не то, что «мало терабайт», а то, что забыли про накладные расходы. Считают только «сырые» логи, а потом диски заканчиваются вдвое быстрее. На объем влияют реплики, служебные индексы, временные сегменты, а также сжатие, которое сильно меняется от типов событий.

Вторая боль - скорость дисков. Места может быть достаточно, но запись не успевает: растет очередь, увеличиваются задержки, появляются дропы, и прием «проседает». Частая причина - попытка хранить горячие индексы на HDD или смешивание записи и тяжелого поиска на одном медленном массиве без запаса по IOPS.

Третья ошибка - «поставим все на один сервер, чтобы попробовать». Для серверов под SIEM/ELK это почти всегда ловушка: пилот быстро превращается в прод, а миграция становится болезненной. Даже если стартуете с одного узла, нужен план, как разносить роли и добавлять узлы без простоя.

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

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

Перед стартом полезно пройти короткую проверку: умножить расчетный объем на реплики и служебные данные и заложить запас; проверить, что диски тянут запись на пике, а не только «по объему»; зафиксировать целевой размер шардов и ротацию индексов; добавить прогноз роста на 6-12 месяцев; описать сценарий бэкапа и приемлемое время восстановления.

Быстрые проверки перед закупкой и запуском

Перед закупкой полезно сделать несколько быстрых проверок. Они часто экономят недели, когда внезапно выясняется, что «в среднем все было нормально», но в пике прием логов отстает на часы.

Подтвердите реальные цифры по событиям: замер EPS и пиков хотя бы за неделю, а лучше за месяц. Важно увидеть не только максимум, но и форму нагрузки: короткие всплески (после обновлений) и длинные периоды повышенного фона (в рабочие часы).

Проверьте емкость с запасом. Elasticsearch растет не только от «сырых» логов: место съедают реплики, снапшоты, служебные данные и накладные расходы индексации. Если планируете 30 дней хранения, посчитайте, что будет при 45, чтобы пережить рост или задержки с расширением.

Практический минимум:

• снять замеры EPS и пиков, зафиксировать топ источников и форматы;
• проверить расчет дисков с учетом реплик, снапшотов и резерва на рост;
• протестировать диски на запись и быстрый поиск по горячим данным на стенде;
• согласовать целевые показатели: задержка приема, время поиска, RPO и RTO;
• продумать расширение без простоя: добавление узлов и дисков по шагам.

Пример: на пилоте в банке все работает при 3-5 тыс. EPS, но раз в неделю SOC запускает тяжелые запросы по инцидентам. На фоне пиков от EDR запись в горячие индексы начинает копиться. Если заранее протестировать сценарий «пик плюс поиск» и заложить запас по IOPS, пилот останется управляемым.

Пример расчета: пилот для банка или госоргана

Возьмем типичный пилот: днем приходит 5 000 EPS, в пиках до 12 000 EPS. Средний размер события - 800 байт (после парсинга может вырасти). Требование по хранению: 30 дней hot, 180 дней cold, реплика 1 (две копии данных), плюс ежедневные снапшоты.

Сколько места нужно

Считаем «сырой» поток: 5 000 EPS x 800 байт = 4 МБ/с. За сутки это примерно 345 ГБ.

Дальше добавляем накладные расходы Elasticsearch (индексы, метаданные, сегменты). Для пилота безопасно заложить коэффициент 1,3-1,5. Возьмем 1,4.

• Hot 30 дней: 345 ГБ/сутки x 30 = 10,4 ТБ сырья. С учетом 1,4: 14,6 ТБ. Реплика 1 удваивает: около 29 ТБ.
• Cold 180 дней: 345 ГБ/сутки x 180 = 62 ТБ сырья. С учетом 1,4: 87 ТБ. С репликой: около 174 ТБ.

Добавьте запас на рост (обычно 20-30%) и служебное место. В такой постановке пилот легко выходит на порядок 250 ТБ «грязной» емкости, если cold тоже хранится в Elasticsearch с репликой.

Снапшоты лучше считать отдельно. При ежедневных копиях обычно нужно отдельное хранилище с запасом под несколько циклов бэкапов и под рост.

Как разнести роли и диски

Чтобы пилот не «поплыл» на пике, прием и обработку логов отделяют от data-узлов. Практичный минимум: отдельные ingest (прием, парсинг, нормализация) и отдельные data (хранение и поиск). Для hot слоя разумны NVMe (низкая задержка на запись и merge), для cold - более емкие диски, а под снапшоты лучше сразу выделить отдельный контур.

На пилоте проверяйте не «красивые графики», а признаки перегруза: очередь на входе (Logstash/ingest) и рост задержки доставки; threadpool bulk/write в Elasticsearch и число rejected; IOPS и задержку диска (особенно в hot); время refresh/merge и рост сегментов; реальную скорость восстановления из снапшота.

Следующие шаги: как перейти от пилота к стабильной системе

Пилот почти всегда живет на допущениях: средний EPS, «примерный» размер события, ожидания по срокам хранения. Чтобы не получить сюрприз через месяц, зафиксируйте допущения в простой таблице и согласуйте ее с владельцами источников и ИБ. Запишите не только цифры, но и правила: какие системы входят в контур, какие исключаются, что считается критичным логом.

Дальше нужен короткий нагрузочный прогон: 2-4 часа, но с пиками, близкими к реальным. По итогам уточняются коэффициенты: средний размер события после парсинга, фактическое сжатие на диске, доля «шумных» источников, скорость индексации и задержки в очередях.

После этого пилот превращается в план роста на 6-12 месяцев. Он должен отвечать на один вопрос: что вы делаете, когда EPS вырастет в 2 раза или появятся новые источники (EDR, AD, сетевые устройства). Обычно это не «замена всего», а добавление узлов и расширение хранения.

Полезно закрепить решения в виде небольшого чеклиста: какие метрики считаются красной зоной (очереди, задержка индексации, заполнение диска, ошибки парсинга); как и когда добавляются узлы (по порогу, по календарю, перед подключением новых систем); где хранится резервная копия и сколько занимает восстановление; кто дежурит 24/7 и какие действия можно выполнять без согласований; как проверяется восстановление (не «бэкап есть», а «мы подняли и открыли поиск»).

Если для проекта важны поставки и поддержка внутри Казахстана, заранее продумайте, кто будет закрывать железо и сопровождение. В таких случаях удобно опираться на локального производителя и интегратора вроде GSE.kz, чтобы конфигурации под нагрузку и план расширения можно было согласовать и повторять без сюрпризов по совместимости и сервису.