解剖智能运维三基石：Metrics/Logs/Traces
3秒知识卡
三基石关系：
Metrics（指标）→ 系统脉搏（CPU/错误率）
Logs（日志）→ 事件日记（错误堆栈/用户行为）
Traces（追踪）→ 血缘地图（请求跨服务路径）
协同价值：故障定位速度提升 10倍（MTTR从1小时→6分钟）
一、为什么必须是这三个？运维数据界的“水粮氧”
1. 从支付系统故障看三基石协同作战
故障现场：
- 用户支付失败率突增30%，但服务器CPU/内存指标全部正常
排查过程：
关键角色：
- Metrics：发现业务指标异常（但无法解释原因）
- Logs：找到错误关键词“Connection timeout”
- Traces：还原完整调用链（穿透12个微服务）
结果对比：
- 传统方式：4人团队排查3小时
- 三基石联动：6分钟定位证书过期
2. 三者本质差异与互补性
| 维度 | Metrics | Logs | Traces |
|---|---|---|---|
| 数据结构 | 数值型（时间序列） | 文本型（非结构化） | 树形拓扑（请求链路） |
| 核心价值 | 量化健康度（如错误率） | 记录事件上下文（如异常堆栈） | 还原调用关系（如服务依赖） |
| 存储成本 | 低（1TB/月） | 高（原始日志100TB/月） | 中（采样后10TB/月） |
| 典型案例 | Prometheus监控仪表盘 | ELK排错日志 | Jaeger链路追踪图 |
二、深度治理指南：金融级数据治理框架
1. Metrics治理四步法（携程50亿/分钟实践）
架构图：
关键治理策略：
- 降采样：原始秒级数据→按业务保留策略（如核心交易保留1年原始数据，非核心服务仅留小时级聚合值）
- 动态聚合：自动识别热点指标（如支付延迟）实时计算P99分位值
- 成本控制：通过标签（env=prod）区分存储等级，冷数据转存S3
2. Logs治理三大战场（某银行日志压缩率95%）
致命痛点：
- 开发随意打印日志 → 单日2PB无效日志（DEBUG日志占比70%）
治理方案：
技术组合：
- 采集：Filebeat（轻量级）+ OpenTelemetry（标准化）
- 处理：Loki（日志聚类）+ Flink（实时分析）
- 存储：ES热数据保留7天 + MinIO冷数据归档
3. Traces治理黄金法则（穿透387个微服务的秘密）
核心挑战：
- 微服务链路追踪成本指数级增长（100万QPS → 每日TB级Span数据）
携程实战方案：
关键决策：
- 采样策略：
- 错误请求：100%采样
- 慢查询：>200ms全留存
- 正常请求：随机5%采样
- 存储优化：
- 仅存储关键Span（DB调用/RPC通信）
- 丢弃中间件内部Span
三、技术选型决策树：不再被厂商绑架
Metrics方案选择（根据数据规模）
Logs架构选型（根据业务需求）
| 场景 | 推荐方案 | 案例说明 |
|---|---|---|
| 实时故障排查 | ELK/EFK | 某电商日志检索＜3秒 |
| 长期合规审计 | Loki+S3 | 金融业7年归档成本降80% |
| 安全威胁分析 | Splunk+机器学习引擎 | 检测黑客攻击行为 |
Traces技术决策矩阵
四、血泪教训：三基石实施中的五个深坑
-
埋点混乱
- 反例：某证券APP未统一TraceID格式 → 跨系统无法关联
- 根治方案：强制OpenTelemetry规范（TraceID需含：appName+timestamp+random）
-
采样过载
- 反例：某短视频平台全量采集日志 → 日均存储成本¥50万
- 黄金比例：
- Metrics：100%采集
- Logs：生产环境ERROR全采，INFO按1%采样
- Traces：错误链路100%，正常请求<10%
-
数据孤岛
- 反例：某银行指标/日志/追踪存在三个系统 → 故障定位需人工串联
- 破局关键：
- 在Span中植入Logs关键字（如error_code）
- 在Metrics标签中嵌入TraceID（如http_requests_total{trace_id="xyz"}）
-
治理滞后
- 反例：某P2P公司先建平台后治理 → 清理无效日志耗时6个月
- 最佳实践：
