Что такое ELK и Elastic Stack

Знакомство с четырьмя компонентами стека и тем, кто за что отвечает в конвейере логов.

Elastic Stack (исторически ELK) — связка из Elasticsearch, Logstash, Kibana и семейства лёгких сборщиков Beats для сбора, хранения, поиска и визуализации данных, прежде всего логов.

Откуда взялась аббревиатура

ELK — это первые буквы трёх продуктов: Elasticsearch, Logstash, Kibana. Все три развивает компания Elastic. Позже к ним добавилось семейство Beats — лёгких агентов сбора, — и аббревиатура честнее звучала бы как «ELKB», но прижилось название Elastic Stack. В этом курсе «ELK» и «Elastic Stack» — синонимы.

Elasticsearch — хранилище и поиск

Сердце стека. Это распределённая поисковая база данных, которая хранит документы (в нашем случае — записи логов) и индексирует их так, чтобы полнотекстовый поиск и агрегации выполнялись очень быстро. Именно сюда в итоге попадают все логи, и именно отсюда Kibana их достаёт. Основы Elasticsearch — индексы, шарды, инвертированный индекс — подробно разобраны в нашем отдельном учебнике по Elasticsearch; здесь мы используем его как готовое хранилище логов и не повторяем базу.

Beats — лёгкие сборщики на источниках

Beats — это маленькие агенты на Go, которые ставятся прямо на машины-источники и делают одну вещь хорошо: читают данные и отправляют дальше. Самый важный для нас — Filebeat: он следит за лог-файлами и шлёт новые строки. Есть и другие: Metricbeat (метрики ОС), Packetbeat (сетевой трафик), Winlogbeat (журналы Windows). Beats нарочно простые и почти не грузят источник.

  web-сервер
  ├── /var/log/nginx/access.log
  └── Filebeat  --читает и шлёт-->  дальше по конвейеру

Logstash — обработка и преобразование

Logstash — это «фабрика» обработки данных в пути. Он принимает поток событий, прогоняет каждое через цепочку фильтров (разбор строки на поля, обогащение, отбрасывание мусора) и отправляет результат в Elasticsearch. Logstash мощный, но тяжёлый (JVM, заметная память), поэтому его ставят не на каждый источник, а отдельным узлом-обработчиком. Часто связка такая: лёгкий Filebeat собирает → Logstash обрабатывает → Elasticsearch хранит.

Kibana — глаза стека

Kibana — веб-интерфейс поверх Elasticsearch. В ней вы ищете логи (Discover), строите дашборды и графики, настраиваете алерты и управляете самим стеком. Без Kibana Elasticsearch — это «слепое» хранилище, к которому можно стучаться только через API; Kibana делает данные видимыми для человека.

Как работает под капотом: типовой конвейер

Собрав роли вместе, получаем классический поток данных в ELK:

  ИСТОЧНИК      СБОР        ОБРАБОТКА      ХРАНЕНИЕ        ВИДИМОСТЬ
  app.log  -->  Filebeat -->  Logstash  -->  Elasticsearch -->  Kibana
               (Beats)      (парсинг,      (индекс по        (поиск,
                            обогащение)     времени)          дашборды)

Это не единственная схема. Filebeat умеет писать в Elasticsearch и напрямую, минуя Logstash, если обработки почти не нужно (об этом — в разделе про Beats). Но как опорная картинка «источник → сбор → обработка → хранение → визуализация» она держит весь курс.

Почему именно такая декомпозиция

Может возникнуть вопрос: зачем дробить систему на четыре отдельных продукта, не проще ли иметь один монолит? Разделение на сбор, обработку, хранение и визуализацию — это не случайность, а отражение того, что у каждого этапа конвейера свои требования к ресурсам и масштабированию. Сборщику нужно быть лёгким и присутствовать на тысячах источников — поэтому Beats маленькие. Обработке нужен CPU и она хорошо параллелится — поэтому Logstash выносят на отдельные узлы и масштабируют независимо. Хранению нужны диск, память и распределённость — поэтому Elasticsearch это кластер из многих узлов. Визуализации нужен один доступный веб-интерфейс — поэтому Kibana обычно в одном-двух экземплярах. Слив всё в монолит, вы не смогли бы масштабировать эти части по отдельности под их разные профили нагрузки.

Эта же модульность даёт гибкость замены компонентов. Не нравится Logstash — поставьте Fluentd или ingest-пайплайны. Не нравится Filebeat — возьмите Fluent Bit или Vector. Хранилище и UI остаются, а сборщик и обработчик взаимозаменяемы. Именно поэтому вокруг Elasticsearch выросла целая экосистема альтернативных компонентов, и стек можно собирать почти как конструктор под свои нужды — мы увидим это в разделах про Kubernetes и альтернативы.

Частые ошибки

Путать роли Logstash и Beats. Beats — лёгкий сборщик на источнике; Logstash — тяжёлый обработчик в стороне. Ставить Logstash на каждый веб-сервер — частая дорогостоящая ошибка.
Считать, что Logstash обязателен. Для простых случаев Filebeat + ingest-пайплайны Elasticsearch обходятся без Logstash вообще.
Думать, что Kibana хранит данные. Kibana ничего не хранит — это только интерфейс к Elasticsearch. Удалите данные в ES — в Kibana они исчезнут.

Итоги

Elastic Stack = Elasticsearch (хранение/поиск) + Logstash (обработка) + Kibana (визуализация) + Beats (сбор).
Filebeat — главный сборщик логов; Logstash — тяжёлый обработчик, ставится отдельным узлом.
Опорный конвейер: источник → Filebeat → Logstash → Elasticsearch → Kibana.
Для простых случаев Logstash можно опустить — Filebeat пишет в ES напрямую.