Опишите фактическую цепочку: источники логов, сборщик, преобразования, доставка, хранилище и поиск. Назовите свою роль и реальные параметры хранения. Шардирование делит данные на части; в Elasticsearch индекс распределяется по primary shards, а replicas являются их копиями. Стратегию индексов объясняют объёмом, запросами, сроками хранения и доступом, не подставляя вымышленный стек.
Где хранились и как собирались логи? Что такое шардирование и какую стратегию индексов вы использовали?
Как описать реальный путь логов от приложения до поиска, свой вклад и выбранное разбиение данных. Elasticsearch приведён только как условный пример.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Начните с реально использованной системы и своей роли. Возможно, вы только искали события, а сбор и хранение настраивала другая команда. Это нужно сказать прямо, а не приписывать себе проектирование всей платформы.
Рассказ удобно строить по пути одного события:
- Источник: приложение пишет структурированный лог в файл, стандартный вывод или передаёт событие другим способом.
- Сбор: какой агент или механизм забирает записи, откуда берутся имя сервиса, окружение и время.
- Обработка и доставка: где разбирается формат, скрываются секреты, работают буферы и повторные попытки. Объясните известное поведение при недоступности хранилища, не обещая отсутствие потерь без доказательств.
- Хранение и поиск: какая система сохраняет события, кто имеет доступ, как задаётся срок хранения и как находят связанный запрос по идентификатору.
Условный пример, а не готовая биография: если использовали Elasticsearch, индекс представляет логическую коллекцию документов. Шардирование распределяет её данные между первичными шардами; replica shard — копия первичного, а не ещё одна независимая часть данных. Шарды размещаются на узлах, но шард не равен отдельному серверу. См. архитектуру Elasticsearch.
Расскажите, как выбирали группировку: по типу событий, приложению, окружению или требованиям доступа; использовали ли временные индексы либо data streams с rollover. Для data stream есть последовательность backing indices и шаблон их настроек — документация Elastic. Не называйте индекс Elasticsearch аналогом B-tree-индекса по одному столбцу.
Обоснуйте решение фактическими объёмами поступления, характерными запросами, размером шардов и политикой хранения. Если точных значений не знаете, обозначьте границу знания. Завершите одним реальным компромиссом: например, почему не создавали отдельный индекс для каждого малонагруженного приложения, если именно такой выбор действительно обсуждался.