Сколько RAM нужно для Wazuh

MAATRIX

Wazuh — это не один процесс, а связка из трёх компонентов с разным аппетитом к памяти, и вопрос «сколько RAM нужно» без уточнения «для чего именно» не имеет ответа. Индексер ведёт себя как классический потомок Lucene и требует героического подхода к heap, менеджер прожорлив по-своему в зависимости от числа агентов и потока событий, а дашборд почти не заметен на фоне первых двух. Разберём, из чего складывается память под Wazuh, какие цифры реально закладывать под тест и под прод, и как понять, что стенду стало тесно, до того как это увидят по алертам, которые не дошли.

Из чего состоит Wazuh и кто ест память

Wazuh разворачивается как минимум из трёх сервисов, и в маленьких инсталляциях все три обычно живут на одном сервере («all-in-one»), а в крупных — разъезжаются по разным хостам:

• Wazuh Manager — ядро на базе движка OSSEC: analysisd разбирает и коррелирует события по правилам, remoted держит соединения с агентами, wazuh-db отвечает за состояние агентов и модуль уязвимостей (vulnerability detector), который периодически сверяет установленный софт с базами CVE. Память здесь расходуется на очереди событий и рабочие процессы, а не на хранение исторических данных.
• Wazuh Indexer — форк OpenSearch (который, в свою очередь, форк Elasticsearch), и именно он хранит и индексирует алерты. Это самый прожорливый по RAM компонент — сюда переходит вся родословная требований Lucene: JVM heap, файловый кеш ОС, шарды.
• Wazuh Dashboard — форк Kibana/OpenSearch Dashboards, визуализация поверх индексера. По памяти сравнительно лёгкий.
• Filebeat — мост между менеджером и индексером, пересылает алерты из /var/ossec/logs/alerts/alerts.json в индексер. Потребление скромное, но при большом потоке событий стоит держать его в уме — если индексер не успевает принимать, у filebeat растёт backlog, а не память менеджера.

Ключевой момент для сайзинга: память индексера растёт от объёма и количества индексируемых событий (EPS — events per second), а не напрямую от числа агентов. Пять агентов, которые шлют десятки тысяч событий в секунду при агрессивном FIM-сканировании, нагрузят индексер сильнее, чем пятьсот тихих агентов с редкими алертами.

Сколько нужно для теста и небольшого стенда

Официальный ориентир для оценочной установки (single-node all-in-one, будь то через готовый OVA-образ или Docker-компоуз) — 4 vCPU и 8 ГБ RAM. Это не «хватит впритык», а разумный минимум, при котором все три компонента стартуют и держат небольшую нагрузку без постоянных OOM — для знакомства с интерфейсом, обкатки правил детекции и десятка-другого тестовых агентов этого достаточно.

Ниже этой планки Wazuh, как правило, технически стартует (особенно в Docker, где легко занизить лимиты), но живёт нестабильно: индексер начинает часто уходить в GC-паузы, а под пиковой нагрузкой — падать по OOM killer. Если планируете именно ознакомительный стенд, минимальный конфиг на VPS выглядит так:

# docker-compose.yml — упрощённо, без сертификатов и сетей
services:
  wazuh.manager:
    image: wazuh/wazuh-manager:4.9.0
    mem_limit: 3g

  wazuh.indexer:
    image: wazuh/wazuh-indexer:4.9.0
    environment:
      - OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g
    mem_limit: 4g

  wazuh.dashboard:
    image: wazuh/wazuh-dashboard:4.9.0
    mem_limit: 1g

Суммарно это как раз около 8 ГБ с небольшим запасом под ОС. Для реальной эксплуатации с десятками и сотнями агентов эти цифры нужно пересчитывать — дальше разберём, от чего они зависят.

Таблица ориентиров по агентам и EPS

Точных официальных цифр «на N агентов нужно M гигабайт» в вакууме не существует — Wazuh сам честно указывает, что сайзинг зависит от профиля нагрузки конкретной среды (частота FIM-сканирований, включён ли vulnerability detector, сколько правил срабатывает). Ниже — ориентировочные диапазоны из практики небольших и средних инсталляций, которые стоит проверять на своём EPS, а не принимать как гарантию:

Столбец EPS важнее столбца «агентов» для расчёта индексера: включённый vulnerability detector с частым сканированием, агрессивный FIM (syscheck) по большим директориям или активный SCA (security configuration assessment) может увеличить поток событий в разы без единого нового агента. Прежде чем закладывать сервер под прод, стоит прогнать реальный поток хотя бы неделю на тестовом стенде и посмотреть фактический EPS — так же, как это делают при расчёте векторной базы по реальным данным, а не по табличным прикидкам.

Heap индексера и системные лимиты

Wazuh Indexer наследует те же правила памяти, что и OpenSearch/Elasticsearch, потому что построен на том же движке: JVM heap не должен превышать 50% физической RAM хоста, а оставшуюся половину операционная система использует под файловый кеш для сегментов Lucene. Отдать индексеру heap в 80-90% от RAM — способ гарантированно замедлить поиск по алертам, а не ускорить его: без кеша ОС каждый запрос дашборда будет чаще упираться в диск.

Heap задаётся в /etc/wazuh-indexer/jvm.options (или через переменную OPENSEARCH_JAVA_OPTS в контейнере), и -Xms/-Xmx всегда должны совпадать:

# /etc/wazuh-indexer/jvm.options
-Xms8g
-Xmx8g

Так же, как и в Elasticsearch, действует потолок эффективности heap около 30-31 ГБ из-за перехода JVM на 64-битные указатели после этой отметки — на серверах со 128+ ГБ RAM выгоднее держать heap в районе 30 ГБ и добавлять узлы индексера, чем раздувать один процесс.

Без правки нескольких параметров ядра индексер либо не стартует, либо падает под нагрузкой — это унаследовано от Lucene и требует memory-mapped файлов:

# /etc/sysctl.conf
vm.max_map_count=262144
vm.swappiness=1

sysctl -w vm.max_map_count=262144

Менеджер по heap не настраивается — его память определяется размером очередей и числом рабочих процессов analysisd, которые задаются в /var/ossec/etc/ossec.conf:

<global>
  <white_list>127.0.0.1</white_list>
</global>
<!-- размер очереди событий на анализ -->
<queue_size>131072</queue_size>

Увеличение очереди снижает риск потери событий на пиках, но пропорционально ест RAM менеджера — на слабом сервере лучше не задирать её бездумно «про запас», а смотреть на реальные ошибки переполнения в логах (о них — ниже).

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

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

• Индексер регулярно упирается в heap (heap.percent в _cat/nodes стабильно выше 80-85% вне пиков) — либо добавляйте RAM на том же хосте, либо выносите индексер отдельно, чтобы он не конкурировал за память с менеджером.
• Filebeat копит backlog — алерты доходят до дашборда с задержкой в минуты, а не секунды. Это значит, что индексер не успевает принимать поток на своём текущем железе.
• analysisd не успевает разбирать события — растёт число дропнутых событий в статистике менеджера, при этом CPU уже упирается в потолок. Здесь помогает не RAM, а больше ядер под analysisd (у него есть механизм воркер-пула, масштабируемый числом CPU).
• Число агентов перевалило за пару сотен, а retention алертов — за месяц — это тот порог, где выгоднее перейти на кластер индексера из нескольких узлов (роли cluster_manager/data, как в OpenSearch), а менеджер оставить отдельным хостом или тоже кластеризовать под балансировщиком подключений агентов.

Для комплаенс-сценариев, где Wazuh стоит рядом с VPN-шлюзом и логи агентов дополняют централизованный сбор с сетевого периметра, имеет смысл сразу проектировать раздельные роли — подробнее о такой связке в статье про интеграцию VPN и SIEM для комплаенса.

Как понять, что памяти не хватает, до того как посыплются алерты

Три источника, которые честно показывают давление на память в связке Wazuh, — API индексера, логи менеджера и системный dmesg:

# Давление на heap по узлам индексера
curl -sk -u admin:<password> "https://localhost:9200/_cat/nodes?v&h=name,heap.percent,ram.percent,cpu"

# Сработавшие circuit breaker'ы — индексер сам обрывает операции, чтобы не упасть в OOM
curl -sk -u admin:<password> "https://localhost:9200/_nodes/stats/breaker?pretty"

# Переполнение очереди на стороне менеджера
grep -i "full" /var/ossec/logs/ossec.log | tail -50

# OOM killer на уровне ядра
dmesg -T | grep -i "killed process"

Отдельно стоит следить за размером и ростом backlog filebeat (filebeat.registry и его логи), а также за темпом роста индексов wazuh-alerts-* — если retention настроен на 90 дней, а диск и RAM считались из расчёта на 30, вы упрётесь не сразу, а через пару месяцев, когда старые данные накопятся. Логика мониторинга здесь та же, что и для любой базы с активной записью: показания heap, темп роста индексов и очередей стоит вынести на общий дашборд — подход разобран в статье про мониторинг баз данных через Grafana, источником метрик для Wazuh Indexer выступает тот же принцип экспортёров поверх REST API.

Прежде чем закладывать конкретный объём RAM под сервер, полезно свериться и с более общим правилом запаса памяти для любого сервиса, а не только SIEM — оно описано в статье сколько оперативной памяти закладывать с запасом.

Частые вопросы