Logo Craft Homelab Docs Контакты Telegram
Prometheus vector matching: тёмная сторона PromQL, которая ломает алерты Трендовые github проекты в нашем телеграм канале. Подпишись →
26 апреля 2026 г.

Prometheus vector matching: тёмная сторона PromQL, которая ломает алерты

PromQL кажется простым, пока запросы ограничены rate() и фильтрами по label. Сложность начинается, когда нужно сравнить или объединить два набора временных рядов. Здесь появляется vector matching — механизм мощный, но неочевидный. Ошибка в сопоставлении может дать пустой результат, раздуть количество рядов или сломать алерт.

Для SRE и DevOps-инженера понимание vector matching важно так же, как знание rate и histogram_quantile.

Labels решают всё

Prometheus сопоставляет ряды по labels. Если labels не совпадают, операция между векторами может не вернуть ничего. Если labels совпадают слишком широко, получится неоднозначность.

Например, CPU usage по pod нужно сопоставить с resource limits. Если в одном векторе есть container, а в другом нет, результат будет не тем, что ожидалось.

One-to-one

Самый простой случай: одному ряду слева соответствует один ряд справа. Prometheus сам сопоставит их по общим labels. Но даже тут полезно явно использовать on() или ignoring(), чтобы запрос был читаемым.

metric_a / on(instance) metric_b

Так видно, по какому ключу происходит join.

Many-to-one

Часто нужно сопоставить много рядов с одним. Например, несколько container metrics с одной pod-level метрикой. Для этого используются group_left или group_right.

Ошибки здесь опасны: можно случайно размножить ряды или потерять labels. Лучше сначала проверить обе стороны запроса отдельно и только потом добавлять join.

Практика отладки

Правила:

  • сначала вывести левый вектор;
  • потом правый;
  • проверить labels;
  • добавить on() явно;
  • проверить cardinality;
  • только потом использовать в alert rule.

Для сложных запросов полезно сохранять recording rules. Они упрощают алерты и снижают нагрузку.

Итог

Vector matching — одна из тех частей PromQL, которые редко нужны в начале, но становятся критичными в production observability. Если понимать labels, cardinality и group_left/group_right, запросы становятся предсказуемыми.

Хороший PromQL-запрос должен быть не только правильным, но и объяснимым для инженера, который будет разбираться с алертом ночью.