5.1 监控体系方法论闭环：盯什么→怎么采→怎么看→怎么响应

5.1 监控体系方法论闭环：盯什么→怎么采→怎么看→怎么响应

走到第五章，把全书的内容收拢一下。我见过很多团队的监控建设是"碎片化"的——今天加个指标，明天加个告警，后天加个看板，缺乏整体方法论。结果是监控越堆越多，但每次故障还是手忙脚乱。这一节把全书的脉络梳理成一个清晰的"四步闭环"，让你在面对任何新的推理场景时，都能用统一的思路去落地监控，而不是东拼西凑。

监控体系的四步闭环

全书的脉络可以用一个闭环概括：盯什么（指标设计）、怎么采（抓取接入）、怎么看（看板呈现）、怎么响应（告警与值班）。这四步不是一次性建完就结束，而是持续迭代的闭环——每次故障后回头优化"盯什么"和"怎么响应"，监控体系才会越用越准。

盯什么对应第一章和第二章，是指标设计。要盯的是黄金信号（QPS、延迟、错误、饱和）加上推理特有的指标（TTFT、TPOT、KV Cache、批处理队列）。遵循 USE（Utilization/Saturation/Errors）、RED（Rate/Errors/Duration）、Four Golden Signals 这些成熟方法论，原则是少而精——盯对关键指标，比盯一堆杂乱指标有用得多。

怎么采对应第二章，是抓取接入。把 vLLM/TGI 的 /metrics 接进 Prometheus。这一步的关键是控制基数（见 3.1 节），高基数指标会拖垮监控系统本身。调试用的细粒度指标按需降采样，不要全量入库。

怎么看对应第四章，是看板呈现。三层递进（概览→服务→实例），首屏黄金信号，用分位数而非平均。看板的组织要围绕"值班排障"这个核心场景设计。

怎么响应对应第四章，是告警与值班。用错误预算告警替代裸阈值告警，分级路由，配套 runbook 和值班响应流程。

四步闭环的迭代本质

这四步最大的价值不在于"一次建好"，而在于"持续迭代"。每次故障都是一次学习机会——故障后复盘，往往会发现"盯什么"漏了某个关键指标、"怎么响应"的 runbook 不够清晰。把这些改进固化回去，下一轮闭环就更完善。

我建议团队建立"故障驱动的监控迭代"机制：每次故障后，必须产出至少一项监控改进（新增指标、优化告警、完善 runbook）。这样监控体系会随着故障经验不断进化，而不是建好后就停滞。一个跑了两年、经历过几十次故障迭代的监控体系，和一个刚建好的监控体系，战斗力天差地别——前者几乎能覆盖所有常见故障场景，后者总会漏掉一些。

能力地图：你在哪一级

把团队的监控成熟度分级，便于自评和规划改进路径。

L0 是无监控，出了事才知道，通常靠用户投诉发现故障。L1 是基础监控，有 CPU、内存这些资源指标，但没有业务 SLO，看不出"用户体验好不好"。L2 是黄金信号，有 TTFT、错误率这些业务指标，能观测到用户体验。L3 是 SLO 驱动，有错误预算，告警基于 SLO，能量化和治理可用性。L4 是自治，有自动根因分析、LLM 辅助告警分诊，走向无人值守。

多数团队卡在 L2 到 L3 的跃迁——从"有指标"到"指标服务于 SLO 决策"。这个跃迁难，是因为它要求团队从"堆指标"的思维，转变为"指标要服务于决策"的思维。本书的目标就是帮你跨过这道坎，把监控从"有"变成"有用"。

上线前的监控检查清单

新推理服务上线前，监控是必查项。我整理了一份清单，每项都空不得。

黄金信号（TTFT、TPOT、错误率、吞吐）已接入并上首屏看板。KV Cache 占用率、批处理队列长度这些推理特有指标已监控。错误预算告警规则已配置并验证（不是配完就完，要触发一次测试告警确认通知链路通）。三层下钻路径打通（概览能点到服务，服务能点到实例）。值班响应流程演练过一次（用一次模拟故障走完确认、定位、止血、复盘全流程）。高基数指标已识别并治理（查过 series 数量，没有失控的标签）。

这份清单不是走形式——任何一个空着上线，都意味着下次故障时两眼一抹黑。我自己推行的纪律是"监控不过关不允许上线"，产品再急也要先把监控补齐，否则上线就是埋雷。

这一节的关键结论

监控是"盯→采→看→响应"的持续闭环，不是一次性工程。用能力地图自评（多数团队在 L2 到 L3 的跃迁期），用上线检查清单兜底。最重要的是建立"故障驱动的监控迭代"机制，让监控体系随经验进化。

下一节 5.2 展望未来——当 LLM 推理走向多模型、Agent、边缘，可观测性会演化成什么样。