ELK-стек в продакшне: Kibana 4 даёт дашборды там, где раньше был только grep

Сколько раз в ответ на «что было в логах в 14:32 на трёх серверах одновременно?» мы открывали три SSH-сессии и запускали grep с tail -f в каждой - и считали это нормой. rsyslog собирал всё в одно место, но «одно место» было текстовым файлом, и дальше начинался ручной разбор. ELK-стек мы смотрели давно, но Kibana 3 требовала дополнительных усилий для нормального интерфейса. Kibana 4 вышла в бете и переменила ситуацию достаточно, чтобы взяться за пилот на реальном стенде.

Что в стеке и зачем каждый слой

Logstash - агрегатор и парсер. Принимает входящий поток, разбирает grok-паттернами, нормализует поля, отдаёт в Elasticsearch. Может выступать и агентом на хосте, и центральным брокером - мы разделили роли: на хостах форвардим через rsyslog или logstash-forwarder, Logstash только принимает и парсит.

Elasticsearch - хранилище и поисковый движок. Логи хранятся как JSON-документы, индексируются по всем полям. Запрос «все записи с HTTP 500 от конкретного upstream за последние 15 минут» - это один запрос, а не grep по гигабайтному файлу.

Kibana 4 - интерфейс. Главное изменение по сравнению с третьей версией: теперь это нормальный веб-интерфейс с Discover, Visualize и Dashboard как отдельными разделами. Строишь график по полю status nginx - видишь всплеск 502 в 14:31. Кликаешь - фильтруешь, видишь конкретные запросы. На это уходит минута, а не пять минут grep.

Pipeline: три источника

Под пилот взяли клиентский стенд на сопровождении: несколько CentOS-серверов, два nginx-балансировщика и несколько Windows-машин с IIS. Задача - всё в одну точку, единый поиск.

Syslog с Linux-хостов. Самый простой источник. rsyslog на хостах форвардит через UDP/TCP на центральный Logstash по стандартному RFC 5424. В конфиге Logstash input - syslog { port => 5514 }, grok-паттерн для syslog уже встроен. Единственное что пришлось добавить - поле host явно, потому что rsyslog иногда шлёт FQDN, иногда короткое имя, и в индексе они разъезжаются как два разных хоста.

nginx access.log. Здесь интереснее. Мы поменяли формат лога nginx на log_format combined_json - JSON прямо из nginx, без grok. Logstash принимает через logstash-forwarder, filter - json { source => "message" }, и поля status, upstream_response_time, request_uri, bytes_sent сразу готовы для агрегаций. Это дало вменяемые графики времени ответа upstream по эндпоинтам - раньше такое считалось вручную через awk после инцидента.

Windows Event Log через nxlog. nxlog - кросс-платформенный агент сбора логов, ставится как служба Windows. Подписывается на каналы System, Security, Application и форвардит события в Logstash через syslog или собственный формат. На трёх Windows-машинах поставили без проблем. Поля событий приходят с EventID, Source, Level, Message - нормализуем grok-паттерном в Logstash. Kibana по ним ищет. Удобно для базового аудита: залогин/разлогин, старт служб, ошибки приложений - всё в одном месте с linux-логами.

Что пошло не по туториалу

Java и память. Elasticsearch и Logstash оба написаны на JVM. На выделенном сервере с 8 ГБ они вдвоём хотят столько, что ОС остаётся впритык. Пришлось явно ограничить heap через ES_HEAP_SIZE и LS_HEAP_SIZE и держать их суммой не больше половины RAM. Иначе Elasticsearch начинает свопиться, и поиск превращается в ожидание.

grok медленнее чем кажется. На потоке в несколько тысяч событий в секунду Logstash держится, но если grok-паттерн неточный и много событий не матчится - растёт очередь, растёт задержка. Отлаживали паттерны через онлайн-отладчик grokdebug.herokuapp.com - это сильно быстрее чем перезапускать Logstash на каждый вариант.

Ротация индексов. По умолчанию Logstash создаёт индексы вида logstash-YYYY.MM.DD. Через месяц индексов много, Elasticsearch начинает тормозить при открытии всех сразу. Решение - curator, утилита для управления жизненным циклом индексов: старше 30 дней закрываем, старше 60 удаляем. Без этого место на диске и оперативная память уходят тихо и незаметно.

Kibana 4 ещё не 1.0. Бета есть бета: несколько раз видели зависание интерфейса при сложных агрегациях, один раз Dashboard не сохранился. Не критично для пилота, но в продакшн как основной инструмент мониторинга - только с резервным способом смотреть логи рядом.

Итог пилота

Неделя работы с ELK - и часть вопросов типа «а что было на серверах в момент инцидента» перестала требовать ssh + grep. Kibana 4 действительно даёт рабочие дашборды без написания кода - достаточно понять интерфейс. Pipeline для трёх источников описывается в Ansible-плейбуке примерно в 200 строк YAML включая установку пакетов.

Главный вывод: ELK не «поставил и забыл». Это отдельный сервис с ресурсными требованиями, который надо обслуживать - следить за индексами, настраивать retention, чинить grok при изменении формата лога. Но по сравнению с тем, что было до - rsyslog в один файл и grep - разница ощутима уже на первой неделе.