Что такое ELK (Elasticsearch, Logstash, Kibana)
Что проверяют
Умеете ли вы отдавать логи в централизованное хранилище и потом ими пользоваться, а не искать проблему через print и кучу файлов. Для питониста вопрос прикладной: как устроен путь строки от приложения до дашборда и кто на этом пути за что отвечает.
Как отвечать
Три роли. Elasticsearch хранит и ищет: записи попадают в индексы, поиск идёт по инвертированному индексу, поэтому фильтр по полю быстрый. Logstash принимает поток, разбирает, обогащает и кладёт в хранилище. Kibana даёт поиск, дашборды и оповещения поверх этих данных.
Сильный ответ добавляет, что сейчас связку чаще называют Elastic Stack и Logstash в ней не обязателен: лёгкий агент (Filebeat, Vector, Fluent Bit) читает файлы или journald и шлёт напрямую, не таская за собой JVM. Приложение на Python в идеале про стек ничего не знает: оно пишет структурированный JSON в stdout через python-json-logger или structlog, а доставка это забота инфраструктуры.
Что стоит назвать по существу: в каждой записи уровень, имя логгера, идентификатор запроса или трассировки, чтобы связать строки одного вызова; индексы нарезаются по дате и живут по политике хранения, иначе диск кончится незаметно; секреты и персональные данные в логи не попадают, потому что доступ к Kibana шире, чем к базе.
Где спотыкаются
Пишут в Elasticsearch прямо из обработчика запроса синхронным клиентом. Кластер притормозил, и вместе с ним встало приложение. Доставкой занимается агент, а буфером служит файл или брокер.
Логируют человеческую строку, а потом разбирают её регулярками в Logstash. Такой разбор дорогой и ломается при первой же правке текста сообщения, поэтому структуру задают на стороне приложения.
Заводят стек и забывают про объём: индексы растут, число шардов уходит в тысячи, кластер деградирует. Срок хранения, размер шарда и политика переноса в холодное хранилище обсуждаются до внедрения, а не после падения.