Prometheus Kubernetes 服务发现配置重载失效

概述

在 Kubernetes 环境中，使用 Prometheus 监控系统时，通过 kubernetes_sd_config 自动发现 Alertmanager 实例是一种常见且推荐的做法。然而，根据一个已知问题报告，Prometheus 对 alerting.alertmanagers 部分配置的动态重载可能无法按预期工作。具体表现为，Prometheus 仅在启动时执行服务发现，此后如果 Alertmanager Pod 发生重建（导致其 IP 地址变化），Prometheus 不会自动发现新的实例，从而影响告警路由的可靠性与系统的可观测性。理解此问题的机制对于保障 SRE 团队告警管道的连续性至关重要。

核心概念

Prometheus 配置重载：Prometheus 支持多种方式重载配置，包括发送 SIGHUP 信号、调用 /-/reload 端点或使用 --config.file 标志重启。重载时，Prometheus 会重新解析配置文件并应用更改。
kubernetes_sd_configs：Prometheus 内置的服务发现机制之一。它通过 Kubernetes API 实时监听指定资源（如 Pod、Service）的变化，并将发现的目标注入到抓取配置中。
静态配置 vs. 动态发现：在 alerting.alertmanagers 列表中，每个条目既可以包含静态的 static_configs，也可以包含动态的发现机制如 kubernetes_sd_configs。问题报告指出，对于 alertmanagers 配置中的动态发现部分，Prometheus 在初始加载后可能停止更新。

实践

问题验证与排查

确认服务发现状态：可以通过 Prometheus 的 /-/service-discovery 端点查看 kubernetes_sd 发现的目标。如果在 Alertmanager Pod 变化后，此端点的列表未更新，则证实了问题。
检查配置重载：修改一个与 alertmanagers 无关的抓取任务配置，触发重载（例如调用 /-/reload）。观察 /-/service-discovery 中 kubernetes_sd 发现的目标是否刷新。根据报告，对于 alertmanagers 配置，它很可能不会刷新。

解决方案与最佳实践

使用标准重载机制：尽管存在上述问题，但通过 SIGHUP 或 HTTP 端点触发的配置重载，仍然是管理 Prometheus 配置的主要方式。对于此特定问题，可能需要等待官方修复。
配置告警路由使用静态地址（变通方案）：如果 Alertmanager 集群地址稳定，可以暂时使用 static_configs 指定其 Kubernetes Service 的 DNS 名称，而非直接发现 Pod IP。这避免了动态发现，但牺牲了部分灵活性。

利用 Kubernetes Service 进行发现（推荐）：调整 kubernetes_sd_configs 的 role 为 endpoints 或 ingress，通过发现 Kubernetes Service 或 Ingress 来间接发现 Alertmanager。由于 Service 的 ClusterIP 或 Ingress 地址相对稳定，这能更好地适应 Pod 重建。

alerting:
  alertmanagers:
    - kubernetes_sd_configs:
        - role: endpoints
          namespaces:
            names:
              - monitoring
      relabel_configs:
        - source_labels: [__meta_kubernetes_service_label_app]
          regex: alertmanager
          action: keep
        - source_labels: [__meta_kubernetes_endpoint_port_name]
          regex: web
          action: keep

SRE 要点

对可靠性的影响：此问题直接威胁告警管道的可靠性。如果 Prometheus 无法发现新的 Alertmanager，告警可能无法被路由到正确的处理器，导致告警丢失或延迟，违背了 SRE 对错误预算（Error Budget）的承诺。
最佳实践：
- 在 Kubernetes 中部署 Prometheus 和 Alertmanager 时，优先考虑使用 Service 来提供稳定的访问点。
- 定期验证服务发现和配置重载的有效性，将其纳入运维检查清单。
- 监控 Prometheus 自身的目标（up{job="prometheus"}）以及告警路由的成功率。
相关指标：
- SLI: prometheus_notifications_sent_total（发送给 Alertmanager 的通知总数）和 prometheus_notifications_failed_total（发送失败的通知数）。通知失败率的突然上升可能间接反映了路由问题。
- 运维检查: 定期检查 /-/service-discovery 和 /-/config 端点，确保配置和发现状态符合预期。

通过采用更稳定的服务发现角色（如 endpoints）并监控关键的告警发送指标，SRE 团队可以缓解此问题带来的风险，确保监控系统的稳健性。