可观测性三件套#

全景概览#

采集标准现状： OpenTelemetry（OTel）已成为三类数据统一的采集标准（SDK + Collector + OTLP 协议），Traces/Metrics/Logs 三类信号的规范均已 stable（各语言 SDK 成熟度不一）；Profiles 作为第四类信号仍在 Alpha。后端存储仍可选 Prometheus / ES / Jaeger 等。

1. Metrics —— 发现问题#

四种指标类型（Prometheus）：

核心监控指标（RED 方法）：

• Rate：请求速率（QPS）
• Errors：错误率（5xx 比例）
• Duration：延迟分布（P50/P99/P999）

告警规则示例：

# 5 分钟内错误率 > 5% 触发告警
- alert: HighErrorRate
  # 分子分母都要 sum 聚合掉 status 标签，否则按标签一一匹配，5xx 序列只会和自己相除
  expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
  for: 2m

2. Logging —— 确认根因#

结构化日志#

为什么用 JSON 而不是纯文本？

• 纯文本：2026-05-25 10:30:00 ERROR OrderService - 创建订单失败: 库存不足
• 结构化：

{
  "timestamp": "2026-05-25T10:30:00.123Z",
  "level": "ERROR",
  "service": "order-service",
  "traceId": "abc123def456",
  "spanId": "span789",
  "class": "OrderService",
  "method": "createOrder",
  "userId": 12345,
  "orderId": "ORD-20260525-001",
  "message": "创建订单失败",
  "reason": "库存不足",
  "skuId": "SKU-100"
}

结构化日志能被 ES 索引，支持按任意字段搜索和聚合。

TraceID 透传#

请求进入网关 → 生成 TraceID（如 UUID）
  → 放入 HTTP Header（X-Trace-Id）
  → 服务 A 取出放入 MDC（SLF4J）
  → 服务 A 调用服务 B 时透传 Header
  → 所有服务的日志都带同一个 TraceID
  → 在 ELK 中按 TraceID 搜索 → 一次请求的全链路日志

Spring Boot 实现： Spring Boot 3+ 用 Micrometer Tracing（桥接 Brave 或 OpenTelemetry）自动生成/透传 TraceID 并放入 MDC，默认用 W3C traceparent 头；Spring Cloud Sleuth 只支持 Spring Boot 2.x，已停止维护。

日志级别规范#

注意： 生产环境日志级别通常设 INFO，不要开 DEBUG——日志量会暴增。

ELK 架构#

应用日志 → Filebeat（采集） → Logstash（解析/过滤） → Elasticsearch（存储/索引） → Kibana（查询/可视化）

3. Tracing —— 定位链路#

核心概念#

• Trace：一次完整请求的调用链，由一个 TraceID 标识
• Span：Trace 中的一个操作单元（如一次 RPC 调用、一次 DB 查询）
• Parent-Child：Span 之间的父子关系构成调用树

Trace: abc123
├── Span 1: API Gateway (50ms)
│   ├── Span 2: Order Service (30ms)
│   │   ├── Span 3: MySQL Query (5ms)
│   │   └── Span 4: Redis Get (2ms)
│   └── Span 5: Inventory Service (15ms)
│       └── Span 6: MySQL Update (8ms)

Jaeger vs SkyWalking#

三者协同排障流程#

1. Grafana 告警：订单服务 P99 延迟从 200ms 飙升到 2s
   ↓
2. Jaeger/SkyWalking 查看慢 Trace：
   发现 Span "Redis Get" 从 2ms 变成 800ms
   ↓
3. Kibana 搜索该 TraceID 的日志：
   发现 Redis 连接池满，等待获取连接
   ↓
4. 根因：Redis 连接数配置过小 + 流量突增
   ↓
5. 修复：调大连接池 + 加连接池监控指标

日志敏感信息脱敏#

生产日志中不能出现：

• 用户密码、Token
• 完整手机号、身份证号
• 信用卡号

脱敏方式： 日志框架层做正则替换，或用 Logback 的自定义 Converter。

可观测性三件套是Metrics、Tracing和Logging，三者协同才能在微服务环境下快速定位问题。Metrics回答”系统是不是有问题”，用Prometheus+Grafana监控RED指标（请求速率、错误率、延迟分布），发现P99飙高了就知道有问题。Tracing回答”问题在哪个环节”，通过Jaeger或SkyWalking查看分布式调用链，一个Trace由多个Span组成，能精确看到哪个服务、哪个SQL慢了。Logging回答”具体错了什么”，在ELK中按TraceID搜索，拿到那一次请求经过所有服务的完整日志，确认根因。实际排障流程就是这三步闭环：Grafana告警触发→查Trace定位慢Span→搜日志确认根因→修复→补监控。关键实践：日志必须结构化JSON并透传TraceID，否则微服务环境下日志散落各处根本没法串联。

追问方向：

• “Metrics 和 Tracing 有什么区别？”→ Metrics 是聚合数据（知道”慢了”），Tracing 是个体数据（知道”谁慢了”）
• “日志量太大怎么办？”→ 采样（只记录 10% 的 Trace）+ 日志分级 + 冷热分离
• “你项目中怎么做的监控？”→ 按三层讲清楚即可：① 指标——应用暴露 /actuator/prometheus，Prometheus 抓取，Grafana 看 RED + JVM（GC、堆、线程池）+ 中间件指标，告警走 Alertmanager；② 链路——OTel/SkyWalking Agent 自动埋点，采样率按流量定（如 10%，错误请求全采）；③ 日志——JSON 格式带 traceId，Filebeat 采到 ES。最后举一次”告警→查 Trace→查日志→定根因→补监控”的完整排障例子

易错点：

• ❌ 只有 Metrics 没有 Tracing——知道系统慢但不知道慢在哪
• ❌ 日志不带 TraceID——微服务环境下无法串联一次请求的完整日志
• ❌ 所有日志都打 INFO——要么日志太少看不出问题，要么太多找不到重点