如何在Prometheus规则文件中按名称编号对比系列指标？

Absolutely! You can absolutely achieve this in Prometheus rules, but you need to fix the many-to-many matching issue first. Let's break down why your original query fails and how to resolve it.

Why Your Original Query Throws an Error #

The "many-to-many matching not allowed" error occurs because Prometheus requires a one-to-one label match when using binary operators like == between two vector selectors. In your original query, both sides return multiple time series (e.g., metric1-value, metric2-value on one side; metric1-value-expected, metric2-value-expected on the other), but there’s no inherent label pairing between the actual and expected metrics. Prometheus can’t automatically map metric1-value to metric1-value-expected just from the name pattern alone.

Solution 1: Dynamic Pairing with label_replace #

If your actual and expected metrics share all identical labels except for __name__ (following the metricN-value/metricN-value-expected pattern), use label_replace to rewrite the expected metric names to match the actual ones. This creates a valid one-to-one label match.

Here’s the corrected PromQL expression:

{__name__=~"metric.*-value"} == label_replace(
  {__name__=~"metric.*-value-expected"},
  "__name__",
  "$1-value",
  "__name__",
  "(metric.*)-value-expected"
)

How this works:

• label_replace extracts the core metric identifier (e.g., metric1) from each expected metric’s name using the regex (metric.*)-value-expected.
• It rewrites the __name__ label to $1-value, turning metric1-value-expected into metric1-value.
• Now both sides of the == operator have identical labels (including __name__), so Prometheus can properly pair each actual metric with its expected counterpart.

Solution 2: Explicit Pairing for Small Metric Sets #

If you only have a handful of metrics (like your 3 examples), it’s often clearer to write explicit comparisons for each pair. This avoids regex complexity and makes your intent immediately obvious:

metric1-value == metric1-value-expected OR 
metric2-value == metric2-value-expected OR 
metric3-value == metric3-value-expected

This approach is straightforward to debug and guarantees you’re pairing exactly the metrics you intend to compare.

Implementing This in Prometheus Rules #

Both approaches work seamlessly in recording or alerting rules. Here are examples for each use case:

Alert Rule (Trigger on Mismatch) #

groups:
- name: metric_validation_rules
  rules:
  - alert: MetricValueMismatch
    expr: |
      {__name__=~"metric.*-value"} != label_replace(
        {__name__=~"metric.*-value-expected"},
        "__name__",
        "$1-value",
        "__name__",
        "(metric.*)-value-expected"
      )
    for: 2m
    annotations:
      summary: "Mismatch in {{ $labels.__name__ }}"
      description: "Actual value: {{ $value }} | Expected value: {{ label_replace({__name__=~\"metric.*-value-expected\"}, \"__name__\", \"$1-value\", \"__name__\", \"(metric.*)-value-expected\") }}"
    labels:
      severity: warning

Recording Rule (Capture Matching Metrics) #

groups:
- name: metric_matches_recording
  rules:
  - record: metric:matches_expected
    expr: |
      {__name__=~"metric.*-value"} == label_replace(
        {__name__=~"metric.*-value-expected"},
        "__name__",
        "$1-value",
        "__name__",
        "(metric.*)-value-expected"
      )

Either approach will solve your problem—pick the one that best fits the number of metrics you’re working with and your preference for readability vs. dynamism.

内容的提问来源于stack exchange，提问作者arodrprope