夜雨聆风
AI 接口上线以后，最怕的不是模型偶尔答得一般。
更麻烦的是：出问题时看不清。
用户说慢，你不知道慢在模型、网络，还是 RAG 检索。
费用突然涨了，你不知道 token 花在系统提示词、历史对话，还是模型输出。
线上偶发失败，你只能翻日志猜。
普通业务接口慢了，我们会看接口耗时、错误率、数据库查询、外部接口耗时。
AI 接口也一样，只是链路里多了几层：
Controller
→ ChatClient
→ Advisor
→ ChatModel
→ 模型服务
Spring AI 2.0.0 的 Observability，就是把这些环节接进 Spring Boot 的观测体系。
这次用 Spring AI 2.0.0 接入 DeepSeek，做一个最小实战：调用一次 AI 接口，然后看清它慢在哪、贵在哪。
一、先把几个概念放到一张图里
Observability 一般翻译成可观测性。
它不是“多打几行日志”，而是让应用在运行时留下可查询的证据：
这次调用用了多久？
模型调用成功还是失败？
输入 token 和输出 token 分别多少？
耗时主要卡在哪一层？
这套证据通常会经过这样一条链路：
Spring AI 产生观测数据
→ Micrometer 负责收集和统一指标格式
→ Actuator 暴露应用运行端点
→ Prometheus 拉取原始指标
→ Grafana / APM 平台做看板、告警和排障
几个名词不用混在一起记。
Micrometer 是指标采集层。
它自己不是监控平台，也不负责画图。它更像 Spring Boot 里的统一指标接口，负责把耗时、次数、token 用量这些数据收集起来，再交给不同的监控系统。
Actuator 是 Spring Boot 暴露运行状态的入口。
健康检查、应用信息、指标列表、Prometheus 原始指标，都是通过 Actuator 端点暴露出来的。
Prometheus 是指标系统。
它会定时访问应用的 /actuator/prometheus，把原始指标拉走并存起来。
Grafana 是看板工具。
它通常从 Prometheus 这类系统里取数据，再画成曲线、表格和告警面板。
APM 平台可以理解成更完整的应用观测平台。
比如 SkyWalking、Datadog、New Relic 这类工具，通常会把指标、链路追踪、日志放在一起看。
本文这个最小实战没有搭 Prometheus 和 Grafana。
代码里加了一个本地页面 observability.html，把关键指标整理成人能直接看懂的样子。真实线上一般不会用这个页面，而是把 Micrometer 指标接到 Prometheus、Grafana 或公司已有的 APM 平台。
二、跑一个真实的 DeepSeek 调用
这个例子模拟一个企业差旅报销助手。
用户问：
上海住宿费 720 元，有发票和行程单，可以直接报销吗？
接口会真实请求 DeepSeek。
调用完成后，Spring AI 会记录 ChatClient、Advisor、ChatModel 和 token usage 相关指标。
这几个词可以按一次调用链路理解：
ChatClient：应用侧发起 AI 调用的入口
Advisor：调用前后的处理链路，比如记忆、RAG、工具调用等
ChatModel：真正和模型服务交互的那一层
token usage：本次调用消耗了多少输入 token 和输出 token
这里不用展开 token 的细节。
排查成本时，先看两件事：
input token 越多，请求上下文越重。
output token 越多，模型生成越长。
启动前先准备 DeepSeek Key：
export DEEPSEEK_API_KEY=你的 DeepSeek API Key
这个实战固定使用 deepseek-v4-flash。
模型先不做成动态配置，后面看指标时更容易对上。
依赖保留最小几项：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-model-deepseek</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-autoconfigure-model-chat-observation</artifactId>
</dependency>
application.yaml 里配置 DeepSeek、Actuator 和示例提示词：
spring:
application:
name: spring-ai-observability-demo
ai:
model:
chat: deepseek
deepseek:
api-key: ${DEEPSEEK_API_KEY}
chat:
model: deepseek-v4-flash
management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus
observations:
key-values:
application: spring-ai-observability-demo
demo:
travel-assistant:
system-prompt: |
你是企业差旅报销助手。
回答时只根据题目里给出的差旅信息做判断。
如果材料或审批条件不足，要明确说明还缺什么。
回答控制在 120 字以内，先给结论，再给原因。
配置好 DeepSeek 以后，把自动装配出来的 ChatModel 交给 ChatClient：
@Configuration
public class AiClientConfig {
@Bean
ChatClient chatClient(ChatModel chatModel, ObservationRegistry observationRegistry) {
return ChatClient.create(chatModel, observationRegistry);
}
}
这里传入了 ObservationRegistry。
它可以理解成观测数据的登记处。ChatClient 调用过程中产生的耗时、标签、状态，会通过它进入 Micrometer。
Controller 只做一件事：接收问题，调用模型，返回结果。
@RestController
public class TravelAssistantController {
private final ChatClient chatClient;
private final String systemPrompt;
public TravelAssistantController(ChatClient chatClient,
@Value("${demo.travel-assistant.system-prompt}") String systemPrompt) {
this.chatClient = chatClient;
this.systemPrompt = systemPrompt;
}
@GetMapping("/travel/ask")
public TravelAnswer ask(@RequestParam(defaultValue = "上海住宿费 720 元，有发票和行程单，可以直接报销吗？") String question) {
long startedAt = System.nanoTime();
String answer = this.chatClient.prompt()
.system(this.systemPrompt)
.user(question)
.call()
.content();
long elapsedMillis = (System.nanoTime() - startedAt) / 1_000_000;
return new TravelAnswer(question, answer, elapsedMillis);
}
public record TravelAnswer(String question, String answer, long elapsedMillis) {
}
}
启动项目：
./mvnw spring-boot:run
调用接口：
curl -sG "http://localhost:8080/travel/ask" \
--data-urlencode "question=上海住宿费720元，有发票和行程单，可以直接报销吗？"
会看到类似结果：
{
"question": "上海住宿费720元，有发票和行程单，可以直接报销吗？",
"answer": "结论：不能直接报销。住宿费 720 元是否超标，需要先确认公司差旅标准；目前还缺少差旅标准或审批信息。",
"elapsedMillis": 1820
}
模型输出和耗时会受网络、模型状态、提示词影响，不需要和这里完全一致。
中文参数建议用 curl -G --data-urlencode，避免直接把中文拼到 URL query 里导致请求解析异常。
调用完成后，浏览器打开：
http://localhost:8080/observability.html
调用后页面大概是这样：
这个页面只展示四类核心信息：
ChatClient 总耗时
Advisor 链路
ChatModel 耗时
token 使用量
先看这一页，就能知道这次调用大概慢在哪、token 花了多少。
如果要看 Prometheus 的原始指标文本，可以打开：
http://localhost:8080/actuator/prometheus
这个页面字段会比较多，适合排查指标名、标签和值，也适合后面接 Prometheus / Grafana。
三、慢在哪，看 ChatClient 和 ChatModel
先记住一个前提：
ChatClient 是外层总耗时。
Advisor 是中间处理链路。
ChatModel 是里面真正请求模型的耗时。
它们不是三段相加。
所以页面里如果看到 ChatClient、Advisor、ChatModel 的耗时很接近，不是异常。
这通常说明：这次调用的大头在模型请求本身，外层处理只占很小一部分。
先看 ChatClient：
spring_ai_chat_client_seconds_count{...,spring_ai_chat_client_stream="false",...} 1
spring_ai_chat_client_seconds_sum{...,spring_ai_chat_client_stream="false",...} 1.742319
spring_ai_chat_client_seconds_max{...,spring_ai_chat_client_stream="false",...} 1.742319
这种原始指标行看起来很长，但拆开以后并不复杂：
spring_ai_chat_client_seconds：指标名，表示 ChatClient 耗时
大括号里的内容：标签，比如是否流式调用、应用名、模型名等
count：调用次数
sum：累计耗时
max：最大耗时
ChatClient 代表一次 AI 调用的应用侧整体链路。
它不只是模型本身，还可能包含 Advisor、Memory、RAG、Tool Calling 等前后处理。
再看 ChatModel：
gen_ai_client_operation_seconds_count{...,gen_ai_response_model="deepseek-v4-flash",gen_ai_system="deepseek"} 1
gen_ai_client_operation_seconds_sum{...,gen_ai_response_model="deepseek-v4-flash",gen_ai_system="deepseek"} 1.602145
gen_ai_client_operation_seconds_max{...,gen_ai_response_model="deepseek-v4-flash",gen_ai_system="deepseek"} 1.602145
ChatModel 更接近模型服务调用本身。
排查时可以先做一个粗判断：
ChatClient 高，ChatModel 也高：优先看模型响应、网络、输出长度、并发排队。
ChatClient 高，ChatModel 不高：优先看 Advisor、RAG、工具调用或业务代码。
这比一句“模型慢”有用。
因为真实项目里，慢的不一定是模型。
可能是 RAG 检索取了太多文档，也可能是工具调用背后的业务接口慢，还可能是 Advisor 拼了太重的上下文。
四、贵在哪，看 token usage
AI 成本很多时候不是按接口次数算，而是按 token 算。
同样是一次调用，100 个 token 和 10,000 个 token，成本、延迟、上下文压力都不一样。
这时看：
gen_ai_client_token_usage_total
它会按 token 类型拆开：
gen_ai_client_token_usage_total{...,gen_ai_token_type="input"} 86.0
gen_ai_client_token_usage_total{...,gen_ai_token_type="output"} 49.0
gen_ai_client_token_usage_total{...,gen_ai_token_type="total"} 135.0
三类含义很直观：
input：送进模型的 token
output：模型生成的 token
total：本次调用总 token
如果 input 很高，通常要回头看上下文：
系统提示词是不是越写越长？
历史对话有没有截断？
RAG 一次是不是塞了太多文档？
Tool 描述和参数 schema 是不是太复杂？
如果 output 很高，再看回答长度：
有没有限制输出格式？
有没有让模型先给结论？
有没有把简单问题答成长报告？
所以成本优化不要只盯着“模型贵不贵”。
先看 token 花在输入，还是输出。
两个方向完全不同。
五、Advisor 指标别误读
Prometheus 里还能看到 Advisor 指标：
spring_ai_advisor_seconds_count{...,spring_ai_advisor_name="Tool Calling Advisor",...} 1
spring_ai_advisor_seconds_count{...,spring_ai_advisor_name="call",...} 1
这里容易误读。
看到 Tool Calling Advisor，不等于外部工具已经执行。
这个实战没有配置任何 Tool，也没有调用业务方法。
它说明的是：这次 ChatClient 调用经过了 Spring AI 的 Advisor 链路。
工具到底有没有真的执行，要看三件事：
ChatClient 有没有配置 tools
工具方法有没有执行日志
业务侧有没有返回结果或状态记录
Advisor 指标说明请求经过了某层处理。
工具执行记录，才说明工具真的被调用。
这个区别在排查问题时很重要。
否则看到 Advisor 指标，就很容易误以为工具已经工作了。
六、线上还要补哪些观测
这个实战只看四类最基础的指标：
ChatClient 耗时
Advisor 耗时
ChatModel 耗时
token 使用量
如果是 RAG 项目，还要继续看 VectorStore：
检索耗时
返回文档数量
topK 是否过大
similarity threshold 是否太低
metadata filter 是否命中
如果是 Tool Calling 项目，还要看工具调用：
工具有没有被调用
调用的是不是预期工具
工具耗时是多少
工具成功还是失败
失败时是什么错误类型
还有一个容易忽略的点：内容日志不要默认全开。
Spring AI 可以记录 prompt、completion、vector query response、tool content 这类内容。
排查问题时它们很有用，但生产环境要谨慎。
Prompt 里可能有用户问题、历史对话、业务规则。
Tool 参数里可能有订单号、手机号、员工 id。
VectorStore 返回结果里可能有内部文档片段。
更稳的方式，是先记录安全摘要：
tool=check_expense_policy
success=true
cost=60ms
traceId=...
businessType=travel_expense
这样既能定位问题，也不会把敏感内容直接打进日志。
写在最后
AI 接口不是只看“最后回答对不对”。
上线以后，还要能回答这些问题：
慢在哪？
贵在哪？
哪一层失败了？
token 是怎么花掉的？
Spring AI 2.0.0 的 Observability，把这些问题拆到了具体环节：
ChatClient
Advisor
ChatModel
token usage
VectorStore
Tool Calling
看得见，才谈得上排查。
能拆开，才谈得上优化。
我是 Dilee，11 年 Java 老兵，专注 AI 落地应用。
完整示例代码已整理好，后台回复「Spring AI」可以查看对应示例。
如果这篇对你有帮助，可以点个赞、收藏一下，也欢迎关注这个系列。
