Graylog 2.1 вместо ELK: меньше компонентов, тот же результат

Несколько недель назад вышел Graylog 2.1. У нас к этому моменту уже был живой кейс - клиент, которому нужна централизованная обработка логов, но ресурсов под нормальный ELK-стек не хватало. Так что новость о релизе мы встретили не абстрактным интересом, а на работающей инсталляции.

Откуда взялся Graylog вместо ELK

Когда речь заходит о централизации логов, первое что приходит в голову - это Elasticsearch + Logstash + Kibana. Мы сами с этим стеком работаем давно, и в целом он справляется хорошо. Но у него есть одна особенность: чтобы это всё нормально работало в продакшне, нужны ресурсы. Elasticsearch любит память. Logstash тоже не аскет. Kibana - ещё один процесс. Итого три сервиса, каждый из которых требует отдельного внимания и настройки. На мощной инфраструктуре это нормально. На паре не самых толстых виртуалок - уже вопрос.

Клиент из этого кейса - небольшое производственное предприятие, у которого есть несколько серверов с Windows и Linux, пара веб-приложений и растущее желание понимать что происходит в логах не по итогам инцидента, а в режиме хотя бы приближённом к реальному времени. Бюджет ограничен, DevOps-команды нет - есть один сисадмин и мы на managed-сопровождении.

ELK в такой ситуации можно поднять, но эксплуатировать его будет тяжело. Logstash конфигурируется через DSL с фильтрами и кодеками - это не ракетостроение, но человеку без опыта написать и отладить pipeline для нескольких источников это задача на несколько вечеров. X-Pack для алертинга платный. Без него алертинг в ELK - это отдельный инструмент, либо сторонние плагины.

Graylog закрывает ровно эти точки. Он работает поверх Elasticsearch, но прячет за собой значительную часть его сложности. Вместо Logstash - встроенная обработка сообщений с графическим редактором. Алертинг встроен и бесплатен с первого дня.

Что изменилось в 2.1

До обновления у нас стоял Graylog 2.0. Двойка уже была значительным шагом - переработанный UI, нормальный REST API. В 2.1 акцент на потоках и алертах.

Потоки стали значительно гибче. Stream rules теперь поддерживают более сложную логику - AND/OR комбинации условий, быстрое тестирование правила на живом потоке прямо в UI. Раньше приходилось сохранять правило, ждать новых сообщений и проверять попадают ли они в нужный поток. Теперь можно нажать «Test rule» и увидеть результат на последних сообщениях немедленно.

Алертинг переработали. Alarm callbacks теперь более предсказуемо ведут себя при нескольких одновременных условиях. Добавили «Grace period» - чтобы не получать одно и то же оповещение каждые пять минут пока проблема не устранена. Это была боль в 2.0: если условие выполнялось на каждом check interval, уведомления сыпались без остановки.

Улучшили Collector sidecar - агент для сбора логов с хостов. По сути это обёртка над Filebeat или NXLog, которая получает конфигурацию с центрального Graylog-сервера. Для Windows-хостов это особенно удобно: NXLog с центральным управлением без ручной правки конфигов на каждой машине.

Как выглядит инсталляция

Стек у клиента: MongoDB для конфигурации и метаданных, Elasticsearch 2.x для хранения сообщений, сам Graylog-сервер. Всё на двух виртуалках. MongoDB и Graylog вместе на одной, Elasticsearch отдельно.

Inputs настроены на GELF UDP от приложений и Syslog TCP от сетевого оборудования. Для Windows-хостов - Collector sidecar с NXLog, который шлёт на GELF-input.

Потоков четыре:

• «Application errors» - всё уровня ERROR и выше из веб-приложений
• «Security events» - неудачные авторизации с Windows-хостов и SSH
• «Infrastructure» - syslog с роутеров и коммутаторов
• «Default stream» - остальное, без роутинга

Алерт настроен на первый поток: если за последние 5 минут больше 10 ERROR-сообщений - уведомление на email. Grace period 15 минут, чтобы не заспамить в случае шторма ошибок.

Что работает хорошо, что не очень

Хорошее: скорость запуска в продакшн. От нулевой инсталляции до работающего сбора логов с нескольких источников - один рабочий день. С ELK на такой же набор источников ушло бы минимум втрое больше.

Алертинг работает. Не надо ничего дополнительно устанавливать, не надо разбираться с X-Pack или ElastAlert. Создаёшь условие в UI, указываешь куда отправить - работает.

Поиск по логам в интерфейсе понятен даже сисадмину без опыта с Elasticsearch. Синтаксис Graylog-поиска проще чем Kibana Discover для неподготовленного человека.

Менее хорошее: визуализация беднее чем в Kibana. Дашборды в Graylog функциональны, но Kibana с её Visualize и возможностью строить произвольные агрегации - другой уровень. Для клиента это не критично - ему нужен поиск и алерты, а не красивые графики. Но если бы задача была аналитика логов, выбор был бы другим.

Ещё одна особенность: Graylog хранит метаданные в MongoDB. Ещё один сервис, ещё один процесс, ещё один бэкап. Небольшой накладной расход, но он есть.

Где сейчас

Инсталляция работает второй месяц. Логи собираются, алерты приходят. На прошлой неделе алерт по application errors поймал проблему раньше, чем кто-то из пользователей успел написать в поддержку - это уже окупает время на настройку.

ELK мы не списываем - для другого клиента с другим бюджетом и другими требованиями к аналитике он остаётся основным выбором. Но Graylog занял в нашем наборе инструментов свою нишу: когда нужна централизация логов без DevOps-оверхеда, он справляется.