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

MAATRIX

Graylog редко падает от нехватки диска — обычно первым сдаётся именно RAM: OpenSearch начинает выкидывать circuit breaker, message journal на диске растёт бесконтрольно, а веб-интерфейс подвисает на простом поиске. Проблема в том, что Graylog — это не один процесс, а связка из трёх сервисов с разной памятью, и посчитать нужный объём "в лоб" не получится без понимания, кто из них что ест. Разберём по компонентам, дадим ориентиры по объёму логов и покажем, как настроить heap так, чтобы не упереться в OOM на третьей неделе эксплуатации.

Из чего складывается память Graylog

Типичная установка — это три процесса на одном или разных серверах, и каждый требует памяти по-своему:

• Graylog server — сам процесс на JVM, который принимает сообщения (syslog, GELF, Beats и т.д.), прогоняет их через pipeline-правила и extractors, пишет в OpenSearch. Он относительно лёгкий: даже под серьёзной нагрузкой heap в 1-2 ГБ обычно хватает, потому что тяжёлую работу по индексации и поиску делает не он.
• OpenSearch (или Elasticsearch — Graylog поддерживает оба, но с версии 5.x по умолчанию идёт на OpenSearch) — здесь живут сами данные логов в виде индексов Lucene. Это главный потребитель памяти: JVM heap под саму индексацию плюс огромный аппетит к page cache операционной системы для быстрого поиска по сегментам.
• MongoDB — хранит только конфигурацию: стримы, дашборды, пользователей, правила алертов, состояние extractors. Самих логов там нет, поэтому база обычно компактная (сотни мегабайт — единицы гигабайт), и 1-2 ГБ RAM для неё за глаза, если вы не храните там что-то нетипичное.

Ключевой вывод: если считаете память "на Graylog", на самом деле считаете память на OpenSearch плюс небольшую добавку на остальное. Про сам движок хранения логов у нас есть отдельные разборы — сколько RAM нужно для OpenSearch и сколько RAM нужно для Elasticsearch — логика расчёта heap там та же.

Сколько RAM нужно в зависимости от объёма логов

Точных цифр без ваших данных никто не даст — зависит от количества полей в сообщениях, срока хранения (retention), числа реплик и того, сколько источников пишет одновременно. Но для ориентира на однонодовой установке (Graylog + OpenSearch + MongoDB на одном сервере) можно опираться на такие вилки:

Это именно ориентир, не измеренный бенчмарк — у вас цифры почти наверняка съедут в ту или иную сторону. Считайте не по мегабайтам сырых логов, а по объёму после индексации: JSON-логи с десятками полей и большими сообщениями (стектрейсы, полные HTTP-запросы) требуют больше памяти на то же количество событий, чем короткие syslog-строки.

Как настроить Java heap для Graylog и OpenSearch

Главная ошибка новичков — выставить heap "на всю память сервера" и получить OOM Killer, который прибивает процесс, как только к JVM добавляется файловый кэш ОС. Работает правило: heap — не больше 50% физической RAM, а остальное отдаётся операционной системе под page cache, в котором и живёт скорость поиска по Lucene-сегментам.

Heap для Graylog server задаётся в /etc/default/graylog-server (Debian/Ubuntu) или /etc/sysconfig/graylog-server (RHEL/AlmaLinux):

GRAYLOG_SERVER_JAVA_OPTS="-Xms1g -Xmx1g -server -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow"

Для большинства инсталляций 1 ГБ хватает даже при заметном потоке сообщений — Graylog server не хранит данные в памяти подолгу, он их прогоняет через pipeline и отдаёт дальше.

Heap для OpenSearch настраивается через /etc/opensearch/jvm.options.d/heap.options:

-Xms16g
-Xmx16g

Значения Xms и Xmx должны совпадать — это исключает паузы на resize кучи под нагрузкой. Важный нюанс: не поднимайте heap выше ~30-32 ГБ, даже если памяти в сервере много. После этого порога JVM теряет compressed oops (сжатые указатели на объекты), и прирост эффективного heap с 32 до, скажем, 48 ГБ номинала может дать даже худший результат, чем честные 30 ГБ со сжатыми указателями. Если логов действительно много и одна нода не тянет — разумнее не раздувать heap, а добавить вторую data-ноду OpenSearch.

Для MongoDB память под кэш WiredTiger по умолчанию считается как (RAM - 1 ГБ) / 2 — на выделенном под Mongo сервере с 4 ГБ это отдаст под кэш примерно 1.5 ГБ, что с запасом покрывает конфигурационную базу Graylog. Ограничить явно можно параметром в /etc/mongod.conf:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 1

Минимальная рабочая конфигурация: пример на VPS

Если разворачиваете стек через Docker Compose на одном сервере, разумно сразу выставить лимиты памяти по контейнерам, а не полагаться на то, что "как-нибудь само поделится":

services:
  mongodb:
    image: mongo:6.0
    mem_limit: 1200m
    volumes:
      - mongodb_data:/data/db

  opensearch:
    image: opensearchproject/opensearch:2.15.0
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms4g -Xmx4g"
      - "discovery.type=single-node"
      - "DISABLE_SECURITY_PLUGIN=true"
      - "bootstrap.memory_lock=true"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    mem_limit: 8g
    volumes:
      - opensearch_data:/usr/share/opensearch/data

  graylog:
    image: graylog/graylog:6.1
    environment:
      - GRAYLOG_PASSWORD_SECRET=<сгенерируйте: pwgen -N 1 -s 96>
      - GRAYLOG_ROOT_PASSWORD_SHA2=<sha256 от пароля>
      - GRAYLOG_HTTP_EXTERNAL_URI=http://<ip-сервера>:9000/
      - GRAYLOG_ELASTICSEARCH_HOSTS=http://opensearch:9200
      - GRAYLOG_MONGODB_URI=mongodb://mongodb:27017/graylog
    mem_limit: 2g
    ports:
      - "9000:9000"
      - "1514:1514/udp"
      - "12201:12201/udp"
    depends_on:
      - mongodb
      - opensearch

Это конфигурация под сервер с 16 ГБ RAM (4 ГБ heap OpenSearch + запас под page cache, 1.2 ГБ Mongo, 2 ГБ Graylog, остальное — ОС и буферы). Для теста на 8 ГБ снизьте OPENSEARCH_JAVA_OPTS до -Xms2g -Xmx2g и mem_limit OpenSearch до 4g — стек поднимется и будет работать, но на потоке больше пары сотен сообщений в секунду начнёт подтормаживать поиск.

Что съедает память сверх расчёта

Даже при правильно выставленном heap память может утекать по нескольким типовым причинам:

• Реплики индексов на одной ноде. По умолчанию Graylog создаёт index set с одной репликой (replicas: 1). На single-node установке это бессмысленно — реплику некуда класть кроме той же ноды, и она просто удваивает нагрузку на heap и диск без выгоды в отказоустойчивости. В Graylog UI: System → Indices → выбранный Index Set → Edit → Index replicas = 0.
• Слишком много мелких индексов. Если ротация настроена по времени (например, новый индекс каждый час) при небольшом объёме логов, вы получаете десятки мелких сегментов вместо нескольких крупных — каждый требует своих метаданных в heap. Настройте ротацию по размеру (Index rotation strategy → Size-based, обычно 20-30 ГБ на индекс) вместо времени, если объём логов небольшой.
• Message journal на диске. Когда OpenSearch не успевает принимать сообщения, Graylog складывает их в журнал на диске (/var/lib/graylog-server/journal по умолчанию, лимит задаётся message_journal_max_size в graylog.conf). Сам по себе журнал не расходует RAM, но если он растёт — это симптом, что OpenSearch недополучает ресурсов, и вы увидите деградацию по всему стеку, включая page cache для активных индексов.
• Буферы обработки. Параметры ring_size, processbuffer_processors, outputbuffer_processors в graylog.conf определяют размер off-heap буферов и число потоков обработки. На слабом сервере с 2-4 ядрами задирать processbuffer_processors выше числа ядер бессмысленно и добавляет накладные расходы без прироста throughput.

Как проверить, хватает ли памяти

Не гадайте — смотрите метрики. Базовая проверка использования RAM на сервере:

free -h

Состояние JVM heap у OpenSearch:

curl -s http://localhost:9200/_nodes/stats/jvm?pretty | grep -A5 heap_used_percent

Если heap_used_percent регулярно упирается в 85-90% и выше — heap мал для текущей нагрузки, пора либо увеличивать, либо горизонтально масштабировать. Circuit breaker сработает и выдаст ошибку [parent] Data too large, если запрос или индексация требуют больше, чем разрешённая доля heap.

В самом Graylog: раздел System → Overview показывает график использования heap процесса Graylog server и throughput сообщений в секунду, а System → Nodes → выбранный узел — детальную статистику по буферам и journal. Если видите, что journal растёт, а throughput падает — узкое место почти всегда в OpenSearch, а не в самом Graylog.

Признаки, что памяти не хватает критически:

• в логах graylog-server или opensearch появляется java.lang.OutOfMemoryError;
• journalctl -k | grep -i "killed process" показывает, что ядро убило процесс через OOM killer;
• поиск по логам, который раньше занимал секунды, стал занимать десятки секунд или таймаутить.

Если сервер регулярно упирается в память — проще и дешевле нарастить RAM или перенести OpenSearch на отдельный сервер, чем бесконечно тюнить буферы вокруг нехватки ресурсов. Про то, как читать логи и находить первопричину сбоя после того, как стек уже собирает данные, у нас есть отдельный материал — как читать логи и находить причину сбоя.

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