Как работают Logstash и Kibana

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

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

Как отвечать

Сначала расставьте роли: Elasticsearch хранит и индексирует, Logstash обрабатывает, Kibana показывает. Сама Kibana данных не хранит.

Logstash это конвейер из трёх стадий, описанных в конфиге пайплайна:

• input: откуда читать. Чаще всего beats (события от Filebeat), kafka, tcp, http;
• filter: разбор и обогащение. grok разбирает текстовую строку шаблонами на регулярных выражениях, json раскладывает готовый JSON, date переносит время события в @timestamp, mutate переименовывает и удаляет поля;
• output: куда писать, обычно elasticsearch, иногда kafka.

Между стадиями стоит очередь. По умолчанию она в памяти, и при падении процесса события теряются; queue.type: persisted включает очередь на диске. Logstash работает на JVM и тяжёл, поэтому на серверах приложений ставят лёгкий Filebeat или Elastic Agent, а Logstash держат отдельно. При больших объёмах перед ним ставят Kafka как буфер.

Kibana: в Discover вы ищете по KQL (service.name : "orders" and log.level : "ERROR"), для этого нужен data view на нужные индексы. Дальше дашборды в Lens и алерты.

Со стороны Java стоит сказать о формате. Лучше сразу писать JSON: logstash-logback-encoder для Logback или встроенное структурированное логирование свежих версий Spring Boot. Идентификатор трассировки кладите в MDC, тогда в Kibana один фильтр по trace.id соберёт весь запрос.

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

Считают Logstash обязательным. Простой разбор умеют ingest pipelines самого Elasticsearch, и Filebeat может писать туда напрямую.

Пишут стектрейсы обычным текстом: каждая строка трейса становится отдельным событием. Лечится JSON-логами или настройкой multiline в Filebeat.

Забывают про объём: без политики жизненного цикла индексов (ILM) диск кластера заканчивается за несколько недель, а сложный grok съедает CPU там, где хватило бы JSON.