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技术决策矩阵

四、血泪教训：三基石实施中的五个深坑

1. 埋点混乱

   • 反例：某证券APP未统一TraceID格式 → 跨系统无法关联
   • 根治方案：强制OpenTelemetry规范（TraceID需含：appName+timestamp+random）

2. 采样过载

   • 反例：某短视频平台全量采集日志 → 日均存储成本¥50万
   • 黄金比例：
     • Metrics：100%采集
     • Logs：生产环境ERROR全采，INFO按1%采样
     • Traces：错误链路100%，正常请求<10%

3. 数据孤岛

   • 反例：某银行指标/日志/追踪存在三个系统 → 故障定位需人工串联
   • 破局关键：
     • 在Span中植入Logs关键字（如error_code）
     • 在Metrics标签中嵌入TraceID（如http_requests_total{trace_id="xyz"}）

4. 治理滞后

   • 反例：某P2P公司先建平台后治理 → 清理无效日志耗时6个月
   • 最佳实践：