监控平台运维

监控平台本身也要被运维。Prometheus 能采到业务指标，不代表平台长期稳定；采集目标变多、标签基数变大、保留周期变长、规则越来越多以后，Prometheus、Alertmanager、Grafana 都会出现容量、性能和可用性问题。监控平台出故障时，最尴尬的是业务已经异常，但告警没有发出来。

一、平台自身要监控

Prometheus 自己会暴露 /metrics。当前实验环境里已经把 Prometheus 自身作为一个 target：

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets:
          - 127.0.0.1:9090

常见自监控指标：

指标	含义
prometheus_target_interval_length_seconds	实际抓取间隔分布
prometheus_target_scrapes_exceeded_sample_limit_total	超过样本限制次数
prometheus_rule_evaluation_duration_seconds	规则计算耗时
prometheus_rule_group_last_duration_seconds	规则组最近一次计算耗时
prometheus_tsdb_head_series	当前 head 中序列数量
prometheus_tsdb_wal_corruptions_total	WAL 损坏次数
prometheus_notifications_errors_total	发送告警失败次数
alertmanager_notifications_failed_total	Alertmanager 通知失败次数

监控平台自己至少留一个小看板：target 数、down 数、TSDB series 数、规则计算耗时、磁盘使用、Alertmanager 通知失败。业务看板再漂亮，平台自身不稳也白搭。

二、容量和保留周期

Prometheus 本地 TSDB 的压力主要来自三件事：序列数量、采集频率、保留周期。

因素	影响
target 数	目标越多，抓取越多
每个 target 样本数	Exporter 暴露指标越多，写入越多
label 基数	序列数量膨胀
scrape interval	间隔越短，样本越多
retention	保留越久，磁盘越大

启动参数里可以设置保留时间和数据目录：

ExecStart=/opt/prometheus/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=15d \
  --web.listen-address=:9090 \
  --web.enable-lifecycle

实验环境保留 7 到 15 天通常够用。生产环境要按指标量和回溯需求计算；如果需要保留几个月甚至一年，更适合接 Thanos、Mimir、VictoriaMetrics 这类远端存储或长期存储方案。

三、标签基数治理

标签基数是 Prometheus 最常见的隐性风险。一个指标如果带上 user_id、request_id、trace_id、订单号，序列数量会快速膨胀。

排查高基数可以从这些方向看：

# 当前 head 中活跃序列数量
prometheus_tsdb_head_series

# 按 job 粗略统计 up 序列数量
count by (job) (up)

更细的高基数分析通常要用 Prometheus 自带 TSDB 工具或管理 API。原则很简单：稳定维度适合标签，唯一 ID 不适合标签。

适合标签	不适合标签
service、env、cluster、instance、status	user_id、request_id、trace_id、订单号、错误堆栈

TraceID 要放到链路和日志里。指标上要关联 Trace，可以用 exemplar，不是把 TraceID 变成普通 label。

四、采集异常

Targets 页面是采集异常第一入口。常见状态：

页面路径：

Status -> Target health （中文：状态 -> 目标健康状态）

操作上先按 scrape pool 过滤，再展开异常 target。Last scrape 能看到最近一次抓取时间和耗时，State 能看到 UP 或 DOWN，展开后能看到最近错误原因。

现象	可能原因
DOWN	exporter 挂了、端口不通、防火墙、地址写错
context deadline exceeded	网络慢、服务响应慢、采集超时
server returned HTTP status	抓到了错误页面或鉴权失败
sample limit exceeded	单个 target 样本太多
label limit exceeded	标签数量或长度超过限制

排查顺序：

# 在 Prometheus 机器上访问 target，验证网络和 exporter
curl -s http://192.168.10.13:9100/metrics | head

# 看 Prometheus 配置是否能解析
/opt/prometheus/promtool check config /etc/prometheus/prometheus.yml

# reload 后看服务日志，抓取错误通常会写出来
journalctl -u prometheus -n 100 --no-pager

如果 Grafana 面板没数据，先回 Prometheus 查同一条 PromQL，再看 Targets。Grafana 在这条链路里是查询入口，不是采集入口。

五、规则和告警噪声

规则文件变多以后，要关注规则计算耗时。规则计算时间接近或超过 evaluation_interval，告警就会延迟，甚至影响 Prometheus 整体性能。

规则检查：

# 检查所有规则文件语法
/opt/prometheus/promtool check rules /etc/prometheus/rules/*.yml

# 检查主配置，能同时发现 rule_files 路径问题
/opt/prometheus/promtool check config /etc/prometheus/prometheus.yml

告警噪声常见来源：

来源	处理方向
阈值太敏感	加 for，按业务基线调阈值
缺少分组	调整 Alertmanager group_by
派生告警太多	用抑制规则
维护窗口告警	用静默，和变更记录对应
低价值告警太多	降级到看板或日志

告警规则不是越多越好。值班的人看到一堆已知噪声时，会很自然地忽略通知，真正的异常也容易被盖住。

六、Alertmanager 运维

Alertmanager 重点看三类问题：是否收到 Prometheus 告警，是否正确分组/静默/抑制，是否成功发出通知。

页面入口：

入口	用途
Alerts（中文：告警）	查看当前进入 Alertmanager 的告警、labels 和 receiver
Silences（中文：静默）	查看维护窗口或临时屏蔽规则
Status（中文：状态）	查看实际生效配置、集群状态和 receiver

检查入口：

# Alertmanager ready
curl -s http://127.0.0.1:9093/-/ready

# 查看当前状态和集群信息
curl -s http://127.0.0.1:9093/api/v2/status

# 查看最近日志，通知失败、配置错误会出现在这里
journalctl -u alertmanager -n 100 --no-pager

生产里 Alertmanager 通常至少两个副本。单节点 Alertmanager 挂掉时，Prometheus 仍然能计算告警，但通知链路会断。

七、Grafana 运维

Grafana 侧重点不是采集，而是数据源、看板、权限和告警查询。

页面入口：

入口	用途
Connections -> Data sources（中文：连接 -> 数据源）	检查 Prometheus URL、认证和 Save & test
Explore（中文：探索）	临时执行 PromQL，判断数据源是否能查到数据
Dashboards -> Dashboard -> Panel menu -> Edit（中文：仪表盘 -> 看板 -> 面板菜单 -> 编辑）	检查面板查询、变量、单位和时间范围
Administration（中文：管理）	检查用户、组织、权限和插件

检查点	说明
数据源	Prometheus URL、鉴权、默认数据源
看板	变量、时间范围、PromQL、面板单位
权限	组织、用户、文件夹权限
provisioning	数据源和看板是否由配置管理
插件	插件版本、兼容性、安全风险

Grafana 看板最好能配置化。手工在页面改出来的看板，如果没有导出 JSON 或放进版本管理，重装平台时很容易丢。

八、备份和迁移

监控平台至少要备份这些东西：

对象	内容
Prometheus 配置	prometheus.yml、rules、file_sd 文件
Alertmanager 配置	alertmanager.yml、通知模板
Grafana 数据	dashboard、datasource、用户权限
部署文件	systemd unit、容器编排文件、Helm values
运行数据	是否备份 TSDB 要看保留需求

Prometheus TSDB 一般不作为最优先备份对象，除非有审计或历史回溯要求。配置、规则、看板、通知模板更应该先纳入版本管理。

九、平台故障场景

常见故障：

场景	处理方向
Prometheus 启动失败	配置语法、规则文件、数据目录权限
Prometheus 磁盘满	缩短保留、清理旧 block、扩容磁盘
Targets 大面积 down	网络、DNS、服务发现、Prometheus 自身网络
查询很慢	高基数、时间范围太大、PromQL 太重
告警没发	Prometheus 到 Alertmanager、路由、receiver
Grafana 没数据	数据源、时间范围、PromQL、Prometheus 状态

监控平台变更也要有窗口。改采集配置、改保留周期、批量加 target、导入大量规则，都会影响 Prometheus。变更前先在测试环境检查规则和样本量，再推到生产。