1. 项目背景与核心挑战
得物作为国内领先的潮流电商平台，其算法系统每天需要处理数亿级别的商品推荐、搜索排序、图像识别等请求。随着业务复杂度提升，我们遇到了几个典型问题：
- 算法效果波动无法快速归因
- 线上异常响应时间增加但缺乏有效观测手段
- 多算法模块协同时的相互影响难以量化
这些问题直接影响了用户体验和转化率。传统监控方案存在三个致命缺陷：
- 指标维度单一（仅CPU/内存等基础指标）
- 数据孤岛现象严重（日志、指标、链路彼此割裂）
- 缺乏业务语义关联（无法映射到算法效果指标）
2. 全景可观测性体系设计
2.1 技术架构选型
我们采用分层观测架构：
应用层：业务指标埋点（CTR、转化率等） 算法层：特征分布、模型版本、推理耗时 资源层：容器指标、GPU利用率关键组件选型对比：
| 需求场景 | 候选方案 | 最终选择 | 选择理由 |
|---|---|---|---|
| 指标存储 | Prometheus vs TDengine | TDengine | 支持高基数维度，压缩比优异 |
| 日志分析 | ELK vs Loki | Loki | 轻量级，与Prometheus生态集成 |
| 分布式追踪 | Jaeger vs SkyWalking | SkyWalking | 对Java生态支持更完善 |
2.2 核心埋点设计
以推荐算法为例，我们在三个关键位置植入观测点：
- 特征处理阶段：
# 特征统计埋点示例 @monitor.histogram( name="feature_stats", dimensions=["feature_name", "model_version"], buckets=[0, 0.1, 0.5, 1] ) def process_feature(raw_data): # 特征处理逻辑 return normalized_feature- 模型推理阶段：
- 记录请求量/耗时百分位值
- 捕获异常输入样本
- 监控GPU显存波动
- 业务效果反馈：
- 实时对接点击/转化埋点
- AB实验分组效果对比
3. 关键实现细节
3.1 指标关联分析
通过TraceID实现跨系统关联：
- 在网关层注入TraceID
- 通过OpenTelemetry SDK透传
- 在数据湖中使用如下SQL关联分析：
SELECT a.model_version, b.gpu_utilization, c.ctr FROM algorithm_metrics a JOIN resource_metrics b ON a.trace_id = b.trace_id JOIN business_metrics c ON a.trace_id = c.trace_id WHERE a.create_time > NOW() - INTERVAL '1' HOUR3.2 动态基线告警
采用时间序列预测实现智能告警：
- 使用Prophet算法训练历史数据
- 动态计算置信区间
- 异常检测逻辑：
def check_anomaly(current_value, ts_model): lower, upper = ts_model.predict(confidence=0.95) if not (lower <= current_value <= upper): send_alert( metric=current_value.name, expected_range=(lower, upper) )4. 典型问题排查案例
4.1 推荐效果突降分析
通过观测系统快速定位的步骤：
- 发现CTR下降15%（业务层）
- 关联查到特征分箱分布偏移（算法层）
- 追溯至特征工程服务内存泄漏（资源层）
- 根本原因：第三方特征库版本冲突
4.2 推理耗时毛刺问题
排查工具链组合：
- SkyWalking定位慢请求Trace
- Py-Spy获取火焰图
- 发现CUDA同步等待问题
- 优化方案：
- 调整batch_size从256→128
- 增加CUDA流数量
5. 演进路线与未来规划
当前已实现的观测能力：
- 98%的指标实现秒级采集
- 85%的异常能在5分钟内预警
- 根因分析效率提升3倍
下一步重点：
- 因果推理能力增强
- 自动化根因分析
- 观测数据反哺算法训练
关键经验：在图像算法服务中，我们发现GPU利用率指标需要细粒度到CUDA kernel级别才有价值，这促使我们开发了定制化的NVIDIA DCGM exporter。
