Запрос врёт: разбор
Вопрос
Интервьюер: «Дашборд показывает p99 = 1 секунда ровно уже неделю, а пользователи жалуются на 3-4 секунды. Доля ошибок на дашборде то 0, то 100%. Что может быть не так с запросами?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
p99 упирается в верхнюю границу конечного бакета: квантиль в +Inf, нужны бакеты шире
Возможна потеря `le` или агрегация не по тем меткам
Доля ошибок 0 или 100%: деление без sum, ряды делятся сами на себя или не сопоставляются
Проверить окно rate относительно интервала опроса
Сверить с независимым источником: логи балансировщика, трейсы
Исправить инструментирование и добавить тест на запросы (promtool)
Что могут спросить следом
- Как выбрать границы бакетов?
- Как проверять правила и запросы в CI?
Разбор
Образцовый ответ: «Ровно 1 секунда неделю подряд почти наверняка означает, что последний конечный бакет 1 секунда, а запросы дольше попадают в +Inf: histogram_quantile в таком случае возвращает верхнюю конечную границу. Смотрю _bucket напрямую: если le="1" заметно меньше le="+Inf", так и есть, добавляю бакеты 2.5, 5, 10. Скачки доли ошибок между 0 и 100% выдают деление без агрегации: ряд 500 делится сам на себя, а когда ошибок нет, рядов в числителе нет вовсе. Переписываю с sum в обеих частях и or vector(0) для пустого числителя, если нужен ноль. Проверяю, что окно rate не меньше четырёх интервалов опроса. Сверяю с логами балансировщика. И добавляю unit-тесты правил через promtool test rules, чтобы такие вещи ловились в CI».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.