Span（追踪）、Metric（指标）和Log（日志）是可观测性的三大支柱，它们在数据特点、处理方式和存储需求上存在显著差异，具体对比如下：
一、数据特点对比
| 维度 | Span（追踪） | Metric（指标） | Log（日志） |
|---|---|---|---|
| 数据类型 | 结构化的离散事件（树状结构） | 聚合的时间序列数据（数值） | 半结构化或非结构化文本 |
| 数据量 | 高基数（每个请求生成唯一Span），存储成本高 | 低基数（按指标名和标签聚合），存储成本低 | 高吞吐量（每秒数万条），存储成本高 |
| 时效性 | 短期分析（故障排查后可丢弃） | 长期趋势分析（需保留历史数据） | 短期高频访问，长期归档 |
| 核心价值 | 全链路请求路径，定位单点故障 | 系统宏观状态，趋势分析和告警 | 详细上下文，问题根因定位 |
二、处理方式对比
1. 采集阶段
-
Span：
- 通过 Agent/SDK 自动埋点（如 Java Agent、OpenTelemetry SDK）。
- 需记录完整调用链（Trace ID、Span ID、父子关系），对性能有一定影响（通常 <5% 额外开销）。
-
Metric：
- 通过采样（如每 10 秒采集一次 CPU 使用率）或聚合（如每分钟统计请求数）。
- 支持预聚合（如计算 p95 响应时间），降低传输和存储压力。
-
Log：
- 通过日志框架（如 Logback、Log4j）或文件收集器（如 Fluentd、Filebeat）采集。
- 支持过滤敏感信息（如正则替换密码）和结构化处理（JSON 格式）。
2. 处理阶段
-
Span：
- 关联分析：通过 Trace ID 关联同一请求的所有 Span。
- 聚合计算：统计 Span 耗时分布、错误率等。
- 问题：高基数导致存储和查询压力大，需定期清理历史数据。
-
Metric：
- 时间窗口聚合：按分钟/小时计算平均值、最大值、分位数。
- 降采样：长期数据降低精度（如 1 天数据保留分钟级，1 年数据保留小时级）。
- 告警触发：基于阈值或机器学习算法检测异常。
-
Log：
- 解析与结构化：提取关键字段（如时间戳、级别、用户 ID）。
- 全文索引：支持关键词搜索（如通过错误堆栈快速定位）。
- 关联分析：通过 Trace ID 关联日志与 Span/Metric。
3. 分析阶段
-
Span：
- 调用链可视化：展示请求在服务间的传递路径。
- 性能瓶颈分析：通过火焰图、耗时分布找出慢节点。
-
Metric：
- 多维分析：按标签分组（如服务名、环境）对比指标。
- 趋势预测：基于历史数据预测资源使用趋势。
-
Log：
- 异常检测：通过关键词匹配（如
ERROR、Exception）发现问题。 - 模式识别：分析日志序列（如登录失败 → 数据库连接异常）。
- 异常检测：通过关键词匹配（如
三、存储方案对比
1. 存储系统选型
| 类型 | 推荐存储系统 | 关键特性 |
|---|---|---|
| Span | Elasticsearch、Jaeger、Apache Cassandra | 支持高基数查询、全文搜索、快速写入 |
| Metric | 时序数据库（InfluxDB、Prometheus） | 高效时间序列存储、聚合查询、降采样 |
| Log | ELK Stack（Elasticsearch + Logstash + Kibana）、Grafana Loki | 全文索引、高吞吐量写入、可视化展示 |
2. 存储结构与优化
-
Span：
- 存储结构：按 Trace ID 聚合，每个 Trace 包含多个 Span。
- 优化：
- 冷热分离：近期数据存高性能存储（如 Elasticsearch），历史数据归档到低成本存储（如 S3）。
- 采样策略：对高频请求采样（如只存储 1% 的请求）。
-
Metric：
- 存储结构：键值对（指标名 + 标签 → 时间序列）。
- 优化：
- 预计算聚合值（如每日平均值），减少实时查询压力。
- 按时间分区（如每天一个文件），提升查询效率。
-
Log：
- 存储结构：文档形式（JSON 或文本）。
- 优化：
- 压缩存储（如使用 LZ4 压缩）。
- 按重要性分级存储（核心业务日志保留更久）。
3. 存储成本与时效
-
Span：
- 保留时间：通常 7-30 天（取决于业务需求和存储成本）。
- 成本：高（每条请求生成大量数据）。
-
Metric：
- 保留时间：短期（如 2 周）明细数据 + 长期（如 1 年）聚合数据。
- 成本：中（通过降采样控制）。
-
Log：
- 保留时间：关键日志（如错误日志）保留 30-90 天，普通日志保留 7-14 天。
- 成本：高（需处理和存储大量文本）。
四、典型技术栈对比
| 场景 | Span 解决方案 | Metric 解决方案 | Log 解决方案 |
|---|---|---|---|
| 开源方案 | OpenTelemetry + Jaeger/Elasticsearch | Prometheus + Grafana | ELK Stack（Elasticsearch + Kibana） |
| 云厂商方案 | AWS X-Ray、Google Cloud Trace | AWS CloudWatch、Azure Monitor | AWS CloudWatch Logs、Google Cloud Logging |
| 混合方案 | OpenTelemetry + 自定义存储 | Prometheus + Thanos（长期存储） | Fluentd + S3（归档） + Elasticsearch（查询） |
五、集成与联动
虽然三者存储和处理方式不同，但需通过 Trace ID 实现联动：
- Span → Metric：从 Span 提取指标（如请求耗时），生成性能指标。
- Span → Log：在 Span 中记录关键日志事件（如数据库查询参数）。
- Metric → Span：当指标异常时，关联查询对应时间窗口的 Span 链。
- Log → Span：通过日志中的 Trace ID 快速定位完整调用链。
通过这种联动，可构建完整的可观测性体系：从宏观指标发现问题 → 通过调用链定位故障点 → 通过日志获取详细上下文。