Graylog на сервере: частые ошибки и решения

MAATRIX

Graylog собирает логи со всей инфраструктуры в одном месте и умеет поднимать тревогу раньше, чем клиент напишет в поддержку. Но на практике сервис часто «стоит», но не работает: сообщения не долетают, индексы краснеют, диск забивается за неделю. Разберём типовые поломки по стеку Graylog — от установки до продакшн-нагрузки — и что с ними делать.

Из чего состоит Graylog и где обычно ломается

Graylog — это не один процесс, а связка из трёх компонентов, и падение любого из них тянет за собой всё остальное:

• Graylog Server — принимает логи через input'ы (GELF, Syslog, Beats), прогоняет их через pipeline rules и extractors, отдаёт веб-интерфейс.
• OpenSearch или Elasticsearch — хранилище и полнотекстовый поиск по логам.
• MongoDB — хранит конфигурацию: input'ы, пользователей, dashboard'ы, правила ретенции. Сами логи в Mongo не попадают.

Если начинаете с нуля, разница между OpenSearch и Elasticsearch по лицензии и совместимости разобрана в статье OpenSearch или Elasticsearch: что выгоднее и когда — для новых установок Graylog в 2026 году практически всегда берут OpenSearch.

Минимальные ресурсы для боевой установки: 4 vCPU, 8 ГБ RAM (комфортно — от 16 ГБ, потому что JVM для OpenSearch и JVM для Graylog едят память отдельно), SSD от 100 ГБ под индексы. На 2 ГБ RAM Graylog запустится, но будет упираться в heap и ронять input'ы под нагрузкой.

Установка через Docker Compose: ошибки первого запуска

Официальный способ развернуть Graylog в 2026 году — Docker Compose с тремя сервисами. Базовый файл:

services:
  mongodb:
    image: mongo:6
    volumes:
      - mongo_data:/data/db
    restart: unless-stopped

  opensearch:
    image: opensearchproject/opensearch:2
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g"
      - "discovery.type=single-node"
      - "DISABLE_SECURITY_PLUGIN=true"
      - "bootstrap.memory_lock=true"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - os_data:/usr/share/opensearch/data
    restart: unless-stopped

  graylog:
    image: graylog/graylog:6.1
    environment:
      - GRAYLOG_PASSWORD_SECRET=замените_на_свою_строку_минимум_16_символов
      - GRAYLOG_ROOT_PASSWORD_SHA2=echo -n Ваш_пароль | sha256sum
      - GRAYLOG_HTTP_EXTERNAL_URI=http://ваш-домен-или-ip:9000/
    entrypoint: /usr/bin/tini -- wait-for-it opensearch:9200 -- /docker-entrypoint.sh
    ports:
      - "9000:9000"
      - "1514:1514/udp"
      - "12201:12201/udp"
    depends_on:
      - mongodb
      - opensearch
    restart: unless-stopped

volumes:
  mongo_data:
  os_data:

Три ошибки, с которыми сталкиваются почти все на первом запуске:

«password_secret must be at least 16 characters». Graylog отказывается стартовать, если GRAYLOG_PASSWORD_SECRET короче 16 символов — это соль для хеширования сессий. Сгенерируйте строку: pwgen -N 1 -s 96 или openssl rand -hex 48.

Веб-интерфейс открывается, но AJAX-запросы падают с CORS-ошибками. Причина почти всегда в GRAYLOG_HTTP_EXTERNAL_URI — если он указывает на localhost, а вы заходите по внешнему IP или домену, браузер получает несовпадающий origin. Значение должно точно соответствовать адресу, по которому реально открывается интерфейс, включая порт и слеш в конце.

OpenSearch падает при старте с «vm.max_map_count [65530] is too low». Стандартная проблема для Elasticsearch-подобных систем — у Linux по умолчанию слишком низкий лимит на mmap. Правится на хосте:

sudo sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf

Если разворачиваете стек с нуля на чистой машине, общая процедура установки Docker описана в статье Установка Docker с нуля — полезно свериться перед тем, как поднимать compose-файл выше.

Индексы OpenSearch/Elasticsearch уходят в red или yellow

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

Status: RED означает, что как минимум один шард недоступен — обычно после нештатной перезагрузки, нехватки диска или единственной ноды, которая не смогла восстановить реплику. В single-node установке (а это большинство Graylog на VPS) red часто возникает из-за того, что индекс создавался с number_of_replicas: 1, а реплицировать физически некуда. Проверить и поправить:

curl -X GET "localhost:9200/_cluster/health?pretty"
curl -X PUT "localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d '
{ "index" : { "number_of_replicas" : 0 } }'

Status: YELLOW на одной ноде — это норма, если у вас нет второй ноды для реплик, беспокоиться не стоит.

Диск заполнен, кластер ушёл в read-only. У OpenSearch и Elasticsearch есть watermark'и на заполнение диска: при 85% кластер перестаёт выделять новые шарды, при 95% индексы принудительно переводятся в read-only — и Graylog начинает терять входящие сообщения. Снять блокировку после освобождения места:

curl -X PUT "localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d '
{ "index.blocks.read_only_allow_delete": null }'

Но это лечение симптома — реальное решение в разделе про ретенцию ниже. Сколько памяти реально требуется под Elasticsearch/OpenSearch в зависимости от объёма индексов, разобрано в статье Сколько RAM нужно для Elasticsearch — логика применима и к OpenSearch, так как это форк с той же архитектурой JVM-heap.

GELF input не принимает сообщения

Настроили input, приложение шлёт логи — а в Graylog тишина. Порядок диагностики:

1. Слушает ли Graylog порт вообще. Внутри контейнера:

docker exec -it graylog netstat -tulnp | grep 12201

Если порта нет — input не запущен или упал. Смотрите Overview → System → Inputs в веб-интерфейсе, там будет причина (например, порт уже занят другим процессом на хосте).

2. Долетает ли пакет до сервера. GELF по UDP — самый популярный вариант для входного трафика, но именно UDP чаще всего режется файрволом или NAT на пути от клиента. Проверка с хоста-отправителя:

echo '{"version":"1.1","host":"test","short_message":"ping from client"}' | nc -u -w1 ваш-graylog-ip 12201

Если сообщение не появилось в Graylog — проблема в сети: проверяйте ufw/iptables на сервере и security group, если сервер в облаке.

3. UDP-буфер ОС слишком мал. При высоком потоке логов ядро Linux начинает молча дропать UDP-пакеты, если буфер приёма меньше, чем нужно под всплеск. Это не ошибка Graylog — она просто никогда не увидит эти сообщения:

sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=26214400

Для продакшна с заметным объёмом логов лучше сразу переключаться на GELF TCP или GELF TCP+TLS — они не теряют сообщения на уровне транспорта, хотя и чуть дороже по накладным расходам.

4. Extractor или Pipeline Rule отбрасывает сообщение молча. Если пакет долетел, но в поиске его нет — проверьте System → Inputs → диагностику input'а, там виден счётчик принятых/отброшенных сообщений, и посмотрите правила pipeline: ошибка в правиле может фильтровать сообщения без явной ошибки в логе.

Диск забивается за пару дней

Логи растут быстро, и без настроенной ретенции индекс-сет съедает весь диск за считаные дни на активном проекте. По умолчанию Graylog создаёт индекс-сет с ротацией по размеру (обычно 20 ГБ на индекс) и хранит ограниченное число индексов — но дефолтные настройки редко подходят под реальный трафик.

Настройка в System → Indices → выбрать индекс-сет:

Пример: если вам нужно хранить логи 30 дней и вы ротируете индексы раз в сутки, max_number_of_indices должен быть не меньше 30 (плюс запас, если задержка обработки бывает всплесками).

Отдельная грабля — старые закрытые индексы, которые никто не удаляет, если стратегия ретенции стоит на Close вместо Delete: они не видны в поиске, но годами занимают место на диске. Общие принципы ротации и хранения логов (применимо не только к Graylog) разобраны в статье Ротация логов, чтобы не забивался диск.

Производительность: лаг сообщений и упавший JVM heap

Graylog показывает в интерфейсе метрику Journal utilization — это буфер на диске между приёмом сообщения и его записью в OpenSearch. Если она растёт и не падает — сервер не успевает индексировать входящий поток.

Основные причины и решения:

• OpenSearch/Elasticsearch не успевает индексировать. Проверьте _cat/thread_pool/write?v — если очередь на запись постоянно заполнена, либо не хватает CPU, либо индексы настроены с избыточным числом шардов на нагрузку. Для single-node установки часто достаточно 1-2 primary shard'а на индекс, а не дефолтные 3-5.
• JVM heap на Graylog Server мал. По умолчанию Graylog берёт немного памяти; под нагрузкой стоит явно задать -Xms2g -Xmx4g через GRAYLOG_SERVER_JAVA_OPTS — но не больше 50% ОЗУ хоста.
• Output buffer processors выставлены слишком консервативно. В System → Overview видно outputbuffer_processor — при постоянной перегрузке имеет смысл увеличить output_batch_size в graylog.conf, но делать это постепенно и проверять память.
• Слишком много extractor'ов с regex на каждое сообщение. Regex-парсинг выполняется синхронно на каждое входящее сообщение — десяток тяжёлых regex на высоком потоке заметно просаживает throughput. Переносите логику в Pipeline Rules со встроенными функциями (grok, key_value) — они быстрее и проще отлаживать.

Если после тюнинга Graylog всё равно упирается в потолок железа — это уже вопрос ресурсов сервера: под серьёзный поток логов с десятков хостов разумно смотреть в сторону выделенного сервера с NVMe вместо VPS с сетевым диском, разница в latency записи ощущается напрямую.

Бэкап и восстановление после сбоя

Данные Graylog живут в двух разных местах, и бэкапить нужно оба:

MongoDB — вся конфигурация (input'ы, dashboard'ы, пользователи, правила):

docker exec mongodb mongodump --archive=/tmp/mongo-backup.gz --gzip
docker cp mongodb:/tmp/mongo-backup.gz ./mongo-backup-$(date +%F).gz

OpenSearch/Elasticsearch — сами логи, через snapshot API в S3-совместимое хранилище или локальный volume. Восстанавливать point-in-time снапшотом надёжнее, чем копировать сырые файлы индекса вручную.

Если вы уже используете Docker volume под данные Graylog, общий подход к бэкапу volume'ов разобран в статье Как установить и настроить бэкап Docker volume на VPS — принципы применимы и к mongo_data/os_data из compose-файла выше.

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