Разбор медленного запроса по трейсам
Вопрос
Интервьюер: «p99 оформления заказа вырос с 400 мс до 2 секунд после пятничного релиза. Как вы будете искать причину с помощью трейсов?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
От метрики к трейсам: exemplars на графике p99 или поиск трейсов длиннее 1.5 с
Сравнить медленные трейсы с быстрыми и старой версией: какие спаны выросли
Собственное время спана против ожидания зависимостей
Атрибуты: версия, под, маршрут, размер данных, повторные вызовы (N+1)
Проверить логи медленных трейсов по trace_id
Подтвердить гипотезу и откатить или исправить, проверить по метрике
Что могут спросить следом
- Что если медленные трейсы не попали в сэмплинг?
- Как отличить медленный код от медленной базы?
Разбор
Образцовый ответ: «Открываю график p99 и кликаю exemplar на пике, либо в Tempo ищу TraceQL-запросом трейсы оформления длиннее 1.5 секунды с новой версией. Сравниваю с быстрым трейсом до релиза. Обычно сразу видно, какой спан вырос: например, вместо одного запроса в базу их стало 80 подряд, классический N+1 после рефакторинга, или новый синхронный вызов в сервис рекомендаций с таймаутом. Смотрю собственное время спана: если оно большое, а дети быстрые, проблема в коде сервиса, и тут нужен профилировщик. Проверяю логи этого trace_id. Гипотезу подтверждаю метрикой по версиям: если p99 вырос только у новой версии, откатываю и чиню. Если медленные трейсы не сохранились, это повод включить tail-sampling на медленные запросы».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.