监控大盘的指标是怎么挑的？关键步骤一次讲清

大模型服务的监控大盘常犯一种病：图表几十张，出了问题没人看得出重点。汽车仪表盘只放速度、转速、油量、水温几样，司机一眼可读——多了反而误事。监控大盘的指标挑选，挑的是「出事时能最快指路的那几根指针」，而非仪表数量的堆砌。

先带走一个判断：好指标有两个特征——能触发行动、能定位方向。既不能让人行动、也不能指路的指标，一律不上大盘。

指标不是越多越准

指标泛滥的真实代价是注意力稀释：值班的人面对满屏曲线，真正异常的那条反而被淹没。收敛的办法是按问题反推——先列出「这个服务最怕发生什么」，再为每种故障找前置信号，信号才够格成为大盘指标。比如最怕响应变慢，前置信号是时延分位数；最怕成本失控，前置信号是消耗速率。从故障倒推指标，天然过滤掉一堆「有也行」的摆设。

服务侧必看的三组数

服务侧指标分三组看。可用组：成功率、错误类型分布，回答「服务还正常吗」。快慢组：时延分位数——用 P95、P99 而不是平均值，平均数会掩盖少数极慢请求，生成式服务还要单看首字时延，用户的耐心是用首字衡量的。压力组：请求量、队列长度、并发水位，回答「系统还剩多少余量」。三组各有分工，异常时互相印证：量涨、队列涨、时延涨同时出现，基本可断定是过载；量平而错误率升，多半是依赖出了问题。三组之外还有一类容易被忽略的信号——依赖健康度：外部接口的成功率与响应时间也要上中层大盘，自家代码再稳，依赖一断全链跟着断。

三组指标各自回答什么、异常怎么读，并排对照。

成本侧的两条曲线

大模型服务的特殊性在于算力即成本，大盘必须留成本位。两条曲线最实用：消耗速率曲线，按小时或天看 tokens 消耗与折算费用，斜率突变就是信号；单位成本曲线，即每次有效调用的平均花费，它能剥离流量波动看效率——单位成本爬升，往往是重试变多或上下文膨胀。成本数据的来源与口径，见多模型的成本对比是怎么跑的？过程拆开看。消耗异常何时该升级成告警，由分级规则决定，见告警的分级是怎么定的？从原理到落地。

大盘的分层与留白

大盘建议三层：顶层只放四到六根指针，供值班三十秒内判断全局健康度；中层按子系统分组，供定位是哪一环出问题；底层是明细查询入口，按需下钻。留白是刻意的——顶层不放满，才容得下新增的关键指标。指标之外还要记录事件标注：发布、扩容、故障修复的时间点画在曲线上，复盘时因果一目了然。大盘的访问权限也跟着职责走：值班看全量，各组负责人看自己的子系统，既避免越权，也避免互相干扰。原始数据从哪来、怎么归档，与日志策略直接相关，见日志的保留与合规是怎么平衡的？；大盘数字的可信度还取决于系统抗压能力，验证方法见容量压力测试是怎么做的？每一步都讲透。

指标挑选自查清单

• 每个指标能否对应一种需要行动的故障
• 时延是否看分位数，生成式是否单看首字时延
• 成本侧是否同时有消耗速率与单位成本
• 大盘是否分层，顶层是否控制在六根指针内
• 发布与故障是否在曲线上留了标注

换个问法再问监控大盘三句

• 大盘多久评审一次？：随架构或业务大变更后必评，平时按季度清理一次，下线三个月无人查看的图表。
• 告警和大盘什么关系？：大盘供人看，告警找人看，指标先上大盘观察，稳定后再为其设阈值告警。
• 接腾讯元宝或秘塔AI搜索这类服务也要自建大盘吗？：平台侧有它的统计，但自己的调用成功率、时延与花费仍要自己记录，责任边界内的健康度自己兜底。