云原生-05-Prometheus+Grafana在测试平台和中间件监控中的落地方法

发表于 分类于 本文字数： 3.1k 阅读时长 ≈ 11 分钟

第一次上 Prometheus + Grafana，最先完成的通常是这些动作：

  • 把 node-exporter、kube-state-metrics、redis-exporter 装起来
  • 导入几套现成 dashboard
  • 让 Grafana 能看到 CPU、内存、网络和磁盘

这些动作能让“看板”跑起来，但离“监控真正可用”还差很远。测试平台和中间件场景里的高频问题，往往不是没有指标，而是指标很多、结论很少：

  • 平台任务失败率升高，却说不清是调度层、执行层还是环境层出问题
  • Redis、Kafka、MySQL 都在监控，但故障发生时没人知道应该先看哪一组指标
  • 某次回归超时很多，Grafana 也能看到波动，但证据对不上执行任务和发布时间窗
  • 告警很多，真正有价值的很少，最后群里只剩静音规则

这说明 Prometheus + Grafana 在测试平台里的角色，不是做一个“基础资源大盘”，而是把下面几条链路收起来：

  • 平台链路：任务调度、任务执行、结果回写、报告生成
  • 中间件链路：Redis、Kafka、MySQL、Elasticsearch 等依赖状态
  • 发布链路：版本上线、配置变更、扩缩容、回滚
  • 排障链路：问题出现时，能不能快速回答“从哪一层开始坏的”

这篇文章只讨论一个核心问题：

Prometheus 和 Grafana 在测试平台与中间件场景里，应该怎么落地指标、看板、告警和排障链路，才能真正支持发布验证和故障定位。

一、先把监控对象分层，别把所有指标都堆进一张大盘

监控体系最容易失控的地方，不是采集不到数据，而是没有先按对象分层。

更适合测试平台现场的做法，是把监控对象拆成下面四层：

  • 平台控制层：任务创建、调度、分发、回写、报告
  • 执行资源层：执行机、Worker、设备、容器、副本、队列
  • 中间件依赖层：Redis、Kafka、MySQL、Elasticsearch、Nginx
  • 用户体验层：任务成功率、耗时分布、回归通过率、发布后错误率

如果不分层，后面通常会出现两类失真：

  • 指标很多，但没有一组指标能直接回答“平台为什么慢”
  • 看板很多，但故障发生时还是只能靠人工翻日志

1. 平台控制层：先确认任务系统是不是已经失真

测试平台自身至少要有下面几类指标：

  • 任务创建数、调度成功数、调度失败数
  • 执行队列长度、等待时长、超时数、重试数
  • 执行实例成功率、失败率、取消率、卡死数
  • 报告生成耗时、结果回写耗时、通知发送耗时

这一层的目标不是“画得好看”，而是回答几个具体问题：

  • 是没人消费任务，还是任务发不出去
  • 是执行资源不够，还是调度策略有问题
  • 是任务本身失败，还是结果回写卡住了

2. 执行资源层：区分资源瓶颈和业务失败

平台执行失败，很多时候不是测试逻辑错，而是资源已经不稳。

这一层更应该盯这些指标：

  • Worker 副本数、活跃任务数、空闲槽位数
  • CPU、内存、磁盘、网络、文件句柄
  • Pod 重启次数、OOMKilled 次数、探针失败次数
  • 执行机负载、容器重建、节点压力

只盯 CPU 和内存通常不够，因为平台型系统更容易被这些问题拖垮：

  • 队列长度积压
  • 连接池耗尽
  • 磁盘写放大
  • 日志量暴涨
  • 节点驱逐

3. 中间件依赖层：别只看“活着”，要看是否还能承受任务压力

测试平台对中间件的依赖通常比普通业务系统更重，因为它会同时放大：

  • 任务并发
  • 结果回写
  • 证据存储
  • 日志收集
  • 状态变更

这一层至少要分对象看：

  • Redis：连接数、命中率、阻塞客户端、慢查询、主从状态
  • Kafka：消费延迟、分区堆积、Broker 状态、生产失败率
  • MySQL：连接使用率、慢 SQL、锁等待、主从延迟
  • Elasticsearch：写入延迟、分片状态、磁盘水位、查询耗时

如果只是统一看“中间件都在线”，发布现场通常仍然回答不了：

  • 为什么任务能创建但不能执行
  • 为什么结果能跑出来但回写越来越慢
  • 为什么回归流量一大，中间件先退化

4. 用户体验层：把技术指标翻译成发布决策指标

纯资源图很难直接支撑测试和发布决策，最终还要翻译成业务可理解的口径：

  • 任务平均耗时、P95 耗时、超时率
  • 回归通过率、异常终止率
  • 发布后 30 分钟失败率
  • 巡检成功率、补跑成功率

这一层是平台监控真正有价值的地方，因为它能直接回答：

  • 这次发布有没有把平台压坏
  • 这次回归失败，值得不值得阻塞
  • 当前集群还能不能继续加压

二、Prometheus 指标采集怎么落地，才不会只剩 exporter

Prometheus 落地最常见的误区，是觉得装好 exporter 就算完成监控接入。

更能落地的方式，是把采集对象拆成三类：

1. 基础资源指标

主要来自：

  • node-exporter
  • kube-state-metrics
  • cadvisor

这部分负责回答：

  • 节点和 Pod 的资源是否稳定
  • 副本是不是在反复重建
  • 部署是否完成收敛

2. 中间件指标

主要来自：

  • redis-exporter
  • mysqld-exporter
  • kafka-exporter
  • elasticsearch-exporter

这部分不能只采默认模板，最好结合测试平台场景补上关键聚合：

  • 按环境、按命名空间、按业务队列聚合
  • 把“单机健康”转成“任务是否受影响”

3. 平台自定义指标

这是最容易缺失、但最有价值的一层。平台至少应该主动暴露：

  • task_dispatch_total
  • task_running_count
  • task_timeout_total
  • task_result_write_duration_seconds
  • worker_busy_slots
  • callback_fail_total

如果平台只依赖外部基础指标，后面做故障定位时几乎一定会出现断层：

  • 知道 Pod 很忙，但不知道哪个任务拖的
  • 知道 Redis 抖了，但不知道哪类任务先受影响

三、Grafana 看板怎么设计，才能支持发布和排障

更合适的看板结构通常不是按组件分，而是按现场问题分。

1. 总览看板

用于快速判断是否需要继续深挖：

  • 平台任务总量
  • 任务成功率
  • 执行耗时 P95
  • Worker 忙闲
  • 关键中间件状态
  • 当前版本和发布时间窗

2. 平台执行看板

重点看：

  • 任务创建、排队、执行、完成的分布
  • 调度耗时与执行耗时拆分
  • 失败类型分布
  • 重试和补跑趋势

3. 中间件专题看板

每个依赖都应该有自己的专题图，不建议完全依赖通用 dashboard。

例如 Redis 更适合重点看：

  • ops/s
  • blocked_clients
  • rejected_connections
  • keyspace hit ratio
  • master link 状态

4. 发布窗口看板

这是 缺的一张图。更实用的方式是把发布版本、灰度窗口、变更时间点打在看板里，对照看：

  • 发布前后任务失败率
  • 发布前后执行耗时
  • 发布前后中间件波动
  • 发布前后 Pod 重建

没有这张图，后面很多“是否和发布有关”的讨论都会停留在猜测。

四、告警不要只按阈值发，要按动作发

测试平台和中间件场景里的告警，最怕两种极端：

  • 一类是阈值过低，任何波动都告警
  • 一类是阈值过高，等真正出问题时已经来不及

更合适的设计方式，是把告警分成三类：

1. 可观察告警

用于提醒异常趋势，但不直接阻塞动作，例如：

  • Redis 命中率持续下降
  • 某个 Worker CPU 长时间偏高
  • Kafka 某个主题延迟升高

2. 需要介入告警

需要工程动作，例如：

  • 执行队列持续堆积
  • 平台结果回写失败率升高
  • MySQL 慢查询持续拉长
  • Elasticsearch 磁盘水位逼近阈值

3. 阻塞类告警

这类才适合影响发布或回归结论，例如：

  • 平台任务成功率跌破基线
  • 多副本同时不健康
  • Redis 主从切换异常
  • 核心队列已无法消费

如果所有告警都直接进群，平台团队最后通常会选择静音，而不是治理。

五、最小可执行落地骨架

下面这套骨架更适合先把第一版监控跑稳：

1. 采集侧

  • 集群资源指标统一接入 Prometheus
  • 核心中间件统一接 exporter
  • 平台服务补自定义指标接口
  • 统一 labels：环境、命名空间、服务、任务类型、版本

2. 看板侧

  • 一张总览
  • 一张平台执行
  • 一张发布窗口
  • 各中间件一张专题图

3. 告警侧

  • 先只上 5 到 8 条关键告警
  • 每条告警必须明确接收人、动作和恢复标准
  • 告警消息里直接带 dashboard 链接和任务入口

4. 记录侧

至少保留一张值班记录表：

时间 事件 影响范围 先异常的指标 对应任务/版本 已做动作 当前状态
10:05 回归超时上升 全量接口回归 任务等待时长、Redis blocked_clients release-20230916 扩副本、限流 恢复中

六、常见坑

1. 看板很多，但没有任务视角

只看基础资源图，最后永远回答不了“到底是哪类任务先坏”。

2. 指标采到了，但 labels 混乱

没有统一环境、服务、任务类型、版本标签，后面根本做不了聚合。

3. 平台不暴露业务指标

只依赖 exporter，结果所有结论都只能停在“资源层有波动”。

4. 告警只按阈值，不按动作

群消息很多，但没人知道下一步该看哪张图、做什么动作。

5. 发布时没有时间窗标记

明明发布引起的波动，看板里却没有版本和变更点，最后只能靠回忆猜。

七、真实案例：回归突然大量超时，根因并不在接口服务

1. 场景

某次测试平台在晚间执行大批量接口回归，任务创建量明显升高。发布后 15 分钟内，大量任务开始超时，现场最先怀疑的是新版本接口服务退化。

2. 执行

值班同学先看接口服务的 Pod CPU、内存和错误日志，没有发现明显异常；随后对照平台总览和发布窗口看板，发现：

  • 平台任务等待时长突然升高
  • Worker 空闲槽位快速下降
  • Redis blocked_clients 和 instantaneous_ops_per_sec 同时波动
  • MySQL 指标基本平稳

3. 现象

表面上看是“接口超时变多”，但真正先异常的不是接口服务，而是平台执行队列和 Redis。

4. 排查

继续往下看平台执行看板，发现某类结果回写任务集中堆积，导致 Worker 长时间被占用；再看 Redis 专题图，发现某批写回 key 使用了大 value，单次回写耗时明显拉长，进而拖慢执行链路。

5. 修复

现场先做了两步：

  • 限流结果回写并临时扩容 Worker
  • 把大对象拆分写入，降低单次阻塞时间

调整后，任务等待时长和超时率逐步回落。复盘时补了三个动作：

  • 平台补充结果回写耗时直方图
  • Redis 看板新增 blocked_clients 与大 key 写入趋势
  • 发布窗口图固定标注大批量回归起始时间

八、结论

Prometheus + Grafana 在测试平台和中间件场景里最重要的价值，不是“把图画出来”，而是把平台任务、中间件依赖、发布动作和排障顺序收成同一条监控链路。

真正更有用的落地方式通常是：

  • 先分层：平台、资源、中间件、用户体验
  • 再补平台自定义指标
  • 再做支撑动作的看板和告警
  • 最后把发布窗口、任务对象和时间线打通

这样监控体系才不只是“能看”，而是“能指导下一步该怎么查、该不该放行、该先扩容还是先回滚”。