# Petclinic 统一诊断体系：从 P99 三秒沿证据链定位慢点

```text
旧方案：日志、指标、链路三套独立，靠人肉 grep 与经验猜
冲突：P99 从 100ms 涨到 3s，告警响了却不知道先看哪
后果：MTTR 从分钟级拖到小时级，回滚靠运气，复盘无证据
```

Petclinic 已经接入了 Actuator、Prometheus 抓取、基础 JVM 指标，但每次线上变慢，团队还是先打开日志翻 stack trace，再切到 Grafana 看 CPU，最后

才想起链路系统。

我是老李，这次被拉进一个真实故障：Owner 查询接口 P99 从 100ms 涨到 3s，用户投诉、老板催、监控告警同时响。

日志里没有异常，CPU 没打满，数据库连接池也没满，那这 3 秒到底花在哪？

是继续加日志重新发布，还是先建立一条从 HTTP 到 SQL、Redis、远程调用的统一证据链？

如果选错，会不会在错误方向上优化半天，最后发现慢在第三方保险报价服务？

# 01、故事

```text
周二 14:30 → 生产环境 → 任务：定位 Owner 查询 P99 三秒 → 冲突：日志无异常、CPU 不高、连接池没满
```

周二下午两点半，生产环境告警群突然刷屏：petclinic-owner-service 的 HTTP P99 超过 3 秒。

任务是半小时内给出初步结论，但打开 Kibana 只有正常请求日志，打开 Grafana 看到 CPU 不到 40%，Hikari 活跃连接只有 5 个。

我盯着三块屏幕，感觉像在三个互不相通的房间里找一只猫。

> 告警声里翻日志，
> 三块屏幕各说各话。
> 猫在哪个房间，
> 没人递来一根线。

# 02、问题

```text
需求变化：业务新增保险报价远程调用 → 冲突：慢请求无统一上下文 → 后果：无法判断慢在 JVM、线程、SQL、Redis 还是远程 HTTP
```

Owner 查询原本只查数据库和缓存，最近为了给宠物主展示保险报价，新增了一次对第三方保险服务的远程调用。

慢请求出现后，日志、指标、链路三套体系各自为政：日志有 traceId 但没和指标关联，指标有 P99 但不知道是哪个 SQL 拖的，链路有 span 但没和 JVM 线程池指标对齐。

可验证的验收标准是：任意一个慢请求，能在 5 分钟内从 HTTP 入口一路看到 JVM 线程、Hikari、SQL、Redis、远程 HTTP 的耗时分布。

> 三套体系三座岛，
> 桥没架好船没到。
> 慢请求像一阵风，
> 吹过无痕找不到。

# 03、原理

```text
Observation = 统一上下文 + 低基数标签 + 高基数标签 + 事件 + 计时
```

Micrometer Observation 把一次操作抽象成一个 Observation，同时向日志、指标、链路三个出口输出。

一个 Observation 包含低基数标签（如服务名、接口名、结果状态）和高基数标签（如 ownerId、traceId），低基数进 Prometheus，高基数进链路系统。

反直觉的是：不是所有标签都该进指标，高基数标签会撑爆 Prometheus 时间序列，但高基数标签恰恰是排障时最需要的线索。

Observation 的 Timer 和 LongTaskTimer 是两回事：Timer 记录已完成操作的耗时分布，LongTaskTimer 记录正在执行的长任务数量，慢请求排查要先用 Time

r 定位，再用 LongTaskTimer 看是否堆积。

> 一根线穿过三座岛，
> 低基数进指标，
> 高基数进链路，
> 反直觉处见分晓。

# 04、架构

```text
HTTP 入口 → ObservationFilter → OwnerService(Observation) → Hikari/SQL/Redis/Remote HTTP → ObservationRegistry → Logging/Metrics/Tracing
```

在 Petclinic 中，Owner 查询的调用链是：HTTP 入口先创建根 Observation，OwnerService 在方法上声明 Observation，内部对 SQL、Redis、远程

HTTP 分别创建子 Observation。

所有 Observation 注册到同一个 ObservationRegistry，由它分发给 LoggingHandler、MeterHandler、TracingHandler。

边界是：低基数标签只进 Meter，高基数标签只进 Tracing，日志只拿 traceId 和关键事件。

收益是排障时能沿一条证据链走到底；代价是每个关键操作都要埋点，代码侵入性比纯 AOP 高。

> 入口一根线，
> 内部三根线，
> 注册中心分三路，
> 证据链上见。

# 05、第一版实战

```text
环境：Spring Boot 4 + Petclinic → 配置：micrometer-tracing + observation → 代码：OwnerService 埋点 → 启动 → 验证：/owners/{id} → V1：只有 HTTP 和 SQL 两个 Observation
```

第一版先给 Owner 查询加最基础的 Observation。

在 `pom.xml` 中加入 Micrometer Tracing 和 Observation 自动配置：

```xml
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-observation</artifactId>
</dependency>
```

在 `OwnerController` 中注入 `ObservationRegistry`，给查询方法创建 Observation：

```java
@GetMapping("/owners/{ownerId}")
public OwnerDto getOwner(@PathVariable Long ownerId) {
    return Observation.createNotStarted("owner.find", registry)
        .lowCardinalityKeyValue("api", "getOwner")
        .highCardinalityKeyValue("ownerId", ownerId.toString())
        .observe(() -> ownerService.findOwner(ownerId));
}
```

在 `OwnerService` 中给 SQL 查询加子 Observation：

```java
public OwnerDto findOwner(Long ownerId) {
    return Observation.createNotStarted("owner.find.sql", registry)
        .lowCardinalityKeyValue("db", "petclinic")
        .observe(() -> ownerRepository.findById(ownerId)
            .map(this::toDto)
            .orElseThrow(() -> new ResourceNotFoundException("Owner not found")));
}
```

启动应用后，用 curl 验证：

```bash
curl -s http://localhost:8080/owners/1 | jq .
```

示例输出：

```json
{
  "id": 1,
  "firstName": "George",
  "lastName": "Franklin",
  "pets": []
}
```

访问 Actuator 的 Prometheus 端点验证指标：

```bash
curl -s http://localhost:8080/actuator/prometheus | grep owner_find
```

示例输出：

```text
owner_find_seconds_count{api="getOwner",error="none"} 12
owner_find_seconds_sum{api="getOwner",error="none"} 0.84
```

V1 成功标准：HTTP 和 SQL 两个 Observation 都有计时指标，traceId 出现在日志中。

> 第一版埋下两根线，
> HTTP 和 SQL 各一边。
> 指标里有了计数，
> 日志里有了 traceId。

# 06、排查

```text
诊断树：P99 三秒 → 是 HTTP 慢还是 SQL 慢？ → 是线程等待还是执行慢？ → 是远程调用还是本地资源？
```

V1 上线后，P99 还是 3 秒，但这次有了证据链。

第一个问题：HTTP 总耗时 3 秒，但 SQL 子 Observation 只有 80ms，说明慢点不在数据库。

检查命令：

```bash
curl -s http://localhost:8080/actuator/prometheus | grep -E 'owner_find_seconds|owner_find_sql_seconds'
```

示例输出：

```text
owner_find_seconds_sum 3.1
owner_find_sql_seconds_sum 0.08
```

第二个问题：HTTP 和 SQL 之间差了 2.9 秒，怀疑是线程等待或远程调用。

检查 Tomcat 线程指标：

```bash
curl -s http://localhost:8080/actuator/prometheus | grep tomcat_threads
```

示例输出：

```text
tomcat_threads_busy 18
tomcat_threads_current 200
tomcat_threads_config_max 200
```

线程没满，排除线程池耗尽。

**错误尝试：** 一开始怀疑是 Hikari 连接池等待，加了 `hikaricp_connections_pending` 指标，发现 pending 一直是 0，浪费了 20 分钟。

第三个问题：V1 没有给远程 HTTP 调用埋点，所以看不到保险报价服务的耗时。

根因：Owner 查询新增的保险报价远程调用没有纳入 Observation，导致证据链在 HTTP 和 SQL 之间断了。

> 先看总再看分，
> SQL 只要八十毫秒。
> 线程没满池没等，
> 断点藏在远程调用。

# 07、优化

```text
V1：HTTP + SQL 两个 Observation → 证据：HTTP 3s、SQL 80ms、线程未满 → V2：补上 Redis、远程 HTTP、Hikari 的 Observation
```

V2 给远程 HTTP 调用、Redis 缓存、Hikari 连接获取都加上 Observation。

在 `InsuranceClient` 中给远程调用埋点：

```java
public QuoteDto getQuote(Long ownerId) {
    return Observation.createNotStarted("owner.insurance.remote", registry)
        .lowCardinalityKeyValue("remote", "insurance-service")
        .highCardinalityKeyValue("ownerId", ownerId.toString())
        .observe(() -> restClient.get()
            .uri("/quotes?ownerId=" + ownerId)
            .retrieve()
            .body(QuoteDto.class));
}
```

在 `OwnerService` 中给 Redis 缓存查询埋点：

```java
public OwnerDto findOwner(Long ownerId) {
    return Observation.createNotStarted("owner.find.redis", registry)
        .lowCardinalityKeyValue("cache", "redis")
        .observe(() -> {
            String cached = redisTemplate.opsForValue().get("owner:" + ownerId);
            if (cached != null) {
                return objectMapper.readValue(cached, OwnerDto.class);
            }
            OwnerDto dto = findOwnerFromDb(ownerId);
            redisTemplate.opsForValue().set("owner:" + ownerId, objectMapper.writeValueAsString(dto));
            return dto;
        });
}
```

在 `application.yaml` 中开启 Hikari 指标：

```yaml
spring:
  datasource:
    hikari:
      register-mbeans: true
management:
  metrics:
    enable:
      hikaricp: true
```

重新启动后，用同一组请求验证：

```bash
for i in $(seq 1 20); do curl -s -o /dev/null http://localhost:8080/owners/1; done
curl -s http://localhost:8080/actuator/prometheus | grep -E 'owner_insurance_remote_seconds|owner_find_redis_seconds'
```

示例输出：

```text
owner_insurance_remote_seconds_sum 2.85
owner_find_redis_seconds_sum 0.02
```

证据链闭合：HTTP 3 秒，远程保险报价 2.85 秒，SQL 80ms，Redis 20ms。

> 补上远程和缓存，
> 证据链终于闭合。
> 三秒里两秒八五，
> 慢在第三方报价服务。

# 08、演进

```text
V2：完整 Observation 证据链 → 能力：5 分钟定位慢点 → 遗留：远程服务内部不可见
```

V2 用同一组请求前后验证：V1 时只能看到 HTTP 3 秒和 SQL 80ms，V2 后能看到远程保险报价占 2.85 秒。

收益是 MTTR 从小时级降到分钟级，排障不再靠猜。

代价是每个关键操作都要手动埋点，代码量增加约 15%。

适用条件是：调用链清晰、关键操作可枚举；不适用于动态生成的大量细粒度操作。

遗留问题是：远程保险服务内部慢在哪，Petclinic 侧看不到，需要对方也接入 Observation 或提供 span 导出。

> 从三秒到两秒八五，
> 证据链上走一遍。
> 代价是埋点十五行，
> 遗留是远程内部看不见。

# 09、洞见

```text
从现象到判断：P99 三秒不是单点问题，是证据链断裂问题
```

## 低基数与高基数标签的边界是排障效率的分水岭
```text
低基数 → Prometheus 聚合
高基数 → 链路系统检索
混用 → 时间序列爆炸
```

反直觉判断：把 ownerId 放进 Prometheus 指标会让时间序列数量随用户数线性增长，最终拖垮监控系统；但排障时没有 ownerId 又无法定位具体慢请求。

正确做法是低基数进指标、高基数进链路，两者通过 traceId 关联。

## Timer 和 LongTaskTimer 回答的是两个不同的问题
```text
Timer → 完成了多少、平均多慢
LongTaskTimer → 现在有多少在跑、跑了多久
```

反直觉判断：P99 涨到 3 秒时，先看 Timer 的 count 和 sum，再看 LongTaskTimer 的 active 数量；

如果 active 数量突增，说明请求堆积，根因可能在入口而非下游。

## 证据链的价值不在采集，而在关联
```text
日志有 traceId → 指标有标签 → 链路有 span
三者不关联 → 三座孤岛
```

Observation 的核心不是多采几个指标，而是让日志、指标、链路共享同一个上下文，排障时能从一个点跳到另一个点。

## 远程调用必须作为一等公民埋点
```text
本地资源 → 可观测
远程依赖 → 必须可观测
```

Petclinic 的教训是：新增远程调用时没有同步埋点，导致证据链断裂；远程依赖的观测成本要计入功能开发成本。

> 低基数进指标，
> 高基数进链路。
> Timer 看完成，
> LongTask 看堆积。

# 10、系统落地

```text
入口：HTTP /owners/{id} → 服务：OwnerService → 本模块：Observation 证据链 → 存储：Prometheus + 链路后端 → 未实现：远程服务内部观测
```

原来 Petclinic 有 Actuator 基础指标和分散的日志，但没有统一诊断体系。

本篇增加了 Micrometer Observation 统一上下文，覆盖 HTTP、SQL、Redis、远程 HTTP、Hikari 五个关键环节。

现在能做什么：任意慢请求可在 5 分钟内沿证据链定位到具体环节。

下一篇缺什么：远程保险服务内部不可见，需要接入 OpenTelemetry Collector 或要求对方导出 span。

官方文档可参考 Spring Boot 文档首页和 Micrometer 文档首页。

> 入口到服务到存储，
> 五环埋点一条线。
> 本篇补上证据链，
> 下篇补远程内部。

# 11、小结

```text
三问三答：先建证据链再排障；低基数进指标高基数进链路；选错会在错误方向优化
```

第一问：是继续加日志重新发布，还是先建立统一证据链？答案是先建证据链，因为日志无异常时，缺的是关联而非更多日志。

第二问：低基数和高基数标签怎么分？答案是低基数进 Prometheus，高基数进链路系统，通过 traceId 关联。

第三问：选错会怎样？选错会在错误方向优化半天，比如先优化 SQL，最后发现慢在远程调用。

当前状态：Petclinic 已具备从 HTTP 到 SQL、Redis、远程 HTTP 的完整 Observation 证据链。

> 先建线再排障，
> 低高基数分开走。
> 选错方向优化半天，
> 不如先看证据链。

# 12、作业

```text
理解 → 实战 → 排障 → 架构判断
```

## 理解题：为什么高基数标签不能进 Prometheus 指标？

高基数标签会让时间序列数量随标签值数量线性增长，比如 ownerId 有 10 万个用户，每个接口指标都会乘以 10 万，Prometheus 内存和查询性能会崩溃。

## 实战题：给 Petclinic 的 Owner 查询补上 Redis 缓存的 Observation，并验证指标输出。

在 OwnerService 中给 Redis 查询创建 Observation，设置低基数标签 cache=redis，启动后用 curl 访问 /owners/1，再访问 /actuator/pr

ometheus 验证 owner_find_redis_seconds 指标存在。

## 排障题：HTTP P99 涨到 3 秒，但 SQL 和 Redis 指标都正常，下一步查什么？

下一步查远程 HTTP 调用的 Observation 指标，如果远程调用耗时接近 3 秒，根因在第三方服务；

如果远程调用也正常，再查 Tomcat 线程和 Hikari 连接池的 LongTaskTimer 是否堆积。

## 架构判断题：是否应该给每个 Service 方法都加 Observation？

不应该。Observation 应该加在关键路径和远程依赖上，给每个方法都加会导致代码噪音大、指标过多、维护成本高；应该先梳理调用链，只给边界和远程调用埋点。

> 理解高基数，
> 实战补缓存。
> 排障看远程，
> 架构不滥埋。

# 13、升华

```text
工程结论：统一诊断体系的价值不在采集，而在关联；证据链闭合才能把 MTTR 从小时级降到分钟级
```

Petclinic 的 P99 三秒故障证明：日志、指标、链路三套独立时，排障靠猜；用 Observation 统一上下文后，排障靠证据。

有依据的结论是：远程依赖的观测成本必须计入功能开发成本，新增远程调用时同步埋点，否则证据链断裂。

下一篇将把远程保险服务内部也纳入观测，通过 OpenTelemetry Collector 接收对方导出的 span，让证据链延伸到第三方系统内部。

> 三秒故障一根线，
> 证据链上走一遍。
> 远程依赖要埋点，
> 下篇延伸到对面。

**系列项目：** Spring 官方 Petclinic 演进为生产级 Spring Boot 4 Java 应用

**已完成：** 环境搭建、启动机制、依赖与自动配置、配置体系、Web/安全/数据/事务、远程调用/数据库迁移/缓存/并发、日志/测试/Testcontainers/Docker Compose、Actuator/可观测基础

**本篇：** Micrometer Observation 统一诊断体系，覆盖 HTTP、SQL、Redis、远程 HTTP、Hikari 的证据链

**下一篇：** OpenTelemetry Collector 接入与远程服务内部观测延伸

Petclinic 已经接入了 Actuator、Prometheus 抓取、基础 JVM 指标，但每次线上变慢，团队还是先打开日志翻 stack trace，再切到 Grafana 看 CPU，最后

《SpringBoot4进阶实战》第21招 可观测要串成证据链

用 Micrometer Observation 打通日志、指标、链路，围绕 Owner 查询与保险报价建立完整证据链，定位 P99 从 100ms 涨到 3s

架构师

编程语言

后端

开发工具

Petclinic统一诊断体系实战：通过Micrometer Observation打通日志、指标、链路三套体系，构建从HTTP到SQL、Redis、远程调用的完整证据链。解决P99从100ms涨至3s的故障定位难题，低基数标签进Prometheus、高基数标签进链路系统，5分钟内定位慢点，MTTR从小时级降至分钟级，附代码示例与排查诊断树。

数据库连接池

代码解释

数据库

Redis

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Petclinic统一诊断体系实战：通过Micrometer Observation打通日志、指标、链路三套体系，构建从HTTP到SQL、Redis、远程调用的完整证据链。解决P99从100ms涨至3s的故障定位难题，低基数标签进Prometheus、高基数标签进链路系统，5分钟内定位慢点，MTTR从小时级降至分钟级，...

《SpringBoot4进阶实战》第21招 可观测要串成证据链-腾讯云开发者社区-腾讯云

《SpringBoot4进阶实战》第21招可观测要串成证据链

《SpringBoot4进阶实战》第21招可观测要串成证据链

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第21招 可观测要串成证据链

《SpringBoot4进阶实战》第21招 可观测要串成证据链

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第21招可观测要串成证据链

《SpringBoot4进阶实战》第21招可观测要串成证据链