修复 Prometheus 命名空间监控

Source: Dev.to

The Setup

我在一个使用 Prometheus Operator 的 Kubernetes 集群上运行，并采用了相当标准的发现模式：

• ServiceMonitor 对象
• 基于 Namespace 的抓取选择
• 下游的 Grafana 仪表盘和 Alertmanager 规则

关键点在于 Prometheus 只会抓取带有特定标签的命名空间。

下面是简化后的 ServiceMonitor 示例：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-servicemonitor
spec:
  selector:
    matchLabels:
      app: payments-api
  namespaceSelector:
    matchLabels:
      monitoring: enabled
  endpoints:
    - port: metrics
      interval: 30s

此时，命名空间的标签实际上已经成为监控配置的一部分。

Breaking It

为了演示，我把命名空间上的 monitoring=enabled 标签删掉了。

• 没有任何崩溃。
• Pod 仍然在运行。
• 指标悄悄消失了。

这正是一种容易被忽视的故障。

Detecting What’s Wrong

我首先检查的是 Prometheus 本身是否异常：

kubectl get pods -n monitoring
kubectl logs prometheus-k8s-0 -n monitoring

一切看起来都正常。

接着，我检查 Prometheus 是否仍在抓取该命名空间的任何内容：

up{namespace="payments-prod"}

没有结果。这说明 Prometheus 没有抓取目标——并不是说应用挂掉了。

Finding the Cause

下一步是检查命名空间本身：

kubectl get namespace payments-prod --show-labels

输出类似于：

monitoring=disabled

由于 ServiceMonitor 依赖于：

namespaceSelector:
  matchLabels:
    monitoring: enabled

Prometheus 正在按其配置的行为工作。从 Prometheus 的角度来看，并没有出现故障。

Fixing It

只需恢复标签即可：

kubectl label namespace payments-prod monitoring=enabled --overwrite

指标在一次抓取周期内恢复。

快速检查以确认数据新鲜度：

time() - timestamp(up{namespace="payments-prod"})

一切再次可见。

Why This Is a Sneaky Failure

本次演练的有趣之处在于：

• 没有触发任何告警。
• 仪表盘是空的，而不是显示红色。
• Prometheus 将缺失的数据视为“没有可评估的内容”。

如果在此期间真的出现了故障，我根本不会知道。这就是为什么你会对看似“绿色”的系统产生盲目信任。

Hardening Things Afterward

Alerting on Missing Metrics

我添加了一个显式告警来捕获遥测丢失：

- alert: NamespaceMetricsMissing
  expr: absent(up{namespace="payments-prod"})
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "No metrics from payments-prod"
    description: "Prometheus is scraping zero targets in this namespace."