PromQL: первая пара запросов

Условий в фигурных скобках всего четыре вида, и их стоит выучить наизусть, потому что встречаются они в каждом запросе. Точное равенство status="500" оставляет серию с конкретным значением. Неравенство status!="200" выбрасывает успешные ответы и оставляет всё остальное — включая редкие коды, которые вы забыли перечислить. Регулярка со знаком равенства status=~"5.." выбирает по шаблону, а с восклицательной тильдой status!~"2.." — всё, что шаблону не подходит: так собирают трафик неуспеха без перечисления кодов. Важная деталь, о которую спотыкаются пришедшие из других языков: регулярки PromQL полностью заякорены от начала и до конца, то есть 5.. означает ровно три символа, начинающихся с пятёрки, и ничего лишнего. Комбинировать условия можно сколько нужно, перечисляя через запятую: route="/api",status=~"5.." — пятисотые одного маршрута.

rate(counter[5m]) считает среднюю скорость роста счётчика в секунду на пятиминутном окне: берёт значения внутри окна, учитывает сбросы после рестартов и экстраполирует результат на края. Для счётчиков это главный инструмент — rate prometheus рекомендует практически всегда, когда хочется увидеть «сколько в секунду», от запросов до заказов. У окна два жёстких требования. Первое: внутри должно лежать хотя бы две точки, иначе результат пустой — при скрейпе раз в 30 секунд окно короче минуты бессмысленно, а сразу после старта сервиса графики будут молчать пару минут. Второе: длина окна выбирается под скорость изменений, и практический минимум — четыре скрейп-интервала: при интервале 15 секунд берите не меньше минуты, при интервале 30 — не меньше двух. К gauge функция rate неприменима по смыслу: датчик не монотонный, и «скорость роста» температуры ничего не значит. Для gauge есть своё семейство: avg_over_time, max_over_time и min_over_time усредняют или выбирают экстремум по окну, не претендуя на счётную природу значения.

Доля ошибок — это пятисотые, поделённые на весь трафик:

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Хитрость в том, что PromQL делит векторы, а не числа: каждой серии левого запроса ищется пара справа по совпадающим лейблам. Если слева серии с лейблами route и status и справа — тоже route и status, пары найдутся не для всех: статуса 500 нет среди серий «всего трафика» с тем же лейблом status, и часть делений развалится. Поэтому сначала суммируют: sum(...) схлопывает векторы до одного элемента без лейблов, и деление становится простым. Хотите долю ошибок по маршрутам — суммируйте с группировкой с обеих сторон: sum by (route) в числителе и в знаменателе, и группировка обязана совпадать, иначе векторы снова не найдут пары. С нулями поведение такое: если знаменатель пуст — серий нет — результат пустой; если знаменатель ноль при ненулевом числителе — плюс бесконечность, и Grafana рисует разрыв. Ночной сервис без трафика с честно разорванным графиком — норма, а не баг.

sum — не единственная агрегация, и остальные полезно держать в голове, потому что отвечают они на другие вопросы. count(http_requests_total) вернёт число серий: моментально видно, сколько комбинаций лейблов породил сервис — быстрый тест на кардинальность. avg усредняет значения серий и годится для датчиков вроде числа горутин по инстансам, но не для счётчиков: средний счётчик — бессмысленная величина, когда инстансы живут разное время. min и max находят крайности: max по инстансам покажет самого нагруженного узла. Отдельно стоит topk(3, rate(...)) — топ три серии по значению: быстрый способ найти самый горячий маршрут без разглядывания линий. Без группировки все серии складываются в одну. Все агрегации принимают необязательную группировку by или without: без (instance) складывает всё, кроме инстансов, — удобный способ увидеть кластер целиком, не перечисляя остальные лейблы руками.

increase(counter[1h]) отвечает на вопрос «сколько за час»: та же скорость, умноженная на длину окна; его место — графики «заказов за день» и «ошибок за неделю». irate(counter[5m]) — мгновенная скорость по двум последним точкам: она реагирует на всплески раньше rate, но и дёргается от каждого скрейпа, поэтому для дашбордов и алертов берут rate, а irate оставляют для разбора инцидента в реальном времени. Отдельного внимания заслуживает поведение после рестарта: счётчик обнуляется, и rate трактует уменьшение как сброс, прибавляя остаток прошлого значения — трафик между последним скрейпом до смерти и первым после подъёма учтён. На коротких окнах это выглядит как единичный выброс, и это честная цена данных: процесс не мог сообщить ничего между падением и подъёмом. С длиной окна связана и самая частая жалоба на свежем дашборде — дрожащая линия. При скрейпе раз в 30 секунд окно в минуту содержит всего две-три точки: каждая новая перестраивает расчёт радикально, и линия скачет. Правило четырёх скрейп-интервалов спасает: окно от двух минут при 30-секундном скрейпе даёт четыре-пять точек, и rate становится устойчивым. Обратная крайность — слишком длинное окно: час сглаживает всё, включая инцидент, и вы увидите аварию через полчаса после пользователей. Рабочая связка: дашборды смотрят на окна пять-пятнадцать минут ради читаемости, алерты считают на окнах одна-две минуты ради скорости обнаружения, а дрожь внутри них гасит for. Если сомневаетесь — поднимите окно вдвое и сравните: изменение формы графика при том же трафике означает, что дело в окне, а не в сервисе.