Наблюдаемость для 100 микросервисов
Вопрос
Интервьюер: «В компании 100 микросервисов, у каждой команды свой мониторинг, разбор инцидентов занимает часы. Как бы вы построили единую наблюдаемость?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Стандарт: общие метки (service, env, version, team), именование метрик, формат логов
Единый сбор через OpenTelemetry SDK и Collector, авто-инструментирование
Хранилища: метрики (Prometheus плюс долгое хранение), логи, трейсы, связанные между собой
Шаблонные дашборды RED и USE и SLO для каждого сервиса из коробки
Управление стоимостью: лимиты кардинальности, сэмплирование, ретеншн
Измеримый результат: время обнаружения и разбора инцидентов
Что могут спросить следом
- Как убедить команды перейти на стандарт?
- Что делать с сервисами, которые нельзя переписать?
Разбор
Образцовый ответ: «Сделаю наблюдаемость платформенным продуктом. Сначала стандарт: обязательные метки service, env, version, team, правила именования метрик, JSON-логи с trace_id. Сбор через OpenTelemetry: SDK в шаблоне сервиса и авто-инструментирование, Collector как агент на узлах и как шлюз, он же делает сэмплирование и фильтрацию. Метрики в Prometheus с долгим хранением в VictoriaMetrics или Mimir, логи в Loki, трейсы в Tempo, всё в одной Grafana с переходами по exemplars и trace_id. Каждый сервис при создании получает готовый дашборд RED, USE и SLO и базовые алерты. Стоимость под контролем лимитов кардинальности и сэмплирования. Успех меряю временем от алерта до понимания причины на реальных инцидентах. Легаси без переписывания закрываю внешними метриками балансировщика и логами».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.