跳至主要內容

可观测

可观测性是指通过系统输出的日志、链路、指标，在不修改系统的情况下推断出内部状态。微服务越多，可观测性越重要。服务治理 发现问题，可观测性定位问题。

提示

日志、链路追踪、指标的分布式系统观测体系

适用场景

  • 分布式系统故障定位：通过 Traces 追踪请求链路，快速定位故障节点
  • 性能瓶颈分析：通过 Metrics 监控 QPS、延迟、资源使用率
  • 生产环境问题排查：通过 Logs 结合 TraceId 还原问题现场
  • 容量规划：基于历史指标数据预测资源需求
  • SLA/SLO 监控：定义服务水平目标并设置告警阈值

三大支柱

支柱定义工具
Metrics数值型定量测量（QPS、CPU）Prometheus, Micrometer
Logs带时间戳的离散事件记录ELK, Loki
Traces单次请求的完整调用路径Jaeger, Zipkin

三者协同：Metrics 触发告警 → Traces 定位链路 → Logs 查看细节。

Metrics

Metrics 是系统运行状态的量化指标，用于直观反映系统健康状况。

四种指标类型

类型说明示例
Counter单调递增请求总数、错误总数
Gauge任意增减的瞬时值内存使用量
Histogram统计分布，支持分位数延迟分布（P99）
Summary客户端计算分位数响应时间 P50/P95

Prometheus + Grafana

Exporter → Prometheus（拉取存储）→ Grafana（可视化）
                                     → Alertmanager（告警）

Prometheus 使用 Pull 模式主动拉取指标，与 Kubernetes 原生集成，自动发现服务。

scrape_configs:
  - job_name: 'spring-boot-app'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/actuator/prometheus'

Logs

Logs 记录系统运行时的离散事件，是排查问题的重要依据。

结构化日志

传统日志难以机器解析，推荐结构化格式（JSON），且必须携带 TraceId 用于关联链路追踪。

{
  "timestamp": "2026-04-14T10:00:00Z",
  "level": "ERROR",
  "traceId": "abc123def456",
  "service": "order-service",
  "message": "下单失败",
  "error": "库存不足"
}

日志收集架构

应用 → Logstash/Promtail → Elasticsearch/Loki → Kibana/Grafana

Traces

Traces 记录单个请求在分布式系统中的完整调用路径，用于定位问题链路。

TraceId / SpanId 机制

TraceId: abc123（全局唯一，贯穿整个请求）

Span 结构:
├── 网关        [SpanId: 001, ParentSpanId: null]
├── 订单服务     [SpanId: 002, ParentSpanId: 001]
│   ├── 库存服务 [SpanId: 003, ParentSpanId: 002]
│   └── 支付服务 [SpanId: 004, ParentSpanId: 002]

每个 Span 记录：服务名、开始时间、持续时间、状态、自定义标签。

Jaeger vs Zipkin

维度ZipkinJaeger
来源TwitterUber（CNCF 毕业）
存储内存、MySQL、CassandraElasticsearch、Cassandra
适用轻量，中小项目大规模系统

Spring Boot 集成

management:
  tracing:
    sampling:
      probability: 1.0  # 生产建议 0.1

TraceId 自动透传（HTTP Header、MQ 消息头），日志自动携带。

OpenTelemetry

OpenTelemetry（OTel）是 CNCF 托管的统一可观测性规范，由 OpenTracing + OpenCensus 合并而来，核心目标是避免厂商锁定，用一套 API 对接任意后端。

应用（OTel SDK）→ OTel Collector → Jaeger/Prometheus/Loki

推荐新项目使用 OTel，与 云原生架构 中的 Kubernetes 生态深度集成。

告警原则

原则说明
SLO 驱动基于用户体验指标设置告警
减少噪音告警必须有行动意义
分级处理P0（立即响应）、P1（1小时内）、P2（工作时间）

实践路径

阶段方案
基础Prometheus + Grafana（指标）+ ELK（日志）
进阶加入 Jaeger（链路追踪），日志携带 TraceId
云原生OTel + Grafana 全家桶

常见问题

Q: Metrics、Logs、Traces 应该先上哪个？

A: 先上 Metrics（Prometheus + Grafana），成本最低、见效最快。能发现「有问题」后，再上 Traces 定位「问题在哪」，最后补 Logs 看「具体细节」。

Q: 采样率应该设置多少？

A: 开发环境 100%（全量采集），生产环境建议 10%（probability: 0.1）。对核心链路可动态调整为 100%。

Q: Jaeger 和 Zipkin 怎么选？

A: 中小项目用 Zipkin（轻量、部署简单），大规模系统用 Jaeger（CNCF 毕业、存储扩展性好）。新项目建议直接用 OTel + Jaeger。

Q: 日志太多怎么控制成本？

A: 1) 结构化日志按级别过滤，生产环境只收集 WARN 以上；2) 使用 Loki 替代 ELK（成本低 10x）；3) 设置日志保留策略（如 7 天）。

Q: OpenTelemetry 和直接用 Jaeger SDK 有什么区别？

A: OTel 是标准规范，一套 SDK 可对接多个后端（Jaeger、Prometheus、Loki），避免厂商锁定。直接用 Jaeger SDK 只能对接 Jaeger，迁移成本高。