Graylog настройка сбора логов: полный гайд с нуля
Содержание статьи
- Подготовка сервера и установка Graylog
- Требования к серверу и выбор версии Graylog
- Установка Elasticsearch и MongoDB для Graylog
- Установка Graylog Server и настройка конфигурации
- Настройка приёма логов через Input
- Создание Input для приёма Syslog-сообщений
- Настройка GELF Input для сбора логов от приложений
- Настройка Beats Input для интеграции с Filebeat
- Настройка источников логов на клиентских машинах
- Настройка отправки логов с Linux через rsyslog
- Настройка отправки логов с Windows через NXLog
- Настройка Filebeat для передачи логов в Graylog
- Обработка и парсинг входящих логов
- Настройка Extractors для разбора Syslog-сообщений
- Настройка Pipeline и правил обработки логов
- Настройка Lookup Tables для обогащения логов
- Поиск, фильтрация и визуализация логов
- Настройка поиска по логам и сохранение запросов
- Создание Streams для разделения логов по источникам
- Настройка Dashboard для визуализации собранных логов
- Оповещения и ротация логов
- Настройка Alert Conditions для уведомлений о событиях
- Настройка Retention и ротации индексов логов
- Проверка работоспособности и устранение ошибок сбора логов
Подготовка сервера и установка Graylog
Перед развертыванием системы централизованного сбора логов необходимо подготовить хост. Платформа требовательна к ресурсам: для индексации сообщений нужен как минимум 4 ГБ ОЗУ и пара ядер CPU. В качестве ОС обычно берут Ubuntu 22.04 LTS или Debian 12.
Установка выполняется в несколько шагов:
- Обновить пакеты:
apt update && apt upgrade. - Прописать репозиторий Elastic (для OpenSearch) и добавить ключ подписи.
- Поставить Java 17 (OpenJDK) — без нее сервис не запустится.
- Установить MongoDB (для метаданных) и OpenSearch (для хранения сообщений).
- Скачать deb-пакет Graylog с официального сайта и выполнить
dpkg -i.
После этого редактируется конфигурационный файл /etc/graylog/server/server.conf: задается password_secret (генерация через pwgen -N 1 -s 96) и хеш пароля администратора. Затем запускаются все три демона, и интерфейс становится доступен на порту 9000.
Требования к серверу и выбор версии Graylog
Прежде чем приступать к развертыванию, стоит оценить ресурсы. Минимальная конфигурация для тестовой среды — 4 ядра CPU, 8 ГБ ОЗУ и 100 ГБ дискового пространства. Для продакшена лучше удвоить эти показатели, особенно если планируется обработка потоков с высокой интенсивностью.
Что касается релизов, актуальная ветка — 5.x. Она получает обновления безопасности и новые функции. Более старые ветки, например 4.x, уже не поддерживаются, поэтому их использование нежелательно. Обратите внимание: в состав дистрибутива входит Elasticsearch, но его версия может отличаться от той, что вы используете в других проектах. Это стоит учесть при планировании архитектуры.
Установка Elasticsearch и MongoDB для Graylog
Перед развертыванием сервера хранения и индексации необходимо подготовить две зависимые службы. Первая отвечает за полнотекстовый поиск и хранение сообщений, вторая — за метаданные, конфигурации и пользовательские сессии.
Для работы с актуальными версиями системы сбора логов рекомендуется использовать Elasticsearch 7.x. Установка выполняется через официальный APT-репозиторий:
- Добавьте ключ и источник пакетов Elastic.
- Обновите индекс пакетов и установите нужную версию.
- Настройте параметры JVM в файле
jvm.options— выделите не менее 2 ГБ оперативной памяти. - В конфигурации
elasticsearch.ymlукажитеcluster.name: graylogиnetwork.host: 127.0.0.1.
Что касается MongoDB, то подойдут версии 4.4 или 5.0. Процесс добавления репозитория аналогичен. После инсталляции обязательно включите сервис в автозагрузку и проверьте статус через systemctl status mongod.
Обе базы данных должны быть доступны только локально — не открывайте порты наружу без необходимости. Это снизит риск несанкционированного доступа к журналам.
Установка Graylog Server и настройка конфигурации
Для развёртывания серверной части потребуется машина минимум с 4 ГБ ОЗУ и 2 ядрами CPU — этого хватит для обработки пары тысяч сообщений в секунду. Ставим компоненты через официальный репозиторий:
- Обновляем пакеты и добавляем ключ репозитория Elastic (для OpenSearch).
- Устанавливаем OpenSearch, задаём пароль администратора и настраиваем single-node кластер.
- Инсталлируем MongoDB — она отвечает за хранение метаданных.
- Ставим сам Graylog Server, прописываем в файле
/etc/graylog/server/server.confхеш пароля (командаpwgen) и секретный ключ.
После правки конфигурации перезапускаем сервис и проверяем порт 9000. Веб-интерфейс должен открыться по адресу http://ваш_сервер:9000. Если страница не грузится, смотрим логи через journalctl -u graylog-server — чаще всего проблема в неверном secret или несовпадении версий компонентов.
Настройка приёма логов через Input
Чтобы система начала принимать данные, нужно создать точку входа. В веб-интерфейсе перейдите в раздел System → Inputs. Нажмите Select input и выберите подходящий тип — например, Syslog UDP или GELF TCP. Укажите порт, присвойте название и нажмите Launch input. После этого трафик начнёт поступать.
Создание Input для приёма Syslog-сообщений
Чтобы начать принимать данные по протоколу Syslog, в веб-интерфейсе перейдите в раздел System → Inputs. Нажмите кнопку Launch new input и выберите тип Syslog UDP или Syslog TCP — выбор зависит от того, какой транспорт используется на ваших источниках.
В открывшейся форме укажите порт (по умолчанию 514) и присвойте узлу понятное имя, например syslog-router. Обязательно отметьте опцию Store full message, чтобы сохранять исходный текст сообщения целиком. После сохранения input сразу начнёт слушать указанный порт — это удобно проверять командой netstat -ulpn на сервере.
Для распределённой инфраструктуры имеет смысл создать несколько входов с разными портами под разные группы устройств. Так проще управлять правами доступа и ротацией данных в дальнейшем.
Настройка GELF Input для сбора логов от приложений
Когда речь заходит о graylog настройка сбора логов с микросервисов или самописных утилит, стандартные системные источники часто не подходят. На помощь приходит протокол GELF — он избавляет от необходимости парсить неструктурированный текст на стороне сервера.
Чтобы создать точку приёма данных, перейдите в раздел System → Inputs. Нажмите кнопку Select input и выберите тип GELF UDP (или TCP, если важна гарантия доставки). Заполните поля:
- Title — понятное имя, например, «app-backend»;
- Bind address — IP-адрес интерфейса, на котором будет слушать порт;
- Port — стандартный 12201 или любой свободный.
После запуска входа проверьте его работоспособность командой:
echo '{"short_message":"test","host":"example.org","facility":"test"}' | nc -u -w1 localhost 12201
Если сообщение появилось в поиске — всё функционирует корректно. Для продакшена стоит настроить TLS и аутентификацию, но это уже тема отдельного разговора.
Настройка Beats Input для интеграции с Filebeat
Чтобы сервер принимал события от Filebeat, в веб-интерфейсе перейдите в раздел System → Inputs. Нажмите «Select input» и выберите тип Beats. Укажите порт (по умолчанию 5044), присвойте узлу понятное имя и сохраните конфигурацию. После этого запустите обработчик — он начнёт слушать входящие соединения.
На стороне агента в файле filebeat.yml пропишите адрес и порт вашего сервера в блоке output.logstash или output.elasticsearch — в зависимости от того, какой протокол используете. Для проверки соединения отправьте тестовое сообщение и посмотрите логи на вкладке «Show received messages».
Настройка источников логов на клиентских машинах
Чтобы сервер начал принимать данные, на каждом хосте нужно установить и сконфигурировать сборщик. Для Linux-систем чаще всего выбирают Filebeat или syslog-ng, для Windows — Winlogbeat. После установки укажите адрес сервера и порт приёма, а также формат сообщений. Ниже — типовой порядок действий.
- Установите агент (например, через пакетный менеджер).
- Пропишите путь к лог-файлам или тип источника.
- Задайте адрес назначения и протокол (UDP/TCP).
- Перезапустите службу и проверьте статус.
Для проверки соединения используйте команду netstat или тестовую отправку сообщения. Если данные не появляются, проверьте сетевые фильтры и доступность порта.
Настройка отправки логов с Linux через rsyslog
Для передачи данных на сервер с Linux-машин чаще всего задействуют rsyslog. Пропишите в конфигурации /etc/rsyslog.conf строку вида *.* @192.168.1.10:1514 — это направит поток по UDP. Для TCP используйте два символа @@. После правок перезапустите службу: systemctl restart rsyslog. Убедиться, что пакеты уходят, можно командой tcpdump -i eth0 port 1514.
Настройка отправки логов с Windows через NXLog
Для передачи событий с машин под управлением Windows в сервер сбора данных часто применяют NXLog. Это легковесный агент, который умеет читать журналы приложений, системный журнал и журнал безопасности. Конфигурация сводится к указанию источника (например, eventlog) и адреса приёмника с протоколом GELF или TCP.
Пример минимальной настройки для пересылки в Graylog:
- Укажите модуль ввода:
Input eventlog. - Задайте формат вывода:
Output gelf. - Пропишите хост и порт сервера (обычно 12201).
После перезапуска службы агент начнёт передавать данные. Проверить поток можно в интерфейсе поиска, отфильтровав сообщения по имени хоста.
Настройка Filebeat для передачи логов в Graylog
Для доставки данных в Graylog чаще всего применяется Filebeat — лёгкий агент от Elastic. Он читает файлы и отправляет события напрямую на нужный порт. В конфигурации указывается путь к журналу и адрес приёмника. Ниже — базовый пример для одного источника.
filebeat.inputs:
- type: log
paths:
- /var/log/nginx/access.log
output.logstash:
hosts: ["graylog.example.com:5044"]
После правки конфига службу перезапускают. Если данные не появляются, проверяют доступность порта и формат сообщений.
Обработка и парсинг входящих логов
Сырые сообщения, попадающие в систему, редко бывают удобоваримыми. Чтобы извлечь из них пользу, потребуется настроить извлечение полей. Механизм extractors позволяет вытаскивать нужные атрибуты из текста, а pipeline — выполнять цепочки преобразований: нормализацию, обогащение, фильтрацию. Для типовых задач удобно использовать готовые правила, например, для разбора JSON или Apache-форматов. Важно помнить: чем раньше вы структурируете данные, тем проще будет строить поисковые запросы и графики в дальнейшем.
Настройка Extractors для разбора Syslog-сообщений
Когда поток данных уже поступает в систему, сырые строки выглядят малопригодными для анализа. На этом этапе подключаются экстракторы — механизм, который вычленяет нужные поля из неструктурированного текста. Работа строится на регулярных выражениях или правилах подстановки.
Для типового syslog-трафика удобно использовать встроенный пресет, который автоматически распознаёт стандартный формат RFC 3164. Если же формат нестандартный, придётся создавать правила вручную. Последовательность действий такая:
- Открыть сообщение в разделе Search и перейти к панели извлечения данных.
- Выбрать подстроку, которую нужно превратить в поле (например, IP-адрес источника).
- Указать тип экстрактора — обычно это регулярное выражение или JSON.
- Задать имя нового поля и проверить результат на тестовой выборке.
Важно помнить: экстракторы применяются только к вновь поступающим записям. Для обработки уже сохранённых данных потребуется переиндексация или повторная отправка. Также стоит группировать правила по типам источников, чтобы не создавать кашу из полей с одинаковыми именами.
Настройка Pipeline и правил обработки логов
Когда поток данных налажен, самое время заняться обогащением и маршрутизацией сообщений. В Graylog эта задача решается через конвейеры (pipeline) — цепочки правил, которые применяются к входящим записям.
Создание цепочки начинается с раздела System → Pipelines. Там добавляется новый конвейер, после чего к нему привязываются правила. Логика работы проста: каждое правило содержит условия (например, has_field или contains) и набор действий — извлечение полей, перезапись значений, удаление лишнего или отправка в нужный стрим.
Для типовых задач удобно использовать готовые функции из библиотеки Graylog, но часто приходится писать собственные выражения. Вот пара примеров, которые пригодятся на старте:
- Извлечение IP-адреса клиента из строки лога через регулярное выражение.
- Добавление поля с уровнем критичности на основе кода HTTP-ответа.
Важно помнить о порядке: правила выполняются последовательно, поэтому сначала стоит нормализовать данные, а уже потом применять фильтры и обогащение. После сохранения изменений конвейер нужно активировать — без этого он не начнёт обрабатывать трафик.
Настройка Lookup Tables для обогащения логов
Обогащение данных в сервисе выполняется через справочники. Они подключаются к полям сообщений и подставляют дополнительные атрибуты — например, имя хоста по IP-адресу или уровень критичности по коду события.
Процесс настройки включает несколько шагов:
- Создание источника данных (файл CSV, база данных или HTTP-запрос).
- Определение структуры кэша и времени жизни записей.
- Привязка справочника к нужному полю в конвейере обработки.
Важно помнить: при использовании внешних источников стоит настроить периодическое обновление, чтобы данные не устаревали. Для проверки работы механизма удобно применять встроенную функцию тестирования в интерфейсе.
Поиск, фильтрация и визуализация логов
Когда данные накоплены, встаёт вопрос их осмысления. Интерфейс поиска в Graylog позволяет строить запросы по синтаксису Lucene, комбинируя поля, временные диапазоны и операторы. Для быстрого отсечения лишнего удобно использовать фильтры по хосту, уровню или приложению — они применяются мгновенно, без перезагрузки страницы.
Визуальная часть представлена дашбордами, где каждый виджет настраивается под конкретную метрику. Например, можно вывести график количества ошибок за сутки или таблицу с топ-10 сообщений. Полезной функцией считается сохранение поискового запроса — к нему возвращаются в один клик, а также возможность поделиться ссылкой с коллегой.
Для углублённого анализа предусмотрены агрегации по полям и создание пользовательских представлений. Это помогает выявлять корреляции между событиями, не прибегая к экспорту данных во внешние инструменты.
Настройка поиска по логам и сохранение запросов
Поисковая строка в интерфейсе принимает синтаксис Lucene. Для быстрого доступа к часто используемым фильтрам их сохраняют: кнопка Save рядом с полем запроса. Удобно группировать такие шаблоны по папкам, назначая понятные имена. Полезно также настроить горячие клавиши для переключения между вкладками поиска.
Создание Streams для разделения логов по источникам
Когда серверов несколько, удобно развести потоки по разным «рукавам». В Graylog это делается через Streams — правила маршрутизации, которые фильтруют входящие сообщения по заданным условиям. Например, можно отделить записи от nginx, PostgreSQL и системного журнала.
Алгоритм действий:
- Перейдите в раздел Streams → Create Stream.
- Задайте имя и описание, сохраните.
- Настройте правило: Manage Rules → Add Stream Rule. Укажите поле (например, source), оператор (match regular expression) и значение (типа nginx).
- Вернитесь в список и нажмите Start Stream.
После этого все сообщения, подходящие под условие, будут автоматически попадать в созданный поток. Для удобства можно добавить несколько правил с логикой AND/OR — так фильтрация станет точнее.
Настройка Dashboard для визуализации собранных логов
Когда поток событий уже поступает в систему, возникает задача наглядного представления данных. Панель мониторинга позволяет вывести ключевые метрики на один экран, не прибегая к постоянному ручному поиску по сообщениям.
Для создания рабочей области перейдите в раздел Dashboards и нажмите Create new dashboard. После этого добавьте виджеты, используя сохранённые поисковые запросы или построив агрегацию с нуля. Удобно комбинировать разные типы визуализации:
- графики для отслеживания динамики количества ошибок по времени;
- круговые диаграммы для распределения источников;
- таблицы для детализации по хостам или уровням критичности.
Каждый виджет настраивается под конкретную задачу: можно задать интервал обновления, выбрать поле для группировки и задать пороговые значения. Готовую панель легко расшарить с коллегами через ссылку или встроить во внутренний портал.
Оповещения и ротация логов
Чтобы вовремя замечать сбои, настройте алерты на основе пороговых значений. Например, уведомление о росте 5xx-ошибок за минуту. Для хранения данных используйте retention-политики: индекс за сутки, закрытие через 30 дней, удаление — через 90. Это сбалансирует нагрузку на диск и сохранит нужную глубину истории.
Настройка Alert Conditions для уведомлений о событиях
Чтобы не пропустить критичные инциденты, настройте оповещения. В интерфейсе перейдите в раздел Alerts, создайте новое условие и укажите порог срабатывания, например, количество ошибок за минуту. Действия выполняются через Event Definitions — там выбирается тип уведомления (email, HTTP-запрос). Для гибкости используйте скрипты на Graylog API.
Настройка Retention и ротации индексов логов
Чтобы хранилище не переполнялось, задают политику жизненного цикла данных. В Graylog это реализуется через настройки ротации и retention для каждого индекса. Ротация определяет момент создания нового индекса (по размеру или времени), а retention — правила удаления старых сегментов.
Рекомендуется следующая последовательность действий:
- Перейти в раздел System → Indices.
- Выбрать нужную индексную модель или создать новую.
- Указать стратегию ротации: по достижении определённого объёма (например, 20 ГБ) или по количеству дней (например, каждый день).
- Настроить retention: задать максимальное количество индексов для хранения или срок их жизни.
Для типовой инфраструктуры подойдут такие параметры:
| Параметр | Значение |
|---|---|
| Ротация по размеру | 10–30 ГБ |
| Ротация по времени | 1–7 дней |
| Retention (кол-во индексов) | 14–30 |
После изменения параметров система автоматически применит их к новым сегментам. Старые данные будут удалены фоновым процессом без участия администратора.
Проверка работоспособности и устранение ошибок сбора логов
После внесения изменений в конфигурацию проверьте, что данные действительно доходят до сервера. Откройте раздел Search и выполните запрос по имени вашего инпута. Если сообщений нет, осмотрите логи самого сервиса — обычно они лежат в /var/log/graylog-server/. Обратите внимание на ошибки, связанные с буферизацией или недоступностью Elasticsearch.
Распространённые неполадки и способы их решения:
- Неверный порт или адрес в настройках источника — сверьте параметры с фактическими данными.
- Проблемы с TLS-сертификатами при передаче по защищённому каналу.
- Переполнение очереди на стороне отправителя — увеличьте таймауты.
Для диагностики удобно использовать команду curl, отправляя тестовое сообщение прямо в инпут. Так вы быстро поймёте, на каком этапе теряются данные.