Приходилось ли писать PromQL запросы

Что проверяют

Отличаете ли вы чтение готовых дашбордов от работы с метриками. Для Go-разработчика это прикладной навык: сервис инструментируете вы сами, и от того, как названы и размечены метрики, зависит, можно ли вообще написать нужный запрос.

Как отвечать

Начните с типов метрик, из них следует всё остальное: счётчик только растёт и обнуляется при перезапуске, датчик меняется в обе стороны, гистограмма раскладывается по накопительным корзинам. Дальше покажите типовые запросы:

• скорость запросов: sum(rate(http_requests_total[5m])) by (handler);
• доля ошибок как отношение двух скоростей по одному окну;
• квантиль задержки: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le));
• насыщение: avg_over_time по датчику, например по числу горутин или занятой памяти.

Важное правило: rate применяется к счётчику первым, суммирование идёт снаружи. Функция сама учитывает обнуление счётчика при рестарте пода, а суммирование до неё этот приём ломает. Окно берут не меньше четырёх интервалов сбора, иначе внутри него может не оказаться двух точек и график станет дырявым.

Для Go добавьте, что даёт стандартный сборщик метрик: число горутин, паузы сборщика мусора, занятая память процесса, открытые дескрипторы. Это первое, куда смотрят при разборе утечки. Полезно упомянуть алерты: условие плюс выдержка по времени, чтобы одиночный всплеск не будил дежурного.

Где спотыкаются

Читают rate как количество событий за окно. Это средняя скорость в секунду, а число событий даёт increase. Ошибка тихая: дашборд рисуется, просто цифры на нём неверные в разы.

Кладут в метку идентификатор пользователя, полный путь запроса или номер заказа. Каждое новое значение это отдельный ряд, и хранилище распухает до отказа. У метки должен быть ограниченный набор значений.

Считают квантиль по каждой реплике и усредняют результат. Среднее от квантилей квантилем не является. Складывать надо корзины через sum(rate(...)) by (le), а квантиль брать уже от суммы.