ELK-стек: компоненты, схема логирования и настройка

Короткий ответ

ELK-стек объединяет Elasticsearch, Logstash и Kibana для централизованного сбора, обработки, поиска и визуализации данных. В типичной схеме приложение пишет структурированные события, агент доставляет их напрямую в Elasticsearch или через Logstash, Elasticsearch индексирует документы, а Kibana помогает искать ошибки и строить панели.

Сегодня Elastic чаще говорит об Elastic Stack: помимо трёх компонентов, в него входят Elastic Agent, интеграции?, APM и другие средства. Logstash не обязателен для каждой установки. Если агент или ingest pipeline уже выполняет нужные преобразования, лишний промежуточный сервис только усложнит эксплуатацию.

ELK и Elastic Stack: в чём разница

Аббревиатура ELK образована от Elasticsearch, Logstash и Kibana. Она описывает историческое ядро решения. Название Elastic Stack шире и точнее для современных архитектур, где данные собирают Elastic Agent, Beats, OpenTelemetry Collector или клиенты приложений.

Термин «стек» здесь означает набор совместно используемых программ, а не структуру данных LIFO. Правила «последним пришёл - первым вышел» к ELK отношения не имеют.

Как проходит событие от приложения до Kibana

1. Приложение создаёт событие. Лучше писать одну структурированную запись на событие, включая время, сервис, уровень и идентификаторы корреляции.

2. Агент читает источник. Это может быть файл, stdout контейнера, системный журнал или интеграция.

3. Конвейер разбирает запись. Поля нормализуются, ненужные значения удаляются, чувствительные данные маскируются.

4. Событие попадает в data stream или индекс. Elasticsearch применяет mapping и делает документ доступным для поиска с небольшой задержкой.

5. Kibana читает данные. Инженер фильтрует события, связывает их по trace ID, строит панель или правило оповещения.

6. Политика жизненного цикла управляет хранением. Старые данные переходят между уровнями либо удаляются по принятому retention.

Elasticsearch предоставляет поиск и аналитику в режиме near real time, то есть почти в реальном времени. Между записью события и его видимостью есть задержка; её нельзя обещать как абсолютный ноль.

Каким должен быть лог приложения

Свободный текст удобен человеку, но плохо подходит для устойчивых фильтров. Структурированный JSON позволяет хранить значения отдельными полями:

{
  "@timestamp": "2026-09-02T07:00:00Z",
  "service.name": "checkout-api",
  "service.version": "example",
  "log.level": "ERROR",
  "event.action": "payment_request",
  "trace.id": "example-trace-id",
  "message": "Upstream request failed"
}

Пример показывает форму, а не обязательный контракт. Схему нужно согласовать для конкретной системы. Полезно придерживаться единого именования полей, передавать время в однозначном формате и добавлять идентификатор запроса или trace ID.

Не записывайте пароли, токены, ключи API?, номера банковских карт и полные персональные данные. Маскирование на стороне Logstash не отменяет фильтрацию в приложении: секрет мог попасть в локальный файл или транспорт ещё до обработки.

Когда нужен Logstash

Logstash оправдан, когда требуется объединить несколько протоколов, выполнить сложный парсинг, обогащение, условную маршрутизацию или отправку в разные назначения. Его pipeline состоит из input, filter и output, но это не означает, что каждый лог обязан проходить через все возможные фильтры.

Прямой путь Elastic Agent → Elasticsearch проще, если интеграция уже создаёт корректные поля. Для более сложной схемы используют Agent → Logstash → Elasticsearch. В критичной системе оценивают persistent queue, повторные попытки, backpressure и поведение при недоступности следующего узла.

Логи, метрики и трассировки

ELK часто называют системой мониторинга, но одних логов недостаточно для полной наблюдаемости. Надёжная диагностика связывает логи, метрики и трассировки общими полями сервиса, среды, версии и запроса.

Как внедрить ELK по шагам

1. Выберите один диагностический сценарий. Например, поиск причин HTTP 5xx одного сервиса.

2. Оцените поток. Измерьте средний и пиковый объём событий, размер записи и требуемый срок хранения.

3. Спроектируйте схему. Зафиксируйте обязательные поля, типы и правила маскирования.

4. Выберите путь доставки. Начните с Agent и интеграции; добавляйте Logstash только при понятной необходимости.

5. Создайте data stream и шаблон. Ограничьте динамическое появление полей и проверьте mapping.

6. Настройте безопасность. TLS, отдельные роли, минимальные права, API keys и закрытый административный доступ.

7. Определите retention. Используйте data stream lifecycle или ILM в зависимости от типа развёртывания и требований.

8. Соберите поисковые запросы и панели. Они должны отвечать на операционные вопросы, а не просто выглядеть насыщенно.

9. Добавьте оповещения. Проверяйте сигнал на тестовом инциденте и исключайте бесконечный шум.

10. Проведите проверку отказа. Остановите приёмник в контролируемой среде и убедитесь, что понятно, где буферизуются и теряются события.

Безопасность по умолчанию и на практике

Утверждение, что в Elasticsearch нет встроенной авторизации, устарело. В управляемых развёртываниях Elastic безопасность настраивается автоматически. В self-managed установках автоматическая конфигурация выполняется, когда это возможно, однако администратор всё равно должен проверить TLS, пользователей, роли и сетевую доступность.

• не публикуйте Elasticsearch и Kibana напрямую в интернет без обоснованной схемы доступа;

• не используйте суперпользователя для агентов и приложений;

• разделяйте права чтения, записи и управления;

• защищайте трафик между агентом, Logstash и Elasticsearch;

• храните учётные данные вне конфигурации приложения;

• ограничивайте доступ к логам с персональными и коммерческими данными;

• журналируйте административные действия и ротацию ключей.

Как не переполнить хранилище

Логи непрерывно накапливаются. Политика «хранить всё» быстро превращается в эксплуатационный риск. До запуска определите минимальный срок для диагностики, юридические ограничения и потребность в долгом архиве.

Elastic предлагает Data Stream Lifecycle и Index Lifecycle Management. Конкретный выбор зависит от типа развёртывания: например, ILM недоступен в Elasticsearch Serverless. Политика может задавать retention, rollover и переход между уровнями хранения. Она должна быть проверена на тестовом потоке, а не только сохранена в интерфейсе.

Mapping и качество данных

Если одно поле иногда приходит числом, а иногда строкой, индексирование может завершиться ошибкой. Динамические имена вроде header_12345 создают множество полей и раздувают mapping. Это называют mapping explosion.

• используйте стабильный контракт событий;

• проверяйте типы до отправки;

• не превращайте значения в имена полей;

• разделяйте несовместимые наборы данных;

• отправляйте ошибочные события в контролируемый канал и наблюдайте за ним;

• версионируйте значимые изменения схемы.

Преимущества и ограничения

Что учесть в лицензировании

Нельзя без оговорок называть весь современный стек продуктом под Apache 2.0. Elastic указывает, что бесплатные части исходного кода Elasticsearch и Kibana доступны с выбором AGPLv3, SSPL или Elastic License 2.0, а стандартная дистрибуция выпускается под ELv2. Для внутреннего использования, встраивания, изменения и особенно управляемого сервиса проверьте актуальные условия нужной версии и компонентов.

Типичные ошибки

• ставить все компоненты ELK до формулировки задачи;

• принимать ELK-стек за структуру данных stack;

• считать Elasticsearch обычной долговременной резервной копией логов;

• открывать кластер наружу и работать одной привилегированной учётной записью;

• отправлять секреты и персональные данные в message;

• разрешать неограниченное создание полей;

• не задавать retention и обнаружить заполненный диск;

• измерять только доступность Elasticsearch, но не задержку и ошибки ingest;

• обещать отсутствие потерь без испытания очередей и сценариев отказа;

• устанавливать разные версии компонентов без проверки совместимости.

Чек-лист готовности

• есть конкретный сценарий диагностики и владелец;

• измерены объём и пики событий;

• утверждена схема полей;

• секреты исключаются до доставки;

• TLS и минимальные роли проверены;

• mapping ограничен шаблоном;

• retention соответствует стоимости и требованиям;

• очереди и повторные попытки наблюдаемы;

• панели отвечают на операционные вопросы;

• оповещения проверены контролируемым событием;

• есть snapshots и план восстановления;

• лицензия соответствует способу использования.

Вывод

ELK полезен не количеством компонентов, а управляемым путём события от приложения до ответа на вопрос инженера. Начните с единой схемы логов и одного сценария, выберите минимальный ingest, настройте доступы и retention, затем проверьте отказ и только после этого масштабируйте панели и источники.

Источники

• Elastic Docs: состав и установка Elastic Stack

• Elastic Docs: безопасность Elasticsearch

• Elastic Docs: жизненный цикл данных

• Elastic Docs: развёртывание и масштабирование Logstash

• Elastic: FAQ по лицензированию