这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
可视化
可视化不是把所有图表堆到一个页面上，而是把排障路径变短。一个好的监控工作台应该让值班人从“收到告警”快速进入“判断影响、定位根因、验证恢复”的流程。
看板分层
可视化看板可以分成三层：
- 全局视图：展示整体可用性、核心业务指标和当前告警数量。
- 服务视图：展示单个服务的 QPS、错误率、延迟、实例状态和依赖。
- 请求视图：展示某次请求的 trace、相关日志和上下文。
不同角色关注不同层。管理者需要全局影响，值班人需要服务异常，开发者需要具体日志和 trace。
黄金指标面板
每个核心服务至少应该有一张黄金指标面板：
- 请求量：当前流量是否异常突增或突降。
- 错误率：失败比例是否超过阈值。
- 延迟：P50、P95、P99 是否劣化。
- 饱和度：CPU、内存、连接池、线程池、队列是否接近上限。
如果一个服务没有这四类指标，就很难判断它当前是否健康。
从告警跳转
告警消息应该能一键跳到相关看板，并自动带上时间范围、服务名、接口名和环境。例如支付回调告警触发于 02:14，看板默认打开 02:04 到 02:24 的窗口。
这个细节很重要。排障时值班人最不应该浪费时间在手动选择时间、输入服务名、复制 trace id 上。
日志查询体验
日志查询不是全文搜索框就够了。实用的查询界面应该支持：
- 按服务、级别、trace id、用户、订单等字段过滤。
- 查看某条日志前后若干秒的上下文。
- 从日志跳到对应 trace。
- 保存常用查询模板。
- 对敏感字段做默认脱敏。
查询速度也要有预期。最近 15 分钟日志通常用于实时排障，应该优先优化；几个月前的日志更多用于审计和复盘，可以接受更慢。
事故工作台
当故障发生时，可以把相关信息聚合成事故工作台：
- 当前告警和确认人。
- 影响服务、接口和业务指标。
- 最近发布和配置变更。
- 关键日志样本和慢 trace。
- 处理记录和恢复时间线。
这能把排障从“到处找信息”变成“围绕同一上下文协作”。可视化的最终目标不是好看，而是降低平均发现时间和平均恢复时间。