Как реализовано логирование в Kibana и откуда берутся данные

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

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

Как отвечать

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

• приложение: Python пишет логи через стандартный logging, но в JSON, а не строкой. Для этого есть python-json-logger, structlog или ecs-logging, который сразу раскладывает поля по схеме ECS. В контейнере логи идут в stdout;
• сборщик: Filebeat или Elastic Agent читает stdout контейнеров или файлы и отправляет дальше. Альтернативы: Fluent Bit или Vector;
• обработка: Logstash или ingest pipeline в самом Elasticsearch. Там парсят неструктурированные строки через grok, добавляют поля, отбрасывают мусор. С JSON-логами этот шаг заметно проще;
• хранение: Elasticsearch кладёт логи в data stream с индексами по времени, политика ILM переводит старые данные на дешёвые узлы и удаляет их по сроку;
• Kibana: data view (раньше index pattern) указывает, какие индексы смотреть. В Discover ищут через KQL, например service.name : "billing" and log.level : "error", дашборды собирают в Lens.

Отдельно упомяните корреляцию: middleware генерирует trace_id или берёт его из входящего заголовка, кладёт в contextvars, а фильтр логгера добавляет его в каждую запись. Тогда запрос через три сервиса находится одним поиском. Если в команде OpenSearch, схема та же, а интерфейс называется OpenSearch Dashboards.

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

Говорят «логирование в Kibana». Kibana только витрина, данные в Elasticsearch кладут Beats, Logstash или само приложение.

Пишут логи f-строками и потом мучаются с grok. Без отдельных полей нельзя отфильтровать записи по пользователю или коду ответа.

Не думают про объём и чувствительные данные: логируют тела запросов с паролями и токенами, не настраивают ILM, и через месяц кластер упирается в диск.