Пять этапов конвейера логов

Логи проходят пять чётких этапов — понимание каждого помогает проектировать и чинить конвейер.

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

Зачем мыслить этапами

Когда логи «не доходят» до Kibana, причина всегда на одном из этапов: не читаются на источнике, теряются при пересылке, отбрасываются на обработке или не индексируются. Разбив путь на этапы, вы превращаете расплывчатое «логи пропали» в конкретный вопрос «на каком шаге?». Это главный навык эксплуатации ELK.

Этап 1: источник

Источник — это то, что порождает лог: файл приложения (app.log), стандартный вывод контейнера, журнал systemd, syslog сетевого устройства. Формат может быть любым: человекочитаемая строка, JSON, бинарный журнал. Главное на этом этапе — решить, что мы вообще собираем и в каком виде это рождается.

Этап 2: сбор

На источнике стоит сборщик (Filebeat), который читает новые строки и отправляет их дальше. Сбор — это про надёжность: запомнить, до какого места в файле уже прочитано, не потерять строки при перезапуске, не отправить одно и то же дважды. Сборщик должен быть лёгким, чтобы не воровать ресурсы у самого приложения.

Этап 3: обработка

Сырая строка лога бесполезна для аналитики, пока она строка. Обработка превращает её в структуру: из 192.168.1.10 - - [24/Jun/2026:14:32:07] "GET /api HTTP/1.1" 500 234 извлекаются поля client_ip, method, path, status, bytes. Здесь же логи обогащаются (геолокация по IP), приводится время, отбрасывается мусор. Это работа Logstash или ingest-пайплайнов Elasticsearch.

  сырая строка:
  192.168.1.10 - - [24/Jun/2026:14:32:07] "GET /api" 500 234

  после обработки:
  { client_ip: 192.168.1.10, method: GET,
    path: /api, status: 500, bytes: 234,
    "@timestamp": 2026-06-24T14:32:07Z }

Этап 4: хранение

Структурированное событие записывается в Elasticsearch и индексируется. Логи кладут в индексы, разбитые по времени (например, по дням), — это упрощает удаление старых данных и ускоряет поиск по диапазону дат. Об этом — следующий урок.

Этап 5: визуализация

Наконец, в Kibana человек ищет события, строит графики и дашборды, настраивает алерты. Это «лицо» всего конвейера, ради которого и затевались предыдущие четыре этапа.

Как работает под капотом: где гарантируется доставка

Между этапами данные передаются по сети, а сеть и узлы могут падать. Поэтому в надёжных конвейерах между сбором и обработкой ставят буфер — очередь (Kafka или Redis) или встроенную persistent queue Logstash. Если Elasticsearch временно недоступен, события копятся в буфере, а не теряются.

  Filebeat --> [ очередь Kafka ] --> Logstash --> Elasticsearch
                    ^
            здесь события переживут
            падение Elasticsearch

Filebeat дополнительно держит «регистр» (registry) — файл, где помечено, до какого смещения прочитан каждый лог. Поэтому при перезапуске он продолжает с того же места, а не шлёт всё заново и не теряет хвост.

Где обычно теряются логи

Раз уж мы мыслим этапами, полезно знать, на каких стыках логи теряются чаще всего на практике. Первый опасный стык — между источником и сбором: если сборщик не настроен на нужный путь файлов, не имеет прав чтения или файл ротировался быстрее, чем его прочитали, часть строк просто не попадёт в конвейер. Второй — между сбором и обработкой/хранением при сетевых сбоях, и здесь спасает буфер, о котором шла речь. Третий, неочевидный — на этапе обработки: фильтр drop или ошибочное условие могут молча выбросить события, которые вы на самом деле хотели сохранить. Поэтому изменения в правилах обработки на проде всегда тестируют осторожно: легко случайно «отфильтровать» нужный класс логов и обнаружить это лишь во время инцидента, когда их не окажется.

Полезная практика — на каждом этапе иметь способ убедиться, что данные через него проходят. У Filebeat есть собственные метрики (сколько строк прочитано и отправлено), у Logstash — счётчики обработанных и отброшенных событий, у Elasticsearch — скорость индексации. Когда эти счётчики выстроены в цепочку, «исчезновение» логов перестаёт быть детективом: видно, на каком именно этапе число событий упало до нуля.

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

Чинить не тот этап. «Логи не видны в Kibana» — сначала проверьте по этапам: доходят ли до ES вообще (этап 4) или проблема в сборе (этап 2). Слепое перенастраивание Kibana не поможет, если данные не дошли до хранилища.
Конвейер без буфера на проде. Прямая связка Filebeat → Logstash → ES без очереди означает потерю логов при любом сбое ES. Для критичных логов буфер обязателен.
Тяжёлая обработка на источнике. Парсить grok прямо на веб-сервере — значит грузить прод. Обработку выносят на этап 3 на отдельные узлы.

Итоги

Пять этапов: источник → сбор → обработка → хранение → визуализация.
Диагностика сбоев начинается с вопроса «на каком этапе?» — это экономит часы.
Обработка превращает сырую строку в структуру с полями; это ключ к аналитике.
Буфер (Kafka/Redis/persistent queue) между сбором и хранением спасает логи при падении ES.