Как логи попадают в ELK стек

Что проверяют

Понимаете ли вы путь записи от приложения до экрана в Kibana и можете ли по этому пути найти, где запись потерялась. Для тестировщика это практический вопрос: следом обычно спрашивают, что делать, если лог в Kibana не появился.

Как отвечать

Проведите запись по цепочке:

• приложение: пишет в файл или в stdout, удобнее всего сразу в JSON. У Java-сервисов для этого есть logstash-logback-encoder;
• сборщик: Filebeat или Elastic Agent читает файлы, запоминает смещение и после перезапуска продолжает с того же места. В Kubernetes его разворачивают как DaemonSet, и он читает логи контейнеров с каждой ноды. Вместо него встречается Fluent Bit;
• обработка: Logstash принимает события от Beats (обычно на порту 5044), разбирает строку фильтрами grok, json, date, mutate и отправляет в Elasticsearch. Logstash не обязателен: простой разбор делает ingest pipeline прямо в Elasticsearch. При больших объёмах между сборщиком и Logstash ставят Kafka как буфер;
• хранение: Elasticsearch кладёт события в индексы или data streams, старые данные удаляет политика ILM. Поиск почти в реальном времени: по умолчанию индекс обновляется раз в секунду;
• просмотр: Kibana только читает. В Discover выбираете data view, диапазон времени и пишете запрос на KQL.

Тот же конвейер часто собирают на OpenSearch, форке Elasticsearch и Kibana, принцип у него такой же.

Где спотыкаются

Думают, что приложение шлёт логи в Kibana. Kibana ничего не собирает и не хранит, это витрина над Elasticsearch.

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

Не могут объяснить, куда пропал лог. Проверять стоит по порядку: дошёл ли файл до сборщика, нет ли у события тега _grokparsefailure, правильно ли разобрано поле @timestamp и не смотрите ли вы не в тот временной диапазон.