这几个月跟几个Java团队聊AI项目落地发现一个特别普遍的现象模型接口调通了Demo也能跑但一上线就抓瞎。用户说“回答变笨了”技术说“我看监控一切正常”。问题出在哪出在绝大多数Java团队还在用传统CRUD那套监控逻辑看AI项目。QPS、RT、错误率这些指标能告诉你服务活着没死但根本回答不了“模型答得对不对”“钱花得值不值”“用户到底用没用”。传统Java监控和AI项目监控之间差的不是几个指标而是一整套埋点设计思路。今天这篇我想结合自己做AI项目监控的实操经验把一套适合Java团队的埋点监控方案完整拆开讲清楚核心是5类指标加4条告警。这套方案不绑定具体厂商不管你是接OpenAI、通义、智谱还是自建模型服务都能直接套用。1. 为什么AI项目的监控不能照搬传统Java监控1.1 传统监控的惯性思维放到AI场景会翻车传统Java后端监控核心就那几个指标QPS、平均响应时间、错误率、GC停顿、线程池活跃度、数据库连接池占用。这套东西在订单、支付、会员这类业务系统里非常成熟因为请求是幂等的或者状态机可预测的成功就是成功失败就是失败网络分层也清楚。但在AI项目里请求成功不代表业务成功。你调一次大模型接口HTTP 200返回了但模型可能给你一段空字符串可能给你一段“我无法回答这个问题”可能给你一本正经的胡扯。业务层看来它成功了用户看来它就是废的。如果监控只看状态码等于完全瞎了一只眼。再说性能。AI接口的耗时结构与传统接口完全不同。传统接口耗时大部分花在数据库、缓存、远程调用上峰值和线程池相关。AI接口里提示词拼装、向量检索、模型推理、结果解析每一段都可能卡住几百毫秒到几十秒。一个接口可能拆成好几个阶段每一阶段都是独立的延迟瓶颈不拆开看根本定位不了问题。还有资源消耗。Java进程内部调用AI能力时通常要持有HTTP连接池等待外部模型服务返回。这个等待不是普通IO等待它有可能把Tomcat线程池拖垮因为每个线程都卡在外部推理上几百毫秒。传统监控里的“线程数”和“等待队列”阈值在AI场景下需要重新设置。1.2 AI项目要盯的不是“服务健康”而是“模型有效性”说到底AI项目监控的核心对象变了。传统系统监控的对象是服务进程和依赖组件AI项目监控的对象是“模型行为”和“业务价值”。举个例子。某客服系统接了大模型自动回复技术团队盯着接口成功率发现一直是99.9%。但从运营视角看用户点“转人工”的比例从30%涨到了60%。这个信号说明模型生成的内容用户根本不接受。这种变化只有在业务漏斗指标和消息质量层面才能看到传统技术监控完全无感。另外模型是外部依赖它不受你控制。你的服务代码没变但模型服务方悄悄更新了版本、调整了温度参数、换了向量模型你的业务可能一夜之间就变了。传统监控假设依赖方是稳定的只在故障时异常AI监控假设模型行为是动态漂移的需要持续跟踪效果指标。所以我在给Java团队设计监控方案时把指标拆成五层基础设施层、接口调用层、资源成本层、模型质量层、业务效果层。前两层用传统方式就够后三层必须针对AI项目单独设计。下面逐个讲清楚。2. 五类核心指标缺一个都会出幺蛾子2.1 第一类基础服务指标——QPS、RT、错误率这部分说白了就是大家最熟悉的“三件套”但放到AI项目里要注意三个变化。第一个是响应时间要重视P95甚至P50不能只盯P99。为什么因为AI请求的延迟分布非常陡峭极少数超长请求会污染P99让你误以为系统整体很慢。我一般会同时记录P50、P95、P99以及最大耗时。P50才是大多数用户的真实体验P95用来判断是否出现模型推理降速P99用来发现个别的超时重试风暴。第二个是错误码要细拆。HTTP层错误、连接超时、读超时、模型返回业务错误码、JSON解析异常、内容安全拦截这些要分开统计。直接把所有非200都算成error会让告警失去意义。内容安全拦截这种其实是“正常业务保护”不应该和系统错误的告警级别一样不然一晚上告警能把人炸醒十次。第三个是HTTP客户端连接池指标。很多AI请求是通过HTTP去调外部模型网关连接池配置不当会出现“明明机器资源很闲但请求大量排队等待连接”的假故障。我建议把连接池活跃连接数、等待获取连接数、连接池耗尽次数都打点上报。再补充一个Java特有的点AI调用的线程池要单独隔离。不要和普通业务线程混在一起。很多团队吃过这个亏AI接口一慢把整个Tomcat线程池占满普通接口也全挂了。监控上要能体现这个线程池的活跃度、阻塞任务数、拒绝次数。如果拒绝次数持续大于0说明你的并发配置或超时策略有问题。2.2 第二类Token与成本指标——AI项目的“钱袋子”这部分传统Java监控没有但它几乎是我接手过的每个AI项目老板第一个问的这功能到底花了多少钱。核心指标包括每次请求的Prompt Token数、Completion Token数、总Token数。按模型名称维度聚合比如GPT-4o、Claude、国内的智谱、通义等各自花多少。然后估算成本Token数乘以单价再按照缓存命中等规则打折最后按天、按周汇总。别小看Token指标的威力。有一次我排查一个AI功能的费用翻倍问题最后发现是某个同事把历史对话全文一股脑拼进了Prompt导致Prompt Token数从2000涨到8000。这种问题从外部接口日志里根本看不出来但Token曲线一拉出来立刻暴露。另外一个容易被忽略的是“缓存命中率”。不少模型网关支持Prompt缓存命中之后价格大幅降低甚至接近免费。我建议把缓存命中数、未命中数、节省金额都记录下来。如果命中率突然下降八成是代码里给Prompt加了动态参数比如时间戳或者随机串导致缓存全部失效。这个坑我踩过好几次每次查都得把生成Prompt的代码翻一遍。成本指标还有一个用途就是做“用户级成本分摊”。给请求打上userId、业务线、功能模块维度月底可以算清楚每个业务线AI成本是多少。这在企业内部跨部门结算时特别重要不记录的话财务只能拍脑袋分账。2.3 第三类模型质量指标——从技术指标里看“模型有没有变傻”模型质量指标是AI项目监控和传统监控最大的区别。它看的不是“请求成功”而是“生成结果靠谱吗”。我设计的时候会拆成这么几个层面语义相似度把用户问题向量和模型回答向量做余弦相似度低于阈值的说明可能答非所问。置信度如果模型返回带概率分数记录下来。置信度低于阈值的要重点观察。空回复率模型可能返回空字符串、只有标点或者只回了几个空格这些要单独计数。拒答率模型返回“我不能回答”“我无法处理”这类固定话术这算业务层失败要单独统计。格式合规率如果要求模型返回JSON但模型返回了Markdown包裹的JSON或者JSON解析失败这都属于格式异常。内容安全拦截率有些输入会被安全策略拦截要记录拦截原因分类方便回溯是误杀还是真有问题。很多Java团队觉得这些指标要等算法工程师来做。其实不用你自己可以在Java服务层做简单计算。比如把模型返回的文本和输入的文本都调一下embedding接口算个相似度。虽然多花一点点钱和耗时但对线上质量监控很有价值。如果不想引入额外计算也可以先做规则层面的指标空回复、拒答关键词匹配、JSON解析失败、长度异常。这些成本几乎为零却已经能抓住一大半问题。模型是外部依赖你无法保证它稳定。质量指标就是给模型装上“行为雷达”一旦发现它开始乱说话立刻触发告警而不是等用户投诉到客服那里再查日志。2.4 第四类上下文与状态指标——让AI不“失忆”AI项目最常见的一个产品投诉是“机器人记不住我说的话”。这背后往往是上下文管理出了问题。要监控的指标包括当前会话消息数、会话总Token大小、上下文窗口占用率、历史摘要触发次数。当消息数和Token数接近模型上下文窗口上限时要么会自动截断要么会触发摘要压缩。截断会导致模型失忆摘要压缩会引入信息丢失。这些都在默默影响用户体验但传统日志不会记录。我们开发的时候会在Java侧记录会话的messages数组大小、字符数、Token估算值。每一次把新消息追加到上下文前做一个预估Token如果超阈值则触发策略丢弃最早的消息、做摘要、或者拒绝新消息。把触发了哪种策略记录下来后续分析用户体验问题时有据可查。另外还要记录知识库检索结果中的命中文档数和相关分数。有时候用户问一个问题检索召回的是完全无关的文档模型基于这个文档回答自然就是答非所问。这个环节出问题你不看检索质量指标光看模型监控也找不到根因。2.5 第五类业务效果指标——技术监控的终点是业务价值监控做到底还是要回答一个问题这个AI功能到底有没有帮到用户、帮到业务。常见的业务指标有功能使用率、人均调用次数、AI回答采纳率、用户转人工率、任务完成率、用户满意度评分。这些指标很多来自埋点日志而非系统监控但作为Java技术负责人你要主动推动把AI调用日志和业务事件打通。我见过一个失败案例。团队做了一个AI报表生成功能技术指标非常漂亮调用量高、成功率99%、Token消耗稳定。但业务方说“没人用”最后一查发现大量调用来自测试账号和一两个内部同事。真正的真实用户使用率不到3%。如果只盯系统指标整个团队都会误以为项目很成功。所以一定要把调用日志打上userId、租户ID、来源页面、业务类型这样业务效果指标才能聚合出来。这五类指标前两类用于发现“服务挂了没”中间两类用于发现“模型傻了没”最后一类用于发现“业务黄了没”。三层视角缺一不可。Java工程师从“只会做接口监控”升级到“能做业务全链路监控”在AI项目里的价值会大很多。3. Java侧落地埋点方式与一条完整链路3.1 打点方式注解AOP、手动埋点还是中间件拦截我有三种常用的埋点方式各有利弊。注解AOP定义一个AiTrace注解在Controller或Service方法上标注然后通过Spring AOP环绕通知统一采集。适合大多数Java团队代码侵入性低可复用。要注意的就是AOP只对Spring Bean生效别在static方法或非Spring代理类上用否则埋点静默失效。手动埋点在核心逻辑里逐段记录耗时和结果比如提示词拼接耗时、模型调用耗时、结果解析耗时、Token统计。这种方式最灵活能照顾到特殊场景但容易漏埋需要有人统一规范。拦截器/过滤器如果是通过统一的SDK Client或HTTP Client调用模型可以在底层加一个拦截器所有AI请求自动经过埋点。适合多个模块都要调用AI的场景不用每个业务方都自己埋。我的建议是组合用AOP做请求级埋点配合底层HTTP拦截器做模型调用级埋点关键算法逻辑里手动加少量统计点。不要只依赖其中一种单靠AOP拿不到Token这类内部信息单靠拦截器也看不到业务语义。埋点时顺便把traceId带进去。Java生态里用MDC放一个全局traceId日志、数据库、监控指标都带上它。排查问题的时候能从一条Trace串起整个调用过程。这个习惯传统Java项目就有AI项目里特别重要因为模型生成慢用户反馈时往往已经过去了很久没有traceId根本查不到当时的上下文快照。3.2 数据链路与存储展示从打点到告警的完整架构打完点之后数据往哪送。这里分享一套成本不高、技术门槛也不高的Java团队标配方案。第一层是打点侧无论用Micrometer还是直接手动上报统一转成Prometheus的数据格式。如果团队已经在用Spring Boot引入micrometer-registry-prometheus非常顺滑自带actuator/prometheus端点Grafana里直接配Prometheus数据源就能出面板。第二层是指标存储。中小团队我推荐Prometheus它天然适合这类持续增长的监控指标有完善的告警规则语法。如果组织里已经有ClickHouse或Elasticsearch也可以把明细日志送过去做更灵活的查询。Prometheus存聚合指标ES存明细日志两者互补别混着用。第三层是展示和告警。Grafana做面板Alertmanager做告警路由。告警接收方可以接企业微信机器人、钉钉机器人、邮件、电话等。我项目里常用企业微信机器人因为配置简单、支持Markdown团队不需要额外装App告警推送直接到群里处理起来效率很高。还有个细节除了埋点指标把模型响应的原始文本也存一份但要脱敏。存原始文本对事后分析“为什么模型答成这样”特别有用。很多Java团队嫌麻烦不存等用户投诉过来再找日志常常发现日志里只有状态码没内容完全复盘不了。建议至少把最近7天的响应原文存到ES或日志系统同时把敏感信息比如手机号、身份证号、密钥做脱敏再入库。3.3 一个可复用的Java埋点示例我直接给一个比较通用的代码骨架你们可以拿回去改。Component public class AiInvocationMonitor { private final MeterRegistry meterRegistry; public AiInvocationMonitor(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } public void recordInvocation(String model, String feature, String userId, boolean success, String errorType, long costMs, long promptTokens, long completionTokens, double similarity) { // 基础指标 meterRegistry.counter(ai.invocation.total, model, model, feature, feature, result, success ? success : fail) .increment(); if (!success) { meterRegistry.counter(ai.invocation.error, model, model, feature, feature, error_type, errorType) .increment(); } // 耗时直方图 Timer.builder(ai.invocation.duration) .tags(model, model, feature, feature) .publishPercentileHistogram() .register(meterRegistry) .record(Duration.ofMillis(costMs)); // Token指标 meterRegistry.counter(ai.invocation.tokens, model, model, type, prompt) .increment(promptTokens); meterRegistry.counter(ai.invocation.tokens, model, model, type, completion) .increment(completionTokens); // 质量指标 meterRegistry.gauge(ai.invocation.similarity, Tags.of(model, model, feature, feature), similarity); } }用的时候很简单比如在业务方法里public String chatWithAi(String userId, String question) { long start System.currentTimeMillis(); try { AiResult result modelClient.chat(...); monitor.recordInvocation(gpt-4o, customer-chat, userId, true, , System.currentTimeMillis() - start, result.getPromptTokens(), result.getCompletionTokens(), calculateSimilarity(question, result.getContent())); return result.getContent(); } catch (Exception e) { monitor.recordInvocation(gpt-4o, customer-chat, userId, false, e.getClass().getSimpleName(), System.currentTimeMillis() - start, 0, 0, 0); throw e; } }这里我用了计数器、直方图和gauge。实际项目里会再抽象一层把AOP切面加上或者做成统一SDK。不过核心思路就是每个AI调用都记录结果、耗时、Token、质量分带上上下文维度。注意TimeUnit别搞错毫秒和秒的换算在告警规则里最容易出bug。计数器递增要用MeterRegistry提供的线程安全实现别自己拿Long或者普通Map来加高并发下数据会丢。4. 四条告警规则只留真正能救命的告警规则设计这一块我踩过非常多坑。最开始的方案是“详细模板”把几十条规则全配上结果一天几百条告警群里的工程师把企业微信机器人拉黑了。后来我把规则精简到4条效果反而好得多。告警不是越多越好每条告警都应该对应一个明确且可执行的故障场景。4.1 告警一成功率断崖式下跌不要只看HTTP状态规则在过去5分钟窗口内AI调用成功率包含业务异常码如空回复、拒答、内容安全拦截低于80%且相比前1小时基线下降超过20%触发P1告警。这条规则的关键是把“业务失败”也算进成功率。传统Java监控里的错误率通常只看HTTP 5xx和超时而AI项目里大量失败是HTTP 200但内容不可用。如果你只算HTTP状态模型从“正常”变成“满嘴胡说”时告警根本不会触发。出现成功率断崖下跌常见原因是模型服务方版本回退、Prompt模板被不小心改了、知识库索引挂了、向量检索召回错误。我们的处理流程是先看错误类型分布如果是超时类查网络和模型网关如果是内容安全拦截类查是不是安全策略被调严了如果是空回复类先检查Prompt模板和生产配置是否一致这个比查代码重要得多因为很多团队改了提示词但没做配置回归测试。4.2 告警二P95延迟突刺先隔离再排查规则P95响应时间在10分钟内超过阈值比如3秒并持续两个检查周期触发P2告警。阈值根据业务场景定不要模板化。这条告警的难点在于“延迟到底该定多少”。我做AI客服类项目一般把P95定为5秒内超过10秒用户就会离开页面。但代码生成类项目用户能接受30秒以上。所以阈值要多观察两周正常数据再定别拍脑袋定太紧天天误报定太松又没用。触发延迟报警先看延迟拆分是提示词拼接慢、向量库查询慢、还是模型推理慢。有一次我们的告警反复响起最后发现是其中一个网关把单条请求的并发模型调用数调高了导致外部模型限流大量请求在排队等待时被算进P95。那个阶段CPU很低但延迟高如果没有延迟拆分判断路径会浪费好几个小时。4.3 告警三Token成本陡增当心“失控循环”规则按小时聚合的Token消耗量相比过去7天同窗口均值增长超过100%触发P2告警。同时可以在账单侧设置日预算超预算直接切到降级模型。Token成本突增的常见原因有Prompt重复累计没清空、某类用户高频刷接口、测试脚本死循环、外部错误重试导致重复计费。我遇到过一次事故一个自动化测试任务进入了死循环调用AI接口每分钟上千次一小时跑掉好几千块钱。后来我们给每个应用设置了周预算超预算模型自动降级成便宜的小模型这才把损失控住。成本告警最好按模型、业务线分开因为不同模型单价差距很大。如果只看总量一个测试环境的异常可能淹没在正常流量的噪声里根本触发不了。4.4 告警四空回复/拒答率异常模型该人工干预了规则空回复率加拒答率超过10%且持续5分钟触发P2告警。这里拒答是指模型返回“我无法回答”“作为一个AI我不能……”等固定话术。这个告警值得每个团队都配。空回复率低时排查成本高但一旦升高往往说明Prompt模板出了问题或者模型提供商对某些输入做了策略收紧。比如有个团队换了新模型版本后模型拒绝回答的比例从2%涨到15%用户投诉瞬间多了。这个变化代码完全没动只有质量指标能发现。收到这类告警后不要盲目重试或调参。先保存当前Prompt版本和模型版本然后从存储的原始响应里抽样查看拒答话术分析命中了哪类策略。如果是内容安全策略调整即使你改提示词也可能没用可能需要走供应商白名单流程或者换模型供应商。5. 实操避坑清单5.1 采集必须异步化别让监控拖垮主业务刚开始做AI埋点监控最容易犯的错就是在主链路里同步上报指标比如直接在请求里调云厂商的日志接口。AI请求本来就慢再额外加一个几十毫秒的同步上报用户体感会更差。推荐做法把所有监控数据先写到一个内存队列再开一个后台线程批量上报。如果队列堆积超过阈值直接丢弃一部分非关键指标绝不让监控阻塞主业务。Java里可以用BlockingQueue或者Disruptor实现用Micrometer时也确认一下注册表是异步的还是同步的别默认配成同步上报。监控的价值是辅助业务不是变成第二个故障源。5.2 维度别乱打基数爆炸是隐性坑埋点指标可以带维度但不能想加就加。比如把userId直接作为Prometheus标签如果日活用户十几万标签基数会爆炸Prometheus内存很快就被打爆。我见过一个项目把sessionId加成了label服务直接OOM。正确做法是聚合时使用低基数维度比如模型名、业务线、错误类型把用户ID、请求ID、sessionID写到日志Detail字段而不是指标标签。需要高基数分析时用明细日志系统查询不要用Prometheus。还遇到过一种情况是模型名不固定。如果代码里直接拿模型返回的model字段做标签供应商某次返回了一个新模型名标签基数就会增加一个。建议在进入监控体系前做一层映射把所有未知模型归到unknown或者手动白名单中防止指标基数被外部输入撑爆。5.3 一次AI接口“显示正常但用户不用”的定位过程复盘最后分享一个印象很深的排查有个AI问答功能上线一个月技术面板一切正常2万次日调用成功率99.5%P95延迟2.8秒Token成本稳定。但用户留存率连续下滑运营归因于“AI不好用”。我们当时没看系统监控先看业务漏斗。拉出userId维度的调用次数分布后发现70%的调用来自当天的前50个用户剩余用户基本只用了一次就不再点。再看模型质量指标那批只调用一次的用户里空回复率高达25%。原来新用户问的问题格式比较口语化模型经常答非所问。老用户也就是内部测试知道怎么提问所以体验好。根因不是系统挂了而是新用户引导和Prompt适配没跟上。如果只盯着常规监控这个锅会一直背在“用户没耐心”上。所以我现在做任何AI项目必加两类指标业务漏斗和质量指标。没有它们技术团队很容易在“一切正常”的假象里自我安慰直到业务数据打脸。我自己做Java多年刚接触AI项目监控时也走了不少弯路。最大的体会是监控方案不是上线前一次性配好就完事的它需要跟着模型和业务持续调整模型换版本了、提示词改了、用户量涨了指标阈值都得重新校准。刚开始宁可少配告警先花一两周看数据分布再把告警阈值调整到有业务含义的水平。另外每次上线AI功能前一定先在灰度环境用自测样例跑一遍质量指标模拟用户真实提问的分布别等线上出问题再回头补监控。毕竟AI项目最慢的不是写代码而是定位“模型行为变化”的时间。监控做得早、做得准这一块时间能省下一大半。上面这套指标和告警配置拿走就能用但千万要结合自己业务的输入分布重新调一遍别照抄。
Java团队AI项目监控实战：五大指标与四条告警规则全解析
这几个月跟几个Java团队聊AI项目落地发现一个特别普遍的现象模型接口调通了Demo也能跑但一上线就抓瞎。用户说“回答变笨了”技术说“我看监控一切正常”。问题出在哪出在绝大多数Java团队还在用传统CRUD那套监控逻辑看AI项目。QPS、RT、错误率这些指标能告诉你服务活着没死但根本回答不了“模型答得对不对”“钱花得值不值”“用户到底用没用”。传统Java监控和AI项目监控之间差的不是几个指标而是一整套埋点设计思路。今天这篇我想结合自己做AI项目监控的实操经验把一套适合Java团队的埋点监控方案完整拆开讲清楚核心是5类指标加4条告警。这套方案不绑定具体厂商不管你是接OpenAI、通义、智谱还是自建模型服务都能直接套用。1. 为什么AI项目的监控不能照搬传统Java监控1.1 传统监控的惯性思维放到AI场景会翻车传统Java后端监控核心就那几个指标QPS、平均响应时间、错误率、GC停顿、线程池活跃度、数据库连接池占用。这套东西在订单、支付、会员这类业务系统里非常成熟因为请求是幂等的或者状态机可预测的成功就是成功失败就是失败网络分层也清楚。但在AI项目里请求成功不代表业务成功。你调一次大模型接口HTTP 200返回了但模型可能给你一段空字符串可能给你一段“我无法回答这个问题”可能给你一本正经的胡扯。业务层看来它成功了用户看来它就是废的。如果监控只看状态码等于完全瞎了一只眼。再说性能。AI接口的耗时结构与传统接口完全不同。传统接口耗时大部分花在数据库、缓存、远程调用上峰值和线程池相关。AI接口里提示词拼装、向量检索、模型推理、结果解析每一段都可能卡住几百毫秒到几十秒。一个接口可能拆成好几个阶段每一阶段都是独立的延迟瓶颈不拆开看根本定位不了问题。还有资源消耗。Java进程内部调用AI能力时通常要持有HTTP连接池等待外部模型服务返回。这个等待不是普通IO等待它有可能把Tomcat线程池拖垮因为每个线程都卡在外部推理上几百毫秒。传统监控里的“线程数”和“等待队列”阈值在AI场景下需要重新设置。1.2 AI项目要盯的不是“服务健康”而是“模型有效性”说到底AI项目监控的核心对象变了。传统系统监控的对象是服务进程和依赖组件AI项目监控的对象是“模型行为”和“业务价值”。举个例子。某客服系统接了大模型自动回复技术团队盯着接口成功率发现一直是99.9%。但从运营视角看用户点“转人工”的比例从30%涨到了60%。这个信号说明模型生成的内容用户根本不接受。这种变化只有在业务漏斗指标和消息质量层面才能看到传统技术监控完全无感。另外模型是外部依赖它不受你控制。你的服务代码没变但模型服务方悄悄更新了版本、调整了温度参数、换了向量模型你的业务可能一夜之间就变了。传统监控假设依赖方是稳定的只在故障时异常AI监控假设模型行为是动态漂移的需要持续跟踪效果指标。所以我在给Java团队设计监控方案时把指标拆成五层基础设施层、接口调用层、资源成本层、模型质量层、业务效果层。前两层用传统方式就够后三层必须针对AI项目单独设计。下面逐个讲清楚。2. 五类核心指标缺一个都会出幺蛾子2.1 第一类基础服务指标——QPS、RT、错误率这部分说白了就是大家最熟悉的“三件套”但放到AI项目里要注意三个变化。第一个是响应时间要重视P95甚至P50不能只盯P99。为什么因为AI请求的延迟分布非常陡峭极少数超长请求会污染P99让你误以为系统整体很慢。我一般会同时记录P50、P95、P99以及最大耗时。P50才是大多数用户的真实体验P95用来判断是否出现模型推理降速P99用来发现个别的超时重试风暴。第二个是错误码要细拆。HTTP层错误、连接超时、读超时、模型返回业务错误码、JSON解析异常、内容安全拦截这些要分开统计。直接把所有非200都算成error会让告警失去意义。内容安全拦截这种其实是“正常业务保护”不应该和系统错误的告警级别一样不然一晚上告警能把人炸醒十次。第三个是HTTP客户端连接池指标。很多AI请求是通过HTTP去调外部模型网关连接池配置不当会出现“明明机器资源很闲但请求大量排队等待连接”的假故障。我建议把连接池活跃连接数、等待获取连接数、连接池耗尽次数都打点上报。再补充一个Java特有的点AI调用的线程池要单独隔离。不要和普通业务线程混在一起。很多团队吃过这个亏AI接口一慢把整个Tomcat线程池占满普通接口也全挂了。监控上要能体现这个线程池的活跃度、阻塞任务数、拒绝次数。如果拒绝次数持续大于0说明你的并发配置或超时策略有问题。2.2 第二类Token与成本指标——AI项目的“钱袋子”这部分传统Java监控没有但它几乎是我接手过的每个AI项目老板第一个问的这功能到底花了多少钱。核心指标包括每次请求的Prompt Token数、Completion Token数、总Token数。按模型名称维度聚合比如GPT-4o、Claude、国内的智谱、通义等各自花多少。然后估算成本Token数乘以单价再按照缓存命中等规则打折最后按天、按周汇总。别小看Token指标的威力。有一次我排查一个AI功能的费用翻倍问题最后发现是某个同事把历史对话全文一股脑拼进了Prompt导致Prompt Token数从2000涨到8000。这种问题从外部接口日志里根本看不出来但Token曲线一拉出来立刻暴露。另外一个容易被忽略的是“缓存命中率”。不少模型网关支持Prompt缓存命中之后价格大幅降低甚至接近免费。我建议把缓存命中数、未命中数、节省金额都记录下来。如果命中率突然下降八成是代码里给Prompt加了动态参数比如时间戳或者随机串导致缓存全部失效。这个坑我踩过好几次每次查都得把生成Prompt的代码翻一遍。成本指标还有一个用途就是做“用户级成本分摊”。给请求打上userId、业务线、功能模块维度月底可以算清楚每个业务线AI成本是多少。这在企业内部跨部门结算时特别重要不记录的话财务只能拍脑袋分账。2.3 第三类模型质量指标——从技术指标里看“模型有没有变傻”模型质量指标是AI项目监控和传统监控最大的区别。它看的不是“请求成功”而是“生成结果靠谱吗”。我设计的时候会拆成这么几个层面语义相似度把用户问题向量和模型回答向量做余弦相似度低于阈值的说明可能答非所问。置信度如果模型返回带概率分数记录下来。置信度低于阈值的要重点观察。空回复率模型可能返回空字符串、只有标点或者只回了几个空格这些要单独计数。拒答率模型返回“我不能回答”“我无法处理”这类固定话术这算业务层失败要单独统计。格式合规率如果要求模型返回JSON但模型返回了Markdown包裹的JSON或者JSON解析失败这都属于格式异常。内容安全拦截率有些输入会被安全策略拦截要记录拦截原因分类方便回溯是误杀还是真有问题。很多Java团队觉得这些指标要等算法工程师来做。其实不用你自己可以在Java服务层做简单计算。比如把模型返回的文本和输入的文本都调一下embedding接口算个相似度。虽然多花一点点钱和耗时但对线上质量监控很有价值。如果不想引入额外计算也可以先做规则层面的指标空回复、拒答关键词匹配、JSON解析失败、长度异常。这些成本几乎为零却已经能抓住一大半问题。模型是外部依赖你无法保证它稳定。质量指标就是给模型装上“行为雷达”一旦发现它开始乱说话立刻触发告警而不是等用户投诉到客服那里再查日志。2.4 第四类上下文与状态指标——让AI不“失忆”AI项目最常见的一个产品投诉是“机器人记不住我说的话”。这背后往往是上下文管理出了问题。要监控的指标包括当前会话消息数、会话总Token大小、上下文窗口占用率、历史摘要触发次数。当消息数和Token数接近模型上下文窗口上限时要么会自动截断要么会触发摘要压缩。截断会导致模型失忆摘要压缩会引入信息丢失。这些都在默默影响用户体验但传统日志不会记录。我们开发的时候会在Java侧记录会话的messages数组大小、字符数、Token估算值。每一次把新消息追加到上下文前做一个预估Token如果超阈值则触发策略丢弃最早的消息、做摘要、或者拒绝新消息。把触发了哪种策略记录下来后续分析用户体验问题时有据可查。另外还要记录知识库检索结果中的命中文档数和相关分数。有时候用户问一个问题检索召回的是完全无关的文档模型基于这个文档回答自然就是答非所问。这个环节出问题你不看检索质量指标光看模型监控也找不到根因。2.5 第五类业务效果指标——技术监控的终点是业务价值监控做到底还是要回答一个问题这个AI功能到底有没有帮到用户、帮到业务。常见的业务指标有功能使用率、人均调用次数、AI回答采纳率、用户转人工率、任务完成率、用户满意度评分。这些指标很多来自埋点日志而非系统监控但作为Java技术负责人你要主动推动把AI调用日志和业务事件打通。我见过一个失败案例。团队做了一个AI报表生成功能技术指标非常漂亮调用量高、成功率99%、Token消耗稳定。但业务方说“没人用”最后一查发现大量调用来自测试账号和一两个内部同事。真正的真实用户使用率不到3%。如果只盯系统指标整个团队都会误以为项目很成功。所以一定要把调用日志打上userId、租户ID、来源页面、业务类型这样业务效果指标才能聚合出来。这五类指标前两类用于发现“服务挂了没”中间两类用于发现“模型傻了没”最后一类用于发现“业务黄了没”。三层视角缺一不可。Java工程师从“只会做接口监控”升级到“能做业务全链路监控”在AI项目里的价值会大很多。3. Java侧落地埋点方式与一条完整链路3.1 打点方式注解AOP、手动埋点还是中间件拦截我有三种常用的埋点方式各有利弊。注解AOP定义一个AiTrace注解在Controller或Service方法上标注然后通过Spring AOP环绕通知统一采集。适合大多数Java团队代码侵入性低可复用。要注意的就是AOP只对Spring Bean生效别在static方法或非Spring代理类上用否则埋点静默失效。手动埋点在核心逻辑里逐段记录耗时和结果比如提示词拼接耗时、模型调用耗时、结果解析耗时、Token统计。这种方式最灵活能照顾到特殊场景但容易漏埋需要有人统一规范。拦截器/过滤器如果是通过统一的SDK Client或HTTP Client调用模型可以在底层加一个拦截器所有AI请求自动经过埋点。适合多个模块都要调用AI的场景不用每个业务方都自己埋。我的建议是组合用AOP做请求级埋点配合底层HTTP拦截器做模型调用级埋点关键算法逻辑里手动加少量统计点。不要只依赖其中一种单靠AOP拿不到Token这类内部信息单靠拦截器也看不到业务语义。埋点时顺便把traceId带进去。Java生态里用MDC放一个全局traceId日志、数据库、监控指标都带上它。排查问题的时候能从一条Trace串起整个调用过程。这个习惯传统Java项目就有AI项目里特别重要因为模型生成慢用户反馈时往往已经过去了很久没有traceId根本查不到当时的上下文快照。3.2 数据链路与存储展示从打点到告警的完整架构打完点之后数据往哪送。这里分享一套成本不高、技术门槛也不高的Java团队标配方案。第一层是打点侧无论用Micrometer还是直接手动上报统一转成Prometheus的数据格式。如果团队已经在用Spring Boot引入micrometer-registry-prometheus非常顺滑自带actuator/prometheus端点Grafana里直接配Prometheus数据源就能出面板。第二层是指标存储。中小团队我推荐Prometheus它天然适合这类持续增长的监控指标有完善的告警规则语法。如果组织里已经有ClickHouse或Elasticsearch也可以把明细日志送过去做更灵活的查询。Prometheus存聚合指标ES存明细日志两者互补别混着用。第三层是展示和告警。Grafana做面板Alertmanager做告警路由。告警接收方可以接企业微信机器人、钉钉机器人、邮件、电话等。我项目里常用企业微信机器人因为配置简单、支持Markdown团队不需要额外装App告警推送直接到群里处理起来效率很高。还有个细节除了埋点指标把模型响应的原始文本也存一份但要脱敏。存原始文本对事后分析“为什么模型答成这样”特别有用。很多Java团队嫌麻烦不存等用户投诉过来再找日志常常发现日志里只有状态码没内容完全复盘不了。建议至少把最近7天的响应原文存到ES或日志系统同时把敏感信息比如手机号、身份证号、密钥做脱敏再入库。3.3 一个可复用的Java埋点示例我直接给一个比较通用的代码骨架你们可以拿回去改。Component public class AiInvocationMonitor { private final MeterRegistry meterRegistry; public AiInvocationMonitor(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } public void recordInvocation(String model, String feature, String userId, boolean success, String errorType, long costMs, long promptTokens, long completionTokens, double similarity) { // 基础指标 meterRegistry.counter(ai.invocation.total, model, model, feature, feature, result, success ? success : fail) .increment(); if (!success) { meterRegistry.counter(ai.invocation.error, model, model, feature, feature, error_type, errorType) .increment(); } // 耗时直方图 Timer.builder(ai.invocation.duration) .tags(model, model, feature, feature) .publishPercentileHistogram() .register(meterRegistry) .record(Duration.ofMillis(costMs)); // Token指标 meterRegistry.counter(ai.invocation.tokens, model, model, type, prompt) .increment(promptTokens); meterRegistry.counter(ai.invocation.tokens, model, model, type, completion) .increment(completionTokens); // 质量指标 meterRegistry.gauge(ai.invocation.similarity, Tags.of(model, model, feature, feature), similarity); } }用的时候很简单比如在业务方法里public String chatWithAi(String userId, String question) { long start System.currentTimeMillis(); try { AiResult result modelClient.chat(...); monitor.recordInvocation(gpt-4o, customer-chat, userId, true, , System.currentTimeMillis() - start, result.getPromptTokens(), result.getCompletionTokens(), calculateSimilarity(question, result.getContent())); return result.getContent(); } catch (Exception e) { monitor.recordInvocation(gpt-4o, customer-chat, userId, false, e.getClass().getSimpleName(), System.currentTimeMillis() - start, 0, 0, 0); throw e; } }这里我用了计数器、直方图和gauge。实际项目里会再抽象一层把AOP切面加上或者做成统一SDK。不过核心思路就是每个AI调用都记录结果、耗时、Token、质量分带上上下文维度。注意TimeUnit别搞错毫秒和秒的换算在告警规则里最容易出bug。计数器递增要用MeterRegistry提供的线程安全实现别自己拿Long或者普通Map来加高并发下数据会丢。4. 四条告警规则只留真正能救命的告警规则设计这一块我踩过非常多坑。最开始的方案是“详细模板”把几十条规则全配上结果一天几百条告警群里的工程师把企业微信机器人拉黑了。后来我把规则精简到4条效果反而好得多。告警不是越多越好每条告警都应该对应一个明确且可执行的故障场景。4.1 告警一成功率断崖式下跌不要只看HTTP状态规则在过去5分钟窗口内AI调用成功率包含业务异常码如空回复、拒答、内容安全拦截低于80%且相比前1小时基线下降超过20%触发P1告警。这条规则的关键是把“业务失败”也算进成功率。传统Java监控里的错误率通常只看HTTP 5xx和超时而AI项目里大量失败是HTTP 200但内容不可用。如果你只算HTTP状态模型从“正常”变成“满嘴胡说”时告警根本不会触发。出现成功率断崖下跌常见原因是模型服务方版本回退、Prompt模板被不小心改了、知识库索引挂了、向量检索召回错误。我们的处理流程是先看错误类型分布如果是超时类查网络和模型网关如果是内容安全拦截类查是不是安全策略被调严了如果是空回复类先检查Prompt模板和生产配置是否一致这个比查代码重要得多因为很多团队改了提示词但没做配置回归测试。4.2 告警二P95延迟突刺先隔离再排查规则P95响应时间在10分钟内超过阈值比如3秒并持续两个检查周期触发P2告警。阈值根据业务场景定不要模板化。这条告警的难点在于“延迟到底该定多少”。我做AI客服类项目一般把P95定为5秒内超过10秒用户就会离开页面。但代码生成类项目用户能接受30秒以上。所以阈值要多观察两周正常数据再定别拍脑袋定太紧天天误报定太松又没用。触发延迟报警先看延迟拆分是提示词拼接慢、向量库查询慢、还是模型推理慢。有一次我们的告警反复响起最后发现是其中一个网关把单条请求的并发模型调用数调高了导致外部模型限流大量请求在排队等待时被算进P95。那个阶段CPU很低但延迟高如果没有延迟拆分判断路径会浪费好几个小时。4.3 告警三Token成本陡增当心“失控循环”规则按小时聚合的Token消耗量相比过去7天同窗口均值增长超过100%触发P2告警。同时可以在账单侧设置日预算超预算直接切到降级模型。Token成本突增的常见原因有Prompt重复累计没清空、某类用户高频刷接口、测试脚本死循环、外部错误重试导致重复计费。我遇到过一次事故一个自动化测试任务进入了死循环调用AI接口每分钟上千次一小时跑掉好几千块钱。后来我们给每个应用设置了周预算超预算模型自动降级成便宜的小模型这才把损失控住。成本告警最好按模型、业务线分开因为不同模型单价差距很大。如果只看总量一个测试环境的异常可能淹没在正常流量的噪声里根本触发不了。4.4 告警四空回复/拒答率异常模型该人工干预了规则空回复率加拒答率超过10%且持续5分钟触发P2告警。这里拒答是指模型返回“我无法回答”“作为一个AI我不能……”等固定话术。这个告警值得每个团队都配。空回复率低时排查成本高但一旦升高往往说明Prompt模板出了问题或者模型提供商对某些输入做了策略收紧。比如有个团队换了新模型版本后模型拒绝回答的比例从2%涨到15%用户投诉瞬间多了。这个变化代码完全没动只有质量指标能发现。收到这类告警后不要盲目重试或调参。先保存当前Prompt版本和模型版本然后从存储的原始响应里抽样查看拒答话术分析命中了哪类策略。如果是内容安全策略调整即使你改提示词也可能没用可能需要走供应商白名单流程或者换模型供应商。5. 实操避坑清单5.1 采集必须异步化别让监控拖垮主业务刚开始做AI埋点监控最容易犯的错就是在主链路里同步上报指标比如直接在请求里调云厂商的日志接口。AI请求本来就慢再额外加一个几十毫秒的同步上报用户体感会更差。推荐做法把所有监控数据先写到一个内存队列再开一个后台线程批量上报。如果队列堆积超过阈值直接丢弃一部分非关键指标绝不让监控阻塞主业务。Java里可以用BlockingQueue或者Disruptor实现用Micrometer时也确认一下注册表是异步的还是同步的别默认配成同步上报。监控的价值是辅助业务不是变成第二个故障源。5.2 维度别乱打基数爆炸是隐性坑埋点指标可以带维度但不能想加就加。比如把userId直接作为Prometheus标签如果日活用户十几万标签基数会爆炸Prometheus内存很快就被打爆。我见过一个项目把sessionId加成了label服务直接OOM。正确做法是聚合时使用低基数维度比如模型名、业务线、错误类型把用户ID、请求ID、sessionID写到日志Detail字段而不是指标标签。需要高基数分析时用明细日志系统查询不要用Prometheus。还遇到过一种情况是模型名不固定。如果代码里直接拿模型返回的model字段做标签供应商某次返回了一个新模型名标签基数就会增加一个。建议在进入监控体系前做一层映射把所有未知模型归到unknown或者手动白名单中防止指标基数被外部输入撑爆。5.3 一次AI接口“显示正常但用户不用”的定位过程复盘最后分享一个印象很深的排查有个AI问答功能上线一个月技术面板一切正常2万次日调用成功率99.5%P95延迟2.8秒Token成本稳定。但用户留存率连续下滑运营归因于“AI不好用”。我们当时没看系统监控先看业务漏斗。拉出userId维度的调用次数分布后发现70%的调用来自当天的前50个用户剩余用户基本只用了一次就不再点。再看模型质量指标那批只调用一次的用户里空回复率高达25%。原来新用户问的问题格式比较口语化模型经常答非所问。老用户也就是内部测试知道怎么提问所以体验好。根因不是系统挂了而是新用户引导和Prompt适配没跟上。如果只盯着常规监控这个锅会一直背在“用户没耐心”上。所以我现在做任何AI项目必加两类指标业务漏斗和质量指标。没有它们技术团队很容易在“一切正常”的假象里自我安慰直到业务数据打脸。我自己做Java多年刚接触AI项目监控时也走了不少弯路。最大的体会是监控方案不是上线前一次性配好就完事的它需要跟着模型和业务持续调整模型换版本了、提示词改了、用户量涨了指标阈值都得重新校准。刚开始宁可少配告警先花一两周看数据分布再把告警阈值调整到有业务含义的水平。另外每次上线AI功能前一定先在灰度环境用自测样例跑一遍质量指标模拟用户真实提问的分布别等线上出问题再回头补监控。毕竟AI项目最慢的不是写代码而是定位“模型行为变化”的时间。监控做得早、做得准这一块时间能省下一大半。上面这套指标和告警配置拿走就能用但千万要结合自己业务的输入分布重新调一遍别照抄。