这是 Beta 探索课程,内容结构、实验步骤和示例可能会继续调整。
看板分层与黄金指标
可视化不是堆图表
可视化不是把所有图表堆到一个页面上,而是把排障路径变短。
一个好的监控工作台应该让值班人从「收到告警」快速进入「判断影响、定位根因、验证恢复」的流程。
看板分层
| 层 | 面向角色 | 内容 |
|---|---|---|
| 全局视图 | 管理者 | 整体可用性、核心业务指标、当前告警数量 |
| 服务视图 | 值班人 | 单个服务的 QPS、错误率、延迟、实例状态和依赖 |
| 请求视图 | 开发者 | 某次请求的 trace、相关日志和上下文 |
不同角色关注不同层:管理者要全局影响,值班人要服务异常,开发者要具体日志和 trace。
黄金指标面板
每个核心服务至少应该有一张黄金指标面板:
支付服务 · 黄金指标面板
请求量
Rate1.2k rps较昨日 +8%,正常
错误率
Errors3.2%超过阈值 1%,告警中
延迟
DurationP95 2.1sP50 180ms · P99 3.8s
饱和度
Saturation62%连接池 / 线程池 / 队列正常
关键认知:
每个核心服务都应有这四类指标——请求量、错误率、延迟(P50/P95/P99)、饱和度。
错误率和延迟同时异常,说明服务正在劣化;看板能直接从告警跳到对应时间窗口。
| 指标 | 含义 |
|---|---|
| 请求量 | 当前流量是否异常突增或突降 |
| 错误率 | 失败比例是否超过阈值 |
| 延迟 | P50、P95、P99 是否劣化 |
| 饱和度 | CPU、内存、连接池、线程池、队列是否接近上限 |
如果一个服务没有这四类指标,就很难判断它当前是否健康。
一句话
可视化看板分三层(全局 / 服务 / 请求)服务不同角色;每个核心服务都要有黄金指标面板(请求量、错误率、延迟、饱和度)——没有这四类指标,就无法判断服务是否健康。
发现内容有问题?
告诉我们哪里需要改进。
