Graylog 1.0 vs ELK: когда меньше Java-процессов - это плюс
Graylog 1.0 вышел с встроенным веб-интерфейсом и GELF-протоколом. Сравниваем с ELK на клиентском стенде с ограниченными ресурсами: где Graylog выигрывает, а где ELK объективно сильнее.
Graylog 1.0 выходит как зрелая альтернатива ELK-стеку с встроенным веб-интерфейсом и нативной поддержкой GELF
Месяц назад мы разворачивали ELK-стек для централизованных логов и по итогу написали честно: это не «поставил и забыл», это отдельный сервис с ресурсными аппетитами. После того поста один из клиентов на сопровождении спросил: «а есть что-то попроще, у нас не три выделенных сервера под логи, а один с 8 ГБ RAM?» Как раз вышел Graylog 1.0 - посмотрели.
Что такое Graylog в одном абзаце
Graylog - централизованная платформа для логов с собственным веб-интерфейсом. Под капотом тоже Elasticsearch как поисковый движок, но рядом - MongoDB для хранения метаданных (конфигурации, дашборды, алерты) и сам Graylog-сервер как оркестратор. Никакого отдельного Kibana, никакого Logstash - один процесс принимает, разбирает и показывает.
Отдельно стоит упомянуть GELF (Graylog Extended Log Format) - собственный протокол поверх UDP/TCP/AMQP, который умеет структурированные поля без grok-паттернов. Библиотеки для отправки GELF есть под большинство языков.
Стенд и что сравнивали
Клиентский стенд: один сервер под логи - CentOS 7, 8 ГБ RAM, 4 ядра. Источники: семь Linux-серверов через rsyslog, два nginx-балансировщика, одно приложение на Java. Объём - несколько миллионов событий в сутки, не BigData, но и не игрушечный стенд.
ELK на этом же железе мы пробовали раньше: Elasticsearch + Logstash + Kibana 4 вместе хотели около 5-6 ГБ heap, ОС оставалось совсем немного. Пришлось резать настройки до минимума и всё равно периодически наблюдали swap.
Graylog развернули через Ansible-плейбук - три роли: mongodb, elasticsearch, graylog-server. MongoDB для метаданных есть не такой тяжёлый, как кажется - на нашем стенде стабильно жил в 200-300 МБ. Elasticsearch настроили с 2 ГБ heap (у нас один узел, репликация не нужна). Graylog-сервер взял ещё около 512 МБ. Итого под стек - около 3 ГБ, ОС и источники событий живут нормально.
Где Graylog реально удобнее
Встроенный веб-интерфейс. Кибана - отдельный компонент, который надо ставить, обновлять, следить за совместимостью версий с Elasticsearch. У Graylog интерфейс встроен в сервер. Открыл порт 9000 - уже работает. Поиск, стримы, дашборды, алерты - всё там же.
Стримы как маршрутизация. В Graylog есть концепция Streams - это правила фильтрации, которые в реальном времени раскидывают входящие события по «каналам». Например, все события с полем level >= ERROR от приложения идут в стрим «Critical», остальное - в «General». Стримы можно использовать как таргеты для алертов: пришло 10 ERRORов за минуту - пришёл email. В ELK такое настраивается через сторонние инструменты - в базовой конфигурации алертов нет.
GELF от приложения. Java-приложение у клиента подключили к logback-appender для GELF - и структурированные события полетели напрямую в Graylog без Logstash-парсинга. Поля userId, requestId, duration пришли как есть, без grok. Это честная разница: когда приложение умеет GELF, промежуточный парсер не нужен.
rsyslog в Graylog через UDP/514. Graylog принимает syslog нативно - в конфиге input добавляешь Syslog UDP input, указываешь порт, и rsyslog с хостов шлёт как обычно. Никакого Logstash-форвардера посередине.
Где ELK объективно сильнее
Гибкость парсинга. Logstash с grok - это комбайн. Принять SNMP trap, распарсить кастомный формат старого оборудования, обогатить GeoIP-данными - это Logstash умеет из коробки. Graylog тоже умеет экстрактить поля через регулярки и JSON-экстракторы, но Logstash в этом месте значительно мощнее.
Kibana 4 для аналитики. Если нужны сложные визуализации и нестандартные агрегации - Kibana с её Visualize-разделом даёт больше свободы. Graylog-дашборды функциональные, но без некоторых типов графиков которые в Kibana есть.
Экосистема Beats. Filebeat, Packetbeat - легковесные агенты от Elastic, которые умеют слать в Elasticsearch напрямую или через Logstash. У Graylog своих агентов в этом стиле нет - придётся либо rsyslog, либо GELF-библиотеки, либо Logstash как форвардер (что несколько обессмысливает упрощение).
Практический вывод
На нашем стенде с одним сервером и умеренным объёмом Graylog выиграл по одному критерию: он нормально работает в тех же условиях, где ELK начинает скрипеть из-за памяти. Это не потому что Graylog «лучше» - просто у него меньше JVM-процессов под одну задачу, и на ограниченном железе это ощутимо.
Алерты из коробки - это отдельный плюс. Клиент хотел уведомления о ERROR-событиях без дополнительных инструментов - в Graylog это настраивается за полчаса через UI без единой строки кода или конфига.
Если у вас большой стенд, нестандартные источники данных и команда, готовая разобраться с Logstash - ELK даёт больше возможностей. Если один сервер, стандартные syslog-источники и нужно быстро получить рабочий поиск по логам с алертами - Graylog ставится и работает с меньшими усилиями. На данный момент для этого клиента оставляем Graylog в продуктиве и смотрим как он ведёт себя под реальной нагрузкой несколько недель.