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

Путь строки лога от сервиса до графика в Kibana состоит из нескольких этапов, и на каждом может что-то сломаться. Если понимать эти этапы, становится ясно, куда смотреть, когда в Kibana пропали логи, и почему в больших системах между агентами и Logstash ставят Kafka.

Пять этапов

Конвейер логов состоит из пяти этапов:

1. Сбор. Приложение пишет строку в файл или stdout, агент на сервере (Filebeat) её читает. Риск: агент не запущен или читает не тот файл.
2. Доставка. Агент отправляет события дальше по сети. Риск: сеть или получатель недоступны, и событиям надо где-то подождать.
3. Обработка. Logstash разбирает строки на поля, правит время, обогащает, отбрасывает шум. Риск: шаблон grok не подошёл, событие ушло сырым или потерялось в фильтре.
4. Хранение. Elasticsearch индексирует и хранит. Риск: кончилось место, документ отклонён из-за типа поля, индекс переполнен полями.
5. Анализ. Kibana ищет и показывает. Риск: неправильный data view или поле времени, и события «не видны», хотя они есть.

Буфер между этапами

Этапы работают с разной скоростью. Во время инцидента сервисы пишут в десять раз больше ошибок, чем обычно, а Elasticsearch не успевает индексировать. Что делать с лишними событиями? Выбрасывать нельзя: именно они нужны для разбора.

Поэтому между этапами нужен буфер:

• Filebeat сам по себе буфер: файл лога на диске. Если Logstash недоступен, агент просто не двигается дальше по файлу и ждёт;
• Logstash держит очередь в памяти, а с queue.type: persisted на диске. Тогда события переживут и перезапуск самого Logstash;
• Kafka между агентами и Logstash это буфер на дни. Агенты пишут в тему, Logstash читает в своём темпе. Если Logstash или Elasticsearch лежат час, события копятся в Kafka и потом дочитываются. Про Kafka есть целый блок.

Типичная схема большой системы: Filebeat → Kafka → Logstash → Elasticsearch → Kibana.