第 21 章 监控体系

学习目标

• 掌握可观测性四要素：指标、日志、追踪、事件、告警；
• 建立四层监控体系：系统、服务、模型、业务；
• 掌握 LLM 特有监控：Token、Prompt、延迟分解；
• 理解监控与 SLO 的关系，把监控变成可行动的管理工具。

---

21.1 可观测性四要素

监控的前提是「可观测」。四类信号各有分工：

要素	是什么	回答	代表工具
指标（Metrics）	数值序列	「现在怎样」	Prometheus
日志（Logs）	事件记录	「发生了什么」	Loki/ELK
追踪（Traces）	请求链路	「问题在哪一环」	Jaeger/Tempo
事件/告警（Events/Alerts）	阈值触发	「需要处理什么」	Alertmanager/PagerDuty

四者互补，缺一不可：指标告诉你「服务慢了」（现象），追踪告诉你「慢在 Prefill 还是检索」（定位），日志告诉你「具体哪个请求、什么输入」（细节）。LLM 服务尤其要三者联动——第 1 章的请求链路在监控侧还原。

21.2 四层监控体系

监控要分四层，每层的对象与负责人不同：

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart TD
    A[业务指标
转化/收入/满意度] --> B[模型指标
质量/幻觉/漂移]
    B --> C[服务指标
QPS/延迟/错误]
    C --> D[系统指标
GPU/显存/网络]
    D -.资源异常.-> C
    C -.质量下降.-> B
    B -.业务受损.-> A

层	指标	例子	负责人
系统	资源健康	GPU 利用率、显存、温度、IB 链路、磁盘 IO	SRE/平台
服务	接口能力	QPS、TTFT、TPOT、错误率、饱和度	平台/服务 owner
模型	模型质量	准确率、召回、漂移、幻觉率、安全事件	模型团队
业务	业务价值	转化、留存、满意度、每 query 成本	业务团队

关键原则：上层指标异常，要靠下层指标定位。业务下降 → 模型质量崩了 → 某次发布导致的延迟劣化 → 某个 GPU 节点故障。四层联动的链路就是排障路径。

21.3 系统指标

LLM 服务的系统层指标比传统服务多一个维度——GPU：

• GPU：利用率（SM 利用率，不是显存）、显存占用、温度、功耗、时钟（降频=节流）、NVLink 带宽；
• CPU/内存：编排与数据面（tokenizer、RAG 管道）的 CPU 消耗；
• 网络：IB 链路状态（第 11 章）、网关吞吐、丢包；
• 磁盘：模型加载 IO、日志写盘、缓存落盘。

LLM 特有的系统坑：GPU「利用率高」可能是 memory-bound 的空转（第 14 章）——要看 SM 利用率 + 显存带宽利用率 双指标；显存接近满时（KV 占用），GC/OOM 风险陡增。

21.4 服务指标

服务层是「用户体验的数字化」，LLM 特有分解：

• QPS / 并发：请求量、在途请求数；
• 延迟分解（第 17 章 SLA 三件套）：TTFT、TPOT、TBT，以及端到端（含编排+RAG）；
• 错误率：HTTP 4xx/5xx、超时率、重试率、截断率（max_tokens 触顶）；
• 饱和度：排队长度、KV 使用率、批大小——饱和度是「快撑不住」的先兆指标。

# 关键 LLM 服务指标示例（Prometheus 风格）
llm_requests_total{model="qwen2.5-7b",status="ok"} 
llm_ttft_seconds_bucket{model="qwen2.5-7b",le="0.5"}
llm_tpot_seconds_bucket{model="qwen2.5-7b",le="0.03"}
llm_kv_utilization{instance="gpu-01"}   # KV 使用率=饱和度
llm_queue_depth{model="qwen2.5-7b"}     # 排队长度

饱和度是监控的灵魂：延迟是「结果」，饱和度是「原因」——KV 快满、队列变深时，延迟恶化已经在路上。好的监控在饱和度越线时告警，而不是等延迟崩了才报。

21.5 模型指标

模型层指标回答「模型还靠谱吗」（第 9 章评估的在线化）：

类型	指标	获取方式
质量	在线打分、好评率、拒答率	用户反馈 + LLM 裁判抽样
漂移	输入分布漂移、输出分布漂移（第 22 章）	统计检测
幻觉	幻觉率（RAG 场景的忠实度）	抽样评测（第 9 章 RAGAS）
安全	越狱/注入事件数、毒性率、PII 泄露率	安全监控层（第 23 章）
成本	每 query token、缓存命中率	成本计量（第 17 章）

模型指标是「慢信号」：不能实时全量，只能抽样 + 窗口统计——但它是「业务下降」的根因层，必须要有。

21.6 业务指标

业务层是「模型最终有没有创造价值」：

• 转化率、留存率、满意度（CSAT/NPS）、任务完成率、收入、每 query 成本。

业务指标与模型指标的因果链要打通：模型变好 1 分 → 满意度涨多少 → 收入涨多少。打不通这条链，模型迭代就是「自嗨」。第 22 章的反馈闭环会把用户行为数据回流成训练数据（第 6 章「线上反馈数据」）。

21.7 从监控到 SLO：让监控可行动

监控的终点不是「有图」，是「能管理」。SLO（Service Level Objective）把监控变成管理工具：

\text{Error Budget} = 1 - \text{SLO} \quad(\text{如 SLO 99.9%，月度错误预算约 43 分钟})

• 监控 → SLI（实际达成值）→ 与 SLO（目标）对比 → 错误预算（可允许的失败量）；
• 错误预算用完了，就该停止发布、专心修稳定——这是监控与发布（第 19 章）的衔接点；
• 第 23 章会完整展开 SLO/SLI/错误预算。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[SLI 实测
TTFT p95] --> B{SLO 99.9%?}
    B -->|达标| C[正常迭代]
    B -->|预算耗尽| D[冻结发布
投入稳定性]
    D --> E[恢复后解冻]

---

本章要点回顾

1. 可观测性四要素：指标（现在怎样）、日志（发生了什么）、追踪（在哪一环）、告警（要做什么）。
2. 四层监控：系统→服务→模型→业务，上层异常靠下层定位。
3. 系统层看 GPU SM 利用率 + 带宽（不是显存空转）；网络链路是敏感点。
4. 服务层延迟要分解 TTFT/TPOT/TBT；饱和度（KV 使用率、队列）是延迟的原因先兆。
5. 模型层是慢信号，抽样 + 窗口统计；安全与成本是 LLM 独有维度。
6. 业务层打通「模型改进 → 业务价值」的因果链。
7. SLO + 错误预算把监控变成管理工具：预算耗尽冻结发布。

习题

1. 为你的 LLM 客服服务设计四层监控指标表：每层至少 5 个指标、单位、采集频率。
2. GPU 利用率 95% 但吞吐不达标，可能是什么原因？怎么用「SM 利用率 + 带宽利用率」分辨？
3. 设计 8 条告警规则（指标、阈值、级别、动作），覆盖四层，含饱和度与质量类。
4. 为什么模型指标不能实时全量监控？给出抽样评测的设计（样本量、频率、统计口径）。
5. 定义你的服务的 SLO（TTFT/TPOT/可用性）与错误预算，并说明预算耗尽时团队该做什么。

延伸阅读

• Google SRE 手册（SLI/SLO/错误预算）
• Prometheus / Grafana 文档
• OpenTelemetry 文档（追踪）
• NVIDIA DCGM 文档（GPU 遥测）
• LangSmith / Langfuse（LLM 可观测性工具）

下一章预告

第 22 章模型可观测性：数据漂移与概念漂移、异常检测、解释性与审计日志，以及 LLM 特有的 Prompt/Token/工具调用/RAG 命中可观测性与在线评估反馈闭环。