kubernetes - 某些 Prometheus 警报最终显示为“未分组”

Question

我在 AKS 1.19.9 上使用 Prometheus Alertmanager (bitnami/alertmanager:0.21.0) 运行 Prometheus (bitnami/prometheus:2.25.2)。
警报由 Alertmanager 处理，后者又将警报路由到松弛通道。

我注意到最近某些警报最终出现在 Prometheus Alertmanager WebUI 中的“未分组”部分，并且没有进入 Slack 频道。

我无法解释这一点，因为它们按 [cluster, alertname] 分组并且确实包含这些标签（在屏幕截图中模糊，但 cluster 包含相同的值）。

为了使事情更加混乱（无论如何对我来说），某些警报也具有这些标签并且被正确发送。

配置中的警报管理器路由树：

spec:
  route:
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 3h
    receiver: fallback
    routes:
    - matchers:
      - name: team
        value: platform-engineering
      groupBy: [cluster, alertname]
      receiver: fallback
      routes:
      - matchers:
        - name: severity
          value: critical
        groupBy: [cluster, alertname]
        receiver: alerts-critical
      - matchers:
        - name: severity
          value: warning
        groupBy: [cluster, alertname]
        receiver: alerts-warning

有人关心这里有什么问题吗？我显然错过了一些东西:-)
非常感谢提前！

标签： kubernetesprometheusazure-aksprometheus-alertmanager

Answer 1

认为我发现了问题。集群上运行的 Prometheus 由 Prometheus 算子配置：上面列出的路由树是部署前bitnami/prometheus-operator:0.53.1 查看 Prometheus Alert manager 配置时看到的。

但是……当您在部署后访问 Prometheus Alert manager WebUI并单击页面顶部的“状态”选项卡时，它讲述了一个不同的故事。我发现运营商在部署期间向路由树中注入了一个额外的匹配器。

这显然会对警报的匹配和分组产生影响，特别是如果击中路由树的警报不是源自命名空间监控。

在我的例子中，只有监控工作负载驻留在此处，并且大部分工作负载来自监控之外的命名空间。

阅读Prometheus Operator repo 上的GitHub issue 3737 ，证实了这一怀疑。

作为一种解决方法，我尝试了 Till Adam 的建议：

kind: clustermanagement
namespace: prometheus
source_namespace: '{{ $labels.namespace }}'

有了这个，我们在 prometheus 命名空间中有一个 alertmanagerconfig 负责所有与集群相关的警报，无论指标最初具有什么命名空间标签。

请注意，使用此功能时也应调整您的警报规则！发出警报的实际命名空间现在位于source_namespace.

我遇到的唯一边缘情况是您最终丢失了命名空间标签。这似乎发生在警报表达式使用聚合运算符（例如计数）时。

如果我没记错的话， PR3821将为这个挑战引入修复（全局 alertmanagerconfig）。