3、监控基础：监控的概念、类型（日志、指标、追踪）、监控体系设计原则
3.1 监控的本质：从“未知”到“已知”的闭环
监控不是简单地“看图表”或“收告警”，其本质是将系统运行状态从不可知转化为可知、从被动响应转化为主动预防的工程能力。一个完整的监控闭环包含四个环节：采集（Collect）→ 存储（Store）→ 分析（Analyze）→ 行动（Act）。采集负责从应用、中间件、基础设施中获取原始数据；存储解决时序数据的高效写入与查询；分析通过规则、算法或机器学习识别异常；行动则触发告警、自动扩缩容或人工介入。
在AI DevOps场景中，监控的边界已从传统IT运维扩展到模型服务、数据管道和推理质量。一个典型的失败案例是：某团队仅监控了GPU利用率，却未监控模型推理的输入数据分布漂移，导致线上推荐效果下降30%而监控系统毫无感知。这说明监控设计必须与业务目标对齐，而非仅关注资源层。
3.2 三大监控类型：日志、指标、追踪
现代可观测性体系建立在三大支柱之上，三者互补，缺一不可。下表对比了它们的核心特征：
| 维度 | 日志（Logs） | 指标（Metrics） | 追踪（Traces） |
|---|---|---|---|
| 数据形态 | 非结构化/半结构化文本 | 数值型时序数据 | 树状跨度（Span）链 |
| 典型来源 | 应用日志、访问日志、系统日志 | CPU、内存、QPS、延迟、错误率 | 分布式调用链、RPC、消息队列 |
| 主要用途 | 故障根因定位、审计、行为分析 | 趋势预警、容量规划、健康检查 | 链路拓扑、性能瓶颈分析 |
| 存储成本 | 高（数据量大） | 低（可聚合降采样） | 中（需采样策略） |
| 查询方式 | 全文检索、正则匹配 | PromQL、SQL聚合 | Trace ID关联查询 |
3.2.1 日志：最原始的“黑匣子”
日志是离散事件的记录，通常包含时间戳、级别、来源、消息体。在AI DevOps中，日志不仅来自服务代码，还包括模型训练任务、数据预处理步骤和推理服务的输入输出采样。设计日志时需遵循结构化原则，使用JSON或键值对格式，便于自动化解析。例如：
{"timestamp":"2025-05-11T14:23:15.123Z","level":"ERROR","service":"inference-api","trace_id":"8f3a2b9c","model_version":"v2.3.1","error":"timeout waiting for response from torchserve","latency_ms":3021}日志管理的关键挑战是基数爆炸与噪音过滤。建议对高频率日志（如访问日志）进行采样或降级，保留完整上下文仅用于错误链路。
3.2.2 指标：系统健康的“心电图”
指标是周期性采集的数值型数据，适合反映系统状态的变化趋势。常用类型包括计数器（Counter）、仪表盘（Gauge）、直方图（Histogram）。在AI系统中，除了常规的CPU、内存、QPS外，还应关注模型专属指标：推理延迟分位数（P99）、GPU显存占用、批处理大小、模型预热时间、特征缓存命中率等。
指标设计需遵循USE方法（利用率、饱和度、错误）和RED方法（速率、错误、持续时间）。例如，对于推荐服务，核心指标集为：
- QPS（请求速率）
- P99/P95延迟（持续时间）
- 5xx错误率（错误）
- 特征存储命中率（饱和度）
3.2.3 追踪：分布式系统的“关联图谱”
追踪用于还原一次请求在分布式系统中的完整路径。每个追踪由多个Span组成，Span记录服务名称、开始时间、持续时间、父子关系。在微服务与AI推理混合架构中，追踪能清晰展示请求从API网关→特征服务→模型推理→结果后处理的完整链路，帮助定位瓶颈是网络开销、GPU排队还是特征拉取延迟。
实施追踪时需注意采样策略：全量采样成本过高，通常采用头部采样（根据请求ID一致性采样）或尾部采样（只保留慢请求或错误请求）。对于AI服务，建议对推理请求单独设置采样率，因为其调用频率高且单次延迟敏感。
trace_id和span_id，实现三类数据的关联。例如，当指标显示P99延迟升高时，可通过时间范围检索对应Trace，再通过Trace ID关联日志中的详细错误堆栈。
3.3 监控体系设计原则
构建监控体系不是工具堆砌，而是遵循以下四项核心原则：
- 面向用户旅程设计：监控指标必须与用户体验直接或间接相关。例如，支付系统的“成功率”比“数据库连接数”更接近用户感知。每个业务核心链路都应定义服务等级目标（SLO），监控围绕SLO展开。
- 分层覆盖，纵深防御：监控应覆盖基础设施层（主机、网络）、平台层（K8s、消息队列）、应用层（服务、API）、业务层（订单量、推荐点击率）。每一层有独立的告警阈值，避免跨层告警风暴。
- 高基数维度可控：允许按标签（Label）维度聚合，但需控制高基数标签（如用户ID、请求URL参数）的使用，防止存储膨胀和查询性能下降。建议将高基数信息放入日志而非指标。
- 告警必须可行动：每条告警都应包含故障现象、影响范围、疑似原因、临时缓解措施。避免“CPU高”这类无上下文告警，应转化为“订单服务CPU持续5分钟>85%，当前错误率上升至2%，建议扩容或排查死循环”。
3.4 案例：AI推理平台的监控体系搭建
某AI公司部署了基于Kubernetes的推理平台，提供图像分类服务。初期仅监控CPU和内存，导致多次线上事故无法快速定位。重构后的监控体系如下：
- 指标层：Prometheus采集GPU利用率、推理延迟直方图、队列深度、批处理大小、模型版本在线切换次数。
- 日志层：ELK收集推理请求的输入尺寸、预处理耗时、模型推理耗时、后处理耗时，以及错误堆栈。
- 追踪层：Jaeger记录从API网关到TensorFlow Serving的完整链路，特别标注GPU排队等待时间。
- 告警规则：当P99延迟超过500ms持续3分钟，且错误率>1%时，触发页面告警，并自动拉起一个Shadow Pod进行流量对比测试。
通过该体系，团队在一次模型升级后，发现新版本模型对长尾图片的推理耗时显著增加，而GPU利用率并未异常。通过追踪定位到是预处理阶段新增的归一化逻辑导致CPU瓶颈，快速回滚后恢复。
3.5 常见误区与复盘
误区二：日志与指标割裂。日志中无trace_id，指标异常时无法关联日志定位根因，只能靠人工猜测。
误区三：忽略监控自身的可靠性。监控系统单点部署，或采集器因资源竞争被OOM Kill，导致故障时监控反而“失明”。
误区四：静态阈值不适应动态流量。例如促销期间QPS翻倍，固定阈值导致频繁误报，应使用动态基线或百分比阈值。
复盘要点：监控体系应定期（每季度）进行“故障演练”，故意注入延迟或错误，验证监控是否能够快速发现并定位。同时，监控数据的保留周期需根据合规与调试需求设计，指标通常保留30天，日志保留15天，追踪采样数据保留7天。
监控体系的设计本质是工程决策，需要在成本、复杂度与可观测性之间取得平衡。从三大数据类型出发，遵循分层与可行动原则，结合AI场景的专属指标，才能构建真正支撑业务稳定性的监控底座。