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

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

Понимаете ли вы весь путь записи от вызова log.info() до строки в Kibana и где на этом пути данные теряются или портятся. Следом обычно спрашивают, что будет с логами, если Logstash или Elasticsearch недоступны.

Как отвечать

Разложите цепочку по звеньям:

• приложение: код пишет через фасад SLF4J, а реализует его Logback (по умолчанию в Spring Boot) или Log4j2;
• формат: лучше сразу JSON, например LogstashEncoder из logstash-logback-encoder или ECS-формат. Стектрейс тогда остаётся одним документом, а поля не нужно выковыривать регулярками. В MDC кладут traceId, Spring Boot 3 с Micrometer Tracing делает это сам;
• вывод: в контейнерах stdout, в классических установках файл с ротацией;
• доставка: Filebeat или Elastic Agent читает файлы или логи контейнеров, запоминает позицию и шлёт дальше. Если получатель недоступен, он повторяет отправку, а не теряет данные;
• обработка: Logstash с конвейером input, filter, output: вход beats слушает порт 5044, grok разбирает текст, json и date приводят поля и время. Простой разбор можно сделать ingest pipeline прямо в Elasticsearch;
• хранение: data stream с политикой ILM, которая делает rollover и удаляет старое, вместо ручных ежедневных индексов;
• просмотр: Kibana, Discover и data view на нужные индексы.

При большом потоке между доставкой и Logstash ставят Kafka как буфер. Прямой LogstashTcpSocketAppender из приложения тоже возможен, но при сбое сети логи копятся в памяти процесса или выбрасываются.

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

Говорят, что SLF4J пишет лог-файлы. Это фасад: без Logback или Log4j2 в classpath он предупреждает об отсутствии провайдера и молчит.

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

Не настраивают ILM. Индексы копятся, диск заполняется, и после порога заполнения Elasticsearch переводит индексы в режим только для чтения.