Когда серверов в инфраструктуре становится больше одного, а сервисов на каждом ещё штук десять, логи превращаются в стихию. SSH-сессии для просмотра /var/log на каждой машине, grep по гигабайтным файлам, попытки сопоставить временные метки между разными источниками. Знакомая картина для многих администраторов, и она быстро доводит до белого каления. Когда что-то ломается, время уходит не на починку, а на поиск причины среди разрозненных логов. Именно здесь на сцену выходит централизованный сбор и анализ логов.
Graylog решает эту проблему по-взрослому. Все логи стекаются в одно место, индексируются, становятся доступны для поиска через единый веб-интерфейс. Можно строить дашборды, настраивать оповещения по триггерам, искать по сложным условиям с фильтрами. Под капотом работает связка из проверенных инструментов. Elasticsearch отвечает за хранение и быстрый поиск по индексам, MongoDB держит метаданные и настройки самого Graylog, а Nginx прячет всю кухню за удобным фронтендом на привычном HTTP-порту.
Дальше пойдёт пошаговый разбор того, как собрать этот стек на свежей Ubuntu 22.04. Будут разобраны нюансы каждого компонента, разъяснены параметры конфигов и показаны типичные грабли, на которые наступают новички при первом знакомстве с системой.
Подготовка операционной системы и установка пакетов для работы с репозиториями сторонних производителей
Перед тем как ставить такую массивную систему, как Graylog с его зависимостями, имеет смысл привести Ubuntu в актуальное состояние. Старые версии пакетов могут конфликтовать с тем, что будет устанавливаться позже, а пропущенные обновления безопасности это вообще отдельный разговор. Серверу нужно минимум 4 гигабайта оперативной памяти, потому что один только Elasticsearch с радостью съест половину этого объёма, а на остальных компонентов и саму систему останется не так уж много.
apt update -y
apt upgrade
Первая команда перечитывает списки пакетов из всех настроенных репозиториев. Это лёгкая операция, которая не меняет ничего в системе, только обновляет локальный кеш информации о доступных версиях. Вторая команда уже выполняет реальное обновление пакетов до свежих версий. Без флага -y во второй команде apt спросит подтверждение перед началом работы, что разумно при ручном администрировании, чтобы оценить масштаб изменений.
После обновления приходит время поставить набор вспомогательных утилит, которые понадобятся на разных этапах установки. Каждый пакет здесь имеет конкретное назначение.
apt install apt-transport-https gnupg2 uuid-runtime pwgen curl dirmngr -y
Пакет apt-transport-https позволяет менеджеру пакетов работать с репозиториями, доступными только по HTTPS, что для современных проектов давно стало нормой. Утилита gnupg2 управляет криптографическими ключами, которыми подписаны репозитории сторонних разработчиков. Без правильно установленных ключей apt откажется доверять пакетам и завалит установку с ошибкой проверки подписи. Инструмент uuid-runtime генерирует уникальные идентификаторы, которые пригодятся при настройке узлов кластера. Генератор паролей pwgen ещё сыграет свою роль при создании секретного ключа для Graylog. Утилита curl нужна для скачивания файлов и проверки HTTP-эндпоинтов. Помощник dirmngr работает в паре с gnupg для управления ключами через серверы ключей.
Развёртывание Java-окружения как основы для работы Graylog и Elasticsearch на одном сервере
И Graylog, и Elasticsearch написаны на Java, что одновременно благословение и проклятие. Благословение, потому что Java даёт прекрасную портируемость, развитую экосистему и проверенные годами runtime-возможности. Проклятие, потому что JVM прожорлива по памяти, и на слабом сервере связка из двух Java-приложений быстро превратит работу в мучение. Хорошая новость в том, что нужный пакет уже есть в стандартных репозиториях Ubuntu, и установка занимает секунды.
apt install openjdk-11-jre-headless -y
Стоит разобрать имя пакета по частям, потому что в нём зашита важная информация. Префикс openjdk означает свободную реализацию Java, а не проприетарную версию от Oracle. Число 11 это LTS-версия Java, которую Graylog поддерживает официально. Часть jre обозначает Runtime Environment, то есть только окружение для запуска готовых Java-программ без инструментов разработки. Слово headless указывает на то, что в пакете нет графических библиотек, которые на серверной машине совершенно бесполезны. Они только занимают место и тянут лишние зависимости.
После установки полезно убедиться, что Java действительно встала и доступна из командной строки.
java -version
Корректно установленная Java отрапортует о своей версии примерно так.
openjdk version "11.0.16" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)
Здесь видна и точная версия с патч-уровнем, и тип сборки, и архитектура виртуальной машины. Параметр "mixed mode" говорит о том, что JVM может работать в смешанном режиме интерпретации и JIT-компиляции, выбирая оптимальный вариант для каждого участка кода. Это стандартное поведение, которое даёт хорошую производительность для длительно работающих приложений вроде Elasticsearch.
Подключение официального репозитория Elasticsearch и настройка кластера для хранения индексированных логов
Elasticsearch занимает центральное место в архитектуре Graylog. Именно туда складываются и индексируются все логи, и именно через него выполняется поиск. В стандартных репозиториях Ubuntu Elasticsearch не лежит по понятным причинам. Это сторонний продукт со своим циклом релизов, и вендор сам поддерживает официальный репозиторий для актуальных версий. Подключение чужого репозитория всегда начинается с импорта GPG-ключа, который удостоверяет подлинность пакетов.
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -
Команда скачивает публичный ключ Elastic с их официального сайта и сразу же передаёт его в apt-key для добавления в систему. Флаг -q включает тихий режим wget без прогресс-баров, а параметр -O с дефисом отправляет вывод в стандартный поток вместо файла. Эта конвейерная конструкция стала классикой для подключения внешних репозиториев.
Следом добавляется сама запись о репозитории в список источников apt.
echo "deb https://artifacts.elastic.co/packages/oss-7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
Обратите внимание на ключевое слово oss в URL. Это open-source версия Elasticsearch без коммерческих компонентов вроде X-Pack. Для работы с Graylog она подходит идеально и не накладывает лицензионных ограничений. Версия 7.x выбрана не случайно. Graylog 4.3 совместим именно с этой линейкой Elasticsearch, а на более новых версиях работать откажется или будет вести себя странно.
После добавления репозитория нужно обновить кеш пакетов и установить Elasticsearch.
apt update -y
apt install elasticsearch-oss -y
Готовый к работе Elasticsearch требует минимальной настройки перед первым запуском. Главное это задать имя кластера и отключить автоматическое создание индексов, потому что Graylog предпочитает контролировать этот процесс сам.
nano /etc/elasticsearch/elasticsearch.yml
В открытый файл нужно добавить или раскомментировать две строки.
cluster.name: graylog
action.auto_create_index: false
Имя кластера может быть любым осмысленным, но соглашение называть его graylog в этой связке стало де-факто стандартом. Отключение auto_create_index критически важно. Если оставить эту опцию включённой, Elasticsearch начнёт создавать индексы по любому первому обращению, что мешает Graylog управлять схемой данных правильным образом.
После сохранения конфигурации можно запускать сервис и настраивать его автостарт.
systemctl daemon-reload
systemctl start elasticsearch
systemctl enable elasticsearch
Команда daemon-reload перечитывает unit-файлы systemd, что нужно делать после изменения конфигов служб. Запуск самого Elasticsearch занимает обычно от десяти до тридцати секунд, в зависимости от мощности сервера. Java-машина прогревается медленно, особенно при первом старте.
Проверка статуса сервиса покажет, всё ли в порядке.
systemctl status elasticsearch
Ожидаемый вывод выглядит примерно так.
? elasticsearch.service - Elasticsearch
Loaded: loaded (/lib/systemd/system/elasticsearch.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2022-09-25 07:05:27 UTC; 21s ago
Docs: https://www.elastic.co
Main PID: 74226 (java)
Tasks: 48 (limit: 4579)
Memory: 1.2G
CPU: 22.739s
CGroup: /system.slice/elasticsearch.service
??74226 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.t>
Sep 25 07:05:11 ubuntu2204 systemd[1]: Starting Elasticsearch...
Sep 25 07:05:27 ubuntu2204 systemd[1]: Started Elasticsearch.
Строка active running это то, что нужно увидеть. Расход памяти около 1.2 гигабайт сразу после старта подтверждает прожорливость Java-приложений. Окончательную проверку работоспособности проводят запросом к HTTP-API Elasticsearch.
curl -X GET http://localhost:9200
Здоровый Elasticsearch отвечает на корневой запрос подробной информацией о своей версии и кластере.
{
"name" : "ubuntu2204",
"cluster_name" : "graylog",
"cluster_uuid" : "6IWBEBx_THa2Gzqb7a1LTQ",
"version" : {
"number" : "7.10.2",
"build_flavor" : "oss",
"build_type" : "deb",
"build_hash" : "747e1cc71def077253878a59143c1f785afa92b9",
"build_date" : "2021-01-13T00:42:12.435326Z",
"build_snapshot" : false,
"lucene_version" : "8.7.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
Имя кластера graylog в ответе подтверждает, что настройки применились. Шуточный слоган "You Know, for Search" завершает ответ. Эта деталь стала визитной карточкой Elasticsearch и отсылает к тому, что движок построен на библиотеке Lucene, заточенной под полнотекстовый поиск.
Установка базы MongoDB для хранения метаданных и конфигурации Graylog
MongoDB в архитектуре Graylog играет вспомогательную, но критическую роль. Сами логи туда не пишутся, для этого есть Elasticsearch. Зато все настройки системы, пользователи, права доступа, конфигурации источников логов, описания дашбордов, правила оповещений хранятся именно в MongoDB. Без неё Graylog запустится, но работать не сможет, потому что не сумеет прочитать или сохранить ни одну настройку.
Как и Elasticsearch, MongoDB не входит в стандартные репозитории Ubuntu и требует подключения официального источника.
wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | apt-key add -
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | tee /etc/apt/sources.list.d/mongodb-org-4.4.list
Здесь стоит обратить внимание на одну хитрость. В URL репозитория указано слово focal, хотя ставится всё это на jammy, то есть Ubuntu 22.04. Это не ошибка. MongoDB иногда отстаёт с поддержкой свежих версий Ubuntu, и использование репозитория для предыдущего LTS-релиза, то есть Ubuntu 20.04 Focal Fossa, это рабочий обходной путь. Пакеты, собранные под focal, прекрасно работают и на jammy благодаря совместимости системных библиотек.
Архитектурное ограничение amd64,arm64 в начале URL говорит apt использовать этот репозиторий только для машин с такими процессорными архитектурами. На экзотических платформах вроде ppc64 пакетов нет, и попытка установки выдала бы ошибку.
После добавления репозитория идёт стандартная процедура обновления кеша и установки.
apt update -y
apt install -y mongodb-org
Метапакет mongodb-org тянет за собой все нужные компоненты: сервер mongod, клиент mongo, утилиты бэкапа и восстановления. Запуск и автостарт настраиваются одной командой.
systemctl enable --now mongod
Двойной флаг --now с enable это удобный приём, который одновременно включает автозагрузку сервиса и запускает его прямо сейчас. Эквивалент двух раздельных команд start и enable, только короче и в одну строку.
Проверка статуса покажет картину работающей базы.
systemctl status mongod
Здоровый MongoDB рапортует примерно так.
? mongod.service - MongoDB Database Server
Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-09-25 07:20:35 UTC; 8s ago
Docs: https://docs.mongodb.org/manual
Main PID: 77018 (mongod)
Memory: 60.0M
CPU: 936ms
CGroup: /system.slice/mongod.service
??77018 /usr/bin/mongod --config /etc/mongod.conf
Sep 25 07:20:35 ubuntu2204 systemd[1]: Started MongoDB Database Server.
Расход памяти у MongoDB на старте скромный, всего 60 мегабайт. По мере накопления данных и роста индексов потребление будет увеличиваться, но в сравнении с Elasticsearch и Java-зверем под Graylog это сущие копейки.
Установка самого Graylog с генерацией криптографических секретов и редактированием главного конфигурационного файла
Дойдя до главного действующего лица, можно наконец ставить Graylog. Разработчики выпустили специальный пакет, который добавляет в систему репозиторий с Graylog. Такой подход удобен тем, что не нужно вручную возиться с ключами и записями в sources.list, всё делается одним пакетом-конфигуратором.
wget https://packages.graylog2.org/repo/packages/graylog-4.3-repository_latest.deb
Скачанный файл это не сам Graylog, а только маленький пакет, который при установке прописывает в систему официальный репозиторий Graylog со всеми нужными настройками доступа и подписями.
dpkg -i graylog-4.3-repository_latest.deb
После такой установки apt уже знает о существовании репозитория Graylog, и можно ставить сервер.
apt update -y
apt install graylog-server -y
Установка завершается быстро, но запускать Graylog ещё рано. Сначала нужно сгенерировать два важных секрета. Первый это password_secret, длинная строка, которую Graylog использует для шифрования паролей пользователей в базе. Без неё пароли хранились бы в открытом виде, что неприемлемо.
pwgen -N 1 -s 96
Параметры команды читаются просто. Флаг -N с числом 1 говорит сгенерировать ровно одну строку, а -s включает режим безопасных паролей с максимальной энтропией. Число 96 в конце задаёт длину строки. Получится что-то вроде такого.
d1fDH1NEOMgb3nxbFYY3eVpqzjOprwgPgFuGh2F0flDdZglJP2CxENV4WEeW8iqZXsjDEZgMob3oBvQYm62RXxoc33hKTPJa
Этот секрет нужно сохранить и не терять. Если он изменится после того, как в системе появятся пользователи, их пароли станут нечитаемыми, и придётся всё восстанавливать.
Второй секрет это хеш пароля для встроенного администратора Graylog. В чистом виде пароль в конфиг не пишется, только его SHA-256 хеш.
echo -n "Enter Password: " && head -1
Команда ждёт ввода пароля с клавиатуры и возвращает его хеш. Введённое значение никуда не пишется в открытом виде, что хорошо с точки зрения безопасности.
Enter Password: yourpassword
e472e1436cbe87774c1bc75d0a646d67e506bea1dff8701fd41f34bca33e1419
Полученный хеш нужно скопировать. Сам пароль yourpassword нужно запомнить, потому что именно его придётся вводить на странице входа в веб-интерфейс.
Теперь оба секрета вставляются в главный конфиг Graylog.
nano /etc/graylog/server/server.conf
Нужные параметры выглядят так.
password_secret = Wv4VQWCAA9sRbL7pxPeY7tb9lSo50esEWgNXxXHypx0Og3CezMmQLdF2QzQdRSIXmNXKINjRvZpPTrvZv4k4NlJrFYTfOc3c
root_password_sha2 = e472e1436cbe87774c1bc75d0a646d67e506bea1dff8701fd41f34bca33e1419
Помимо секретов в этом же файле задаётся адрес, на котором Graylog будет слушать HTTP-запросы.
http_bind_address = 127.0.0.1:9000
Привязка к 127.0.0.1 это осознанный выбор. Graylog будет доступен только локально на самом сервере, а доступ извне пойдёт через Nginx, который выступит обратным прокси. Такой подход даёт лучшую безопасность и позволяет в будущем легко прикрутить HTTPS на уровне прокси.
После сохранения конфига можно запускать сервис.
systemctl daemon-reload
systemctl start graylog-server
systemctl enable graylog-server
Стартует Graylog долго, иногда до минуты или больше на слабых серверах. Это нормально для Java-приложений такого масштаба. Проверка статуса покажет процесс запуска.
systemctl status graylog-server
Здоровый сервис в выводе будет выглядеть так.
? graylog-server.service - Graylog server
Loaded: loaded (/lib/systemd/system/graylog-server.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2022-09-25 07:25:13 UTC; 10s ago
Docs: http://docs.graylog.org/
Main PID: 78082 (graylog-server)
Tasks: 44 (limit: 4579)
Memory: 539.4M
CPU: 18.488s
CGroup: /system.slice/graylog-server.service
??78082 /bin/sh /usr/share/graylog-server/bin/graylog-server
??78119 /usr/bin/java -Xms1g -Xmx1g -XX:NewRatio=1 -server -XX:+ResizeTLAB -XX:-OmitStackTraceInFastThrow -Djdk.tls.acknowledgeC>
Sep 25 07:25:13 ubuntu2204 systemd[1]: Started Graylog server.
Sep 25 07:25:13 ubuntu2204 graylog-server[78119]: OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 a>
Sep 25 07:25:14 ubuntu2204 graylog-server[78119]: WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performan>
Sep 25 07:25:17 ubuntu2204 graylog-server[78119]: WARNING: An illegal reflective access operation has occurred
Sep 25 07:25:17 ubuntu2204 graylog-server[78119]: WARNING: Illegal reflective access by retrofit2.Platform (file:/usr/share/graylog-server/gr>
Sep 25 07:25:17 ubuntu2204 graylog-server[78119]: WARNING: Please consider reporting this to the maintainers of retrofit2.Platform
Sep 25 07:25:17 ubuntu2204 graylog-server[78119]: WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access >
Sep 25 07:25:17 ubuntu2204 graylog-server[78119]: WARNING: All illegal access operations will be denied in a future release
Многочисленные предупреждения о deprecated опциях JVM и illegal reflective access выглядят пугающе, но в работе Graylog не мешают. Это известные особенности взаимодействия старого кода с новыми версиями Java, и разработчики постепенно их устраняют в новых релизах.
Для более детального контроля за стартом удобно следить за основным логом Graylog.
tail -f /var/log/graylog-server/server.log
Финальная строчка успешного запуска выглядит так.
2022-09-25T07:25:40.117Z INFO [ServerBootstrap] Services started, startup times in ms: {FailureHandlingService [RUNNING]=73, GeoIpDbFileChangeMonitorService [RUNNING]=88, PrometheusExporter [RUNNING]=88, OutputSetupService [RUNNING]=89, JobSchedulerService [RUNNING]=89, InputSetupService [RUNNING]=90, BufferSynchronizerService [RUNNING]=91, LocalKafkaMessageQueueReader [RUNNING]=92, LocalKafkaMessageQueueWriter [RUNNING]=92, GracefulShutdownService [RUNNING]=93, MongoDBProcessingStatusRecorderService [RUNNING]=93, UserSessionTerminationService [RUNNING]=101, StreamCacheService [RUNNING]=133, LocalKafkaJournal [RUNNING]=134, UrlWhitelistService [RUNNING]=134, ConfigurationEtagService [RUNNING]=137, EtagService [RUNNING]=139, PeriodicalsService [RUNNING]=174, LookupTableService [RUNNING]=203, JerseyService [RUNNING]=4076}
2022-09-25T07:25:40.133Z INFO [ServerBootstrap] Graylog server up and running.
Сообщение "Graylog server up and running" это сигнал к тому, что система готова принимать соединения. До этого момента веб-интерфейс будет недоступен, даже если порт уже открыт.
Проверка занятого порта подтвердит, что Graylog действительно слушает на 9000.
ss -antpl | grep 9000
Вывод покажет процесс Java, привязанный к нужному адресу и порту.
LISTEN 0 4096 [::ffff:127.0.0.1]:9000 *:* users:(("java",pid=78119,fd=56))
Адрес 127.0.0.1 в выводе подтверждает, что Graylog слушает только на локальном интерфейсе, как и было настроено. Снаружи он недоступен напрямую, и это правильно.
Настройка Nginx в режиме обратного прокси для удобного доступа к веб-интерфейсу через стандартный порт
Доступ к Graylog по адресу с портом 9000 в реальной работе неудобен. Пользователи привыкли к стандартным портам 80 и 443, а часто и просто к доменным именам без портов. Обратный прокси на Nginx решает эту задачу элегантно. Он принимает запросы на 80-й порт, корректно прокидывает их Graylog со всеми нужными заголовками и возвращает ответы обратно клиенту.
apt install nginx -y
После установки Nginx нужно создать конфигурационный файл виртуального хоста для Graylog.
nano /etc/nginx/sites-available/graylog.conf
В файл вписывается типовая конфигурация прокси для Graylog.
server {
listen 80;
server_name graylog.example.org;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Graylog-Server-URL http://$server_name/;
proxy_pass http://208.117.84.72:9000;
}
}
Здесь много интересных деталей. Директива listen 80 говорит Nginx принимать соединения на стандартном HTTP-порту. Параметр server_name определяет, на какое доменное имя должен реагировать этот виртуальный хост. Имя graylog.example.org нужно заменить на реальный домен или поддомен, который указывает на сервер.
Блок location указывает Nginx обрабатывать все пути на этом домене. Серия директив proxy_set_header передаёт Graylog оригинальные данные о запросе клиента. Без этих заголовков Graylog видел бы все запросы как идущие с localhost, что ломало бы построение ссылок и логирование. Заголовок X-Graylog-Server-URL это особенный параметр, специфичный для Graylog. Через него фронтенд узнаёт, по какому адресу обращаться к API на бекенде.
Директива proxy_pass указывает, куда отправлять запросы. В примере стоит IP-адрес 208.117.84.72, но в реальной установке его нужно заменить на 127.0.0.1, если Graylog работает на той же машине. Адрес из примера это IP конкретного сервера автора оригинальной инструкции, и на других машинах он, разумеется, не подойдёт.
Перед применением конфигурации обязательно проверяется её синтаксис.
nginx -t
Успешная проверка вернёт два сообщения о корректности.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Если в выводе появляются ошибки или предупреждения, нужно их устранить, иначе перезапуск Nginx прервётся и сервис останется в нерабочем состоянии.
Активация виртуального хоста делается через символическую ссылку из sites-available в sites-enabled. Это устоявшаяся практика Debian-семейства дистрибутивов, которая позволяет хранить все конфиги в одном месте, а включать только нужные.
ln -s /etc/nginx/sites-available/graylog.conf /etc/nginx/sites-enabled/
Дефолтный виртуальный хост Nginx, который показывает приветственную страницу, лучше убрать. Он может конфликтовать с новой конфигурацией или просто маячить лишней страницей.
rm -rf /etc/nginx/sites-enabled/default
После изменения активных конфигов Nginx нужно перезапустить, чтобы он подхватил новые настройки.
systemctl restart nginx
Контрольная проверка статуса убедит, что Nginx живёт и здравствует.
systemctl status nginx
Здоровый Nginx выглядит так.
? nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-09-25 07:30:45 UTC; 8s ago
Docs: man:nginx(8)
Process: 78980 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 78981 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 78982 (nginx)
Tasks: 3 (limit: 4579)
Memory: 3.3M
CPU: 49ms
CGroup: /system.slice/nginx.service
??78982 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
??78983 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
??78984 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
Sep 25 07:30:45 ubuntu2204 systemd[1]: Started A high performance web server and a reverse proxy server.
Расход памяти у Nginx смешной по сравнению с Java-зверями. Всего 3.3 мегабайта против гигабайта у Graylog и 1.2 гигабайт у Elasticsearch. Это и есть та самая магия эффективного C-кода, за которую Nginx так любят.
Вход в веб-интерфейс Graylog и первые шаги по настройке источников логов
Когда вся инфраструктура поднята, можно открывать браузер и проверять результат работы. В адресной строке вводится доменное имя, прописанное в server_name конфига Nginx. Если домен ещё не настроен в DNS, для теста можно прописать соответствие в файле hosts на клиентской машине.
При обращении к http://graylog.example.com появится страница входа в Graylog с полями для логина и пароля. Имя пользователя по умолчанию admin, а пароль это тот самый yourpassword, который вводился при генерации хеша. После успешной авторизации откроется главный дашборд системы, ещё пустой, но готовый к работе.
Первым шагом обычно настраивают входной канал для приёма логов. Graylog поддерживает множество протоколов и форматов. Syslog UDP и TCP для классических Unix-логов, GELF для специфичных Graylog-сообщений с расширенными полями, Beats для интеграции с Elastic-стеком, Kafka для высоконагруженных потоков. Каждый Input настраивается через интуитивный интерфейс с подсказками и валидацией параметров.
Несколько типичных проблем поджидают новичков на этом этапе. Первая это нехватка памяти. Если сервер еле тянет 4 гигабайта оперативки, JVM Elasticsearch и Graylog начинают конкурировать за ресурсы, и система тормозит или вылетает по OOM. Решение простое, нарастить память до 8 гигабайт или больше для серьёзной нагрузки. Вторая проблема это закрытые порты на файрволе. Если используется ufw или iptables, нужно явно разрешить трафик на 80-й порт для Nginx и на порты для входных каналов логов. Третья типичная сложность связана с DNS. Без правильно настроенного домена доступ к Graylog по имени работать не будет, а с использованием IP-адреса прямо в URL могут возникать проблемы из-за заголовков прокси.
Полезный совет из практики: всегда мониторьте свободное место на диске. Elasticsearch начинает капризничать и переходить в режим только для чтения, когда место заканчивается, и логи перестают индексироваться. Настройка ротации индексов в самом Graylog помогает контролировать этот процесс автоматически. Можно задать ограничения по времени хранения, по количеству сообщений или по размеру индексов, и старые данные будут удаляться по расписанию.
Что даёт центральная система сбора логов команде и почему стоит вложиться в её настройку
Развёртывание Graylog с нуля требует времени и понимания нескольких технологий одновременно. Но окупаются эти вложения сторицей, как только команда начинает реально пользоваться системой. Время на диагностику инцидентов сокращается в разы. Вместо часовой беготни по серверам с grep и tail приходит десятиминутный поиск через веб-интерфейс с фильтрами по времени, источнику и уровню важности. Корреляция событий между разными сервисами становится очевидной, потому что все логи в одном месте с единой временной шкалой.
Оповещения, которые можно настраивать в Graylog, превращают пассивный мониторинг в активный. Когда количество ошибок 500 на веб-сервере превышает порог, или когда в логах появляется паттерн "out of memory", система сама присылает уведомление администратору. Это даёт возможность реагировать на проблемы до того, как они станут заметны пользователям.
Связка Elasticsearch и Graylog раскрывает возможности полнотекстового поиска по логам. Привычные команды grep и awk бледнеют на фоне того, что умеет Lucene под капотом Elasticsearch. Сложные запросы с булевой логикой, поиск по фразам, нечёткое сравнение, поиск по интервалам и регулярным выражениям. Все эти инструменты доступны через простой синтаксис в строке поиска веб-интерфейса.
Для команд DevOps и SRE наличие централизованной системы логов часто становится переломным моментом. До неё инфраструктура существует как набор разрозненных кусков, после неё превращается в наблюдаемое целое. Метрики, трейсы и логи это три кита современной observability, и логи здесь играют особую роль, потому что содержат самые подробные данные о происходящем. Освоение Graylog или подобных систем это шаг от ремесленного администрирования к инженерному подходу, при котором решения принимаются на основе данных, а не интуиции и догадок.
Канал сайта в Telegram
Канал сайта на YouTube