可观测性：指标、健康与链路追踪

约 1371 字大约 5 分钟

布欧-Lewyon

2026-05-16

首页 › Spring Boot › 架构师进阶 › 可观测性：指标、健康与链路追踪

本篇服务 L4 架构师。假设你已经熟悉 Actuator 端点与基础日志配置（见生产部署与日志基础）。

可观测性（Observability）的三根支柱：Metrics（指标）、Logging（日志）、Tracing（链路追踪）。Spring Boot 通过 Actuator + Micrometer + Micrometer Tracing（取代旧版 Spring Cloud Sleuth）提供统一接入，但平台级可观测不止于"接入"——它关系到容量规划、SLO 定义、告警收敛等架构决策。

Metrics：Micrometer 与指标体系

Micrometer 门面设计

Micrometer 是 Boot 3.x/4.x 的指标门面，类似 SLF4J 之于日志。应用代码只依赖 Micrometer API，运行期绑定具体后端（Prometheus、Datadog、InfluxDB、New Relic 等）：

应用代码 → 注册表（MeterRegistry）→ 后端（Prometheus / Datadog / …）
                │
          PrometheusMeterRegistry（最常用）
          GraphiteMeterRegistry
          DatadogMeterRegistry
          LoggingMeterRegistry（调试用）

关键指标分类

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  metrics:
    tags:
      application: ${spring.application.name}    # 全局标签
    export:
      prometheus:
        enabled: true

指标类别	示例	来源	用途
JVM 内存	`jvm.memory.used`、`jvm.memory.max`	Micrometer JVM 扩展	堆/非堆使用率
GC	`jvm.gc.pause`、`jvm.gc.memory.promoted`	Micrometer JVM 扩展	GC 停顿时长与晋升
线程	`jvm.threads.live`、`jvm.threads.daemon`	Micrometer JVM 扩展	线程数趋势
请求	`http.server.requests`（含 method/status/uri 标签）	Actuator 自动注册	请求量、延迟分布、错误率
数据源	`hikaricp.connections.active`、`hikaricp.connections.idle`	HikariCP 自带	连接池饱和度
缓存	`cache.gets`、`cache.puts`	Cache 自动配置	缓存命中率
日志	`logback.events`（按级别统计）	Logback Appender	错误日志量监控

自定义指标

@RestController
public class OrderController {

    private final Counter orderCreateCounter;
    private final Timer orderCreateTimer;

    public OrderController(MeterRegistry registry) {
        this.orderCreateCounter = Counter.builder("order.create.total")
                .description("订单创建总数")
                .register(registry);
        this.orderCreateTimer = Timer.builder("order.create.duration")
                .publishPercentiles(0.5, 0.9, 0.99)   // p50/p90/p99
                .register(registry);
    }

    @PostMapping("/orders")
    public Result<Order> create(@RequestBody Order req) {
        return orderCreateTimer.record(() -> {
            Order order = orderService.create(req);
            orderCreateCounter.increment();
            return Result.success(order);
        });
    }
}

架构视角：指标维度与基数

L4 关注：http.server.requests 的 uri 标签如果包含动态路径（/users/{id}），会导致指标基数爆炸（每个 ID 产生一个时间序列）。高基数会压垮 Prometheus 的 TSDB。正确做法：在 WebMvcMetricsFilter 或 ServerHttpObservationFilter 中将 URI 恢复为模式化路径。Spring Boot 默认已通过 DispatcherServlet 的 bestMatchingPattern 处理，但自定义 Filter 或非标准路由需人工验证。

健康检查：从 UP/DOWN 到 SLO

Actuator 的健康检查是存活/就绪探针的数据源，但其能力不止于此：

management:
  endpoint:
    health:
      show-details: when-authorized
      probes:
        enabled: true                    # Boot 3+ 启用 K8s 探针
  health:
    readinessstate:
      enabled: true
    livenessstate:
      enabled: true

扩展自定义健康指标：

@Component
public class ExternalServiceHealthIndicator implements HealthIndicator {

    @Override
    public Health health() {
        // 对外部依赖做浅检测
        boolean reachable = checkConnectivity();
        if (reachable) {
            return Health.up().withDetail("latency_ms", measureLatency()).build();
        }
        return Health.down(new Exception("无法连接到外部服务")).build();
    }
}

架构视角：健康检查粒度

L4 关注：一个"DOWN"的健康状态可能触发 Pod 被 K8s 杀死重启——但并非所有 DOWN 都需要立即重启。例如：磁盘空间 90% 是 WARN 级别，但某次突发写入导致某一缓存组件响应慢——这时将整个应用标记为 DOWN 可能导致雪崩。建议区分：
Liveness：应用进程是否存活（仅检查 JVM / 内部组件）
Readiness：应用是否可接收流量（检查关键依赖——数据库、消息队列）
Health 细粒度：自定义 HealthContributor 用 Status.DOWN / OUT_OF_SERVICE / UNKNOWN 区分降级程度

Tracing：Micrometer Tracing

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
    <groupId>io.zipkin.reporter2</groupId>
    <artifactId>zipkin-reporter-brave</artifactId>
</dependency>

management:
  tracing:
    sampling:
      probability: 0.1                    # 10% 采样率（生产通常 0.01–0.1）
    propagation:
      type: w3c                           # W3C TraceContext（建议）或 b3

自动为 RestTemplate、RestClient、WebClient、@Async、JDBC 等注入 TraceId。通过 Zipkin 或 Jaeger 查看跨服务调用链。

架构视角：采样与成本

L4 关注：100% 采样的链路数据量大约占请求吞吐的 10–20% 额外存储成本。高吞吐服务（>10k req/s）全采样会耗尽存储和 CPU。推荐头采样（Head-based） + 尾采样（Tail-based） 混合：头采样（如 1%）用于常规统计，尾采样对错误/慢请求（>p99）做额外保留。生产环境下重点关注 TraceId 在日志中的可关联性——即使链路追踪系统不可用，日志中的 TraceId 也能跨服务串联排错。

架构视角：可观测与 SLO 的衔接

可观测的最终目的不是"有数据"，而是支撑 SLO（服务等级目标）：

SLO 目标	对应指标	告警阈值示例
可用性 99.9%	`http.server.requests`（5xx 占比）	错误率 > 0.1%（1 分钟窗口）
p99 延迟 < 500ms	`http.server.requests` p99	p99 > 500ms（5 分钟窗口）
连接池不耗尽	`hikaricp.connections.active / maximum-pool-size`	使用率 > 80%（持续 2 分钟）

演进风险：可观测系统本身也可能成为故障点——大量指标/链路采集可能加剧应用性能抖动。建议①采样率从低起步（0.1%），②对 MeterRegistry 做背压控制，③监控可观测系统的自身资源（Prometheus 内存、ES/Loki 磁盘）。

小结

可观测性三支柱：Metrics（Micrometer + Prometheus）、Logging（Logback + 集中式日志）、Tracing（Micrometer Tracing + Zipkin/Jaeger）。
Actuator 健康检查需要区分 Liveness / Readiness 粒度，避免过度重启。
SLO 驱动告警配置：可用性、p99 延迟、资源饱和度是三大黄金信号。
架构视角：指标基数爆炸、Tracing 采样策略、可观测基建的自保能力。
思考任务：为现有应用添加 Prometheus 指标暴露，在本地用 Prometheus + Grafana 验证 http.server.requests 的 p99 和错误率面板；调整 management.tracing.sampling.probability 从 1.0 降到 0.01，观察吞吐量变化。

上一节：生产部署

下一节：韧性与容错