第二章：监控体系架构设计

好，咱们直接进入正题。监控体系怎么搭？我个人的习惯是——先画分层，再定数据流，最后串告警链路。这三件事搞定了，整个架子就立起来了。

2.1 分层监控架构

为什么要分层？说白了，AI系统太复杂了。你想想看，底层是GPU集群，中间是模型推理，上层是业务API。任何一个环节出问题，表现可能都一样——用户说“系统卡了”。但根因在哪？不分层你根本查不到。

我一般把监控分成三层：

基础设施层

这一层管的是“硬家伙”。GPU利用率、显存占用、网络延迟、磁盘IO。嗯，这里要注意——GPU监控和传统CPU监控完全是两码事。GPU有显存带宽、SM利用率、温度墙这些指标，传统监控工具根本看不懂。

模型层

这一层是AI监控的核心。模型在跑什么？推理延迟多少？精度有没有掉？这些才是业务方真正关心的。

我个人习惯把模型层监控分成两个维度：

• 性能维度：P50/P95/P99延迟、吞吐量（QPS）、批处理大小
• 质量维度：输出分布漂移、置信度变化、异常输入比例

举个例子，你部署了一个文本分类模型。某天突然发现所有输出都偏向“正面”类别。这时候模型层的监控应该能立刻告诉你——输入分布变了，还是模型参数出了问题？

应用层

这一层面向最终用户。API响应时间、错误率、调用量。说白了，用户不关心你的模型有多牛，他只关心“点一下按钮，结果多久出来”。

应用层监控要回答三个问题：

1. 用户请求是否成功？（HTTP状态码、业务错误码）
2. 响应时间是否可接受？（SLA达标率）
3. 用户体验是否一致？（同一条请求，不同时间结果是否稳定）

2.2 数据流设计

数据怎么从底层流到上层？这是架构设计里最容易翻车的地方。我见过太多团队，每层各搞各的监控，数据孤岛严重。出了问题，要从应用层一路查到基础设施层，中间还得手动对时间戳。

我的做法是——统一打点，统一采集，统一存储。

具体来说：

• 打点：每层都用相同的trace ID。应用层收到请求时生成一个ID，传到模型层，再传到基础设施层。这样出了问题，一条链路查到底。
• 采集：用统一的Agent采集。别搞什么“GPU用nvidia-smi，模型用自定义脚本，应用用Prometheus”。统一用OpenTelemetry或者自研Agent，减少维护成本。
• 存储：时序数据进InfluxDB/TimescaleDB，日志进Elasticsearch，链路追踪进Jaeger。各司其职，别混着用。

2.3 告警链路设计

告警链路，说白了就是“出了问题，谁该知道，怎么知道”。很多团队的告警链路设计得一团糟——要么告警太多，没人看；要么告警太少，出事了才发现。

我总结了一个“三级告警”模型：

• P0（致命）：服务不可用、模型完全失效。直接电话+短信+钉钉/，5分钟内必须有人响应。
• P1（严重）：延迟飙升、错误率上升。邮件+即时消息，15分钟内响应。
• P2（警告）：资源使用率偏高、模型精度轻微下降。邮件通知，日清日结。

告警链路设计里，最容易忽略的是“告警抑制”。你想想看，GPU温度告警了，紧接着显存告警、推理延迟告警、API超时告警……一堆告警同时涌过来。这时候如果没有抑制机制，值班人员根本不知道先处理哪个。

告警链路的另一个关键点是“升级机制”。如果P0告警发出后10分钟没人认领，自动升级到技术负责人；20分钟没人处理，升级到部门负责人。别觉得不好意思，出事了没人扛才是最大的问题。

好了，监控体系架构设计就聊这么多。记住一句话：分层是为了隔离复杂度，数据流是为了串联信息，告警链路是为了快速响应。这三件事做好了，你的AI系统就有了“眼睛”和“耳朵”。