Выбор стека логов
Вопрос
Интервьюер: «У нас 3 ТБ логов в день, Elasticsearch-кластер из 30 узлов дорогой и часто краснеет. Что бы вы сделали?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Измерить: какие источники дают объём, какие запросы реально делают
Сократить объём: мусор на агенте, уровни, сэмплирование, ретеншн по типам
Разделить: горячие недавние логи и дешёвый архив в объектном хранилище
Сравнить варианты: Loki, ClickHouse, OpenSearch с ILM, по стоимости и сценариям поиска
Миграция поэтапно, двойная запись на время перехода
Метрики вместо логов там, где считают частоты
Что могут спросить следом
- Какие сценарии поиска ухудшатся при переходе на Loki?
- Как не потерять логи во время миграции?
Разбор
Образцовый ответ: «Сначала разберу, откуда 3 ТБ: обычно 20% источников дают 80%, часто это access-логи, health-check и DEBUG, который забыли выключить. Режу на агенте и договариваюсь об уровнях, это может дать половину объёма. Затем смотрю, как ищут: если в основном по сервису, времени и trace_id, хорошо подходит Loki с объектным хранилищем, он в разы дешевле. Если нужна тяжёлая аналитика по полям, ClickHouse. Если остаёмся на OpenSearch, то ILM с горячими и тёплыми узлами и короткий ретеншн для шумных индексов. Переходим постепенно: агент пишет в оба хранилища, сравниваем полноту и скорость, переводим команды, потом выключаем старое. Честно предупреждаю, что полнотекстовый поиск по месяцу в Loki медленнее».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.