接了个人工智能客服相关的Java项目后我第一次发现日志这两个字的含义完全变了。以前写服务端接口日志就是log.info(requestId{}, userId{}, id, uid)那一行文本排查问题时 grep 一下关键词再看一眼耗时和状态码基本就能定位问题。可一旦用 LangChain4j 去调用大模型传统那套日志思路立刻不够用了用户那一轮对话到底传了什么消息给模型、模型为什么给出这样一个回答、一次调用消耗了多少 token、花了多少毫秒、是不是因为 max_tokens 被截断了——这些问题靠打印几行文本根本答不上来。这道高级 Java 面试题问的调用日志的结构化存储和分析本质上就是考察你能不能把一次大模型调用从黑盒变成白盒。这里的关键词有两个一个是结构化意味着日志不是一行给人看的中文文本而是分好字段、能进数据库、能被 SQL 聚合的数据另一个是分析意味着存下来不是目的后续还要拿去做成本核算、性能监控、效果归因。这篇文章我会从 LangChain4j 的监听器机制讲起到表结构设计再到可直接抄的查询 SQL最后是生产环境落地时我踩过的几个坑希望对正在做 AI 应用开发或者准备这道面试题的朋友都有帮助。1. 面试官抛出结构化存储和分析到底想听到什么1.1 传统接口日志和 LLM 调用日志的差异很多候选人一上来就背监听器 API、贴代码但我觉得这种答法往往拿不到高分因为面试官问的其实是你理不理解这两类日志的本质区别。传统后端接口日志关注的是请求参数、返回状态、耗时、异常堆栈日志形态通常是自由文本分析目标也很单一就是排障。而一次 LLM 调用需要记录的东西要复杂得多完整的消息列表system、user、assistant 各自的角色和内容、模型返回的文本、token 消耗明细输入、输出、总量、延迟、完成原因finish_reason、成本估算、甚至当时使用的模型版本和提示词版本。我通常用下面这个表格来对比两者面试时如果能把这个差异说清楚就已经赢了第一印象维度传统接口日志LLM 调用日志核心关注点请求路径、状态码、耗时、异常消息内容、模型输出、token、成本、截断原因日志形态自由文本grep 可排查结构化字段需要入库二次分析主要消费者开发排查问题开发者、算法工程师、业务方共同分析分析目标故障恢复成本控制、模型选型、提示词优化为什么非结构化不行因为 AI 调用有两个传统接口没有的特点。一是结果不确定性同一个提示词模型可能给出完全不同长度的回答你必须记录实际输出才能还原现场二是可计费性每次调用都直接和成本挂钩token 消耗需要被聚合、对比、预测。文本日志里塞这些东西后续做SUM(total_token) GROUP BY model这种分析时根本无从下手除非你再写一堆正则去解析那维护成本就完全失控了。1.2 能拿分的回答框架采集、存储、分析三层递进踩过几次坑之后我总结出一个比较稳的回答框架三层递进先说数据的生命周期再落到具体实现。第一层是采集层解决数据从哪来的问题对应到 LangChain4j 就是如何通过监听器拿到一次调用完整的事件数据。第二层是存储层解决数据怎么放的问题核心是表结构设计包括主表字段、明细表要不要拆、索引怎么建。第三层是分析层解决数据怎么用的问题要给出具体的场景和对应的 SQL 或指标比如成本趋势、延迟分位数、异常归因、提示词版本对比。这个框架的好处是逻辑严密、有递进感面试官追问任何一个环节你都能往下展开。文章后面我就按这个顺序来讲每一层我都会给出我在真实项目里验证过的做法。2. 数据从哪来把 LangChain4j 的监听器变成日志采集器2.1 监听器的四个触点能拿到什么LangChain4j 给模型调用留了一个非常关键的扩展点ChatModelListener接口。它对应的是ChatModel在发起请求和返回响应过程中各个阶段的事件你只要把它注册到模型构建器里就能在调用前后拿到完整的上下文对象。我把它理解为 AOP 切面只不过这个切面已经帮你定义好了四个触点请求发起前、响应返回后、出错时还有一个通用的扩展方法。在onRequest(ChatModelRequestContext context)里你可以拿到ChatModelRequest里面是本次请求的所有参数包括模型名、消息列表、温度、top_p、max_tokens 等。这块数据对应的是用户当时是怎么请求的。在onResponse(ChatModelResponseContext context)里你能拿到ChatModelResponse注意它里面的tokenUsage()字段直接给出了输入 token 数、输出 token 数和总 token 数这是做成本分析的关键依赖还有finishReason()能告诉你回答到底是正常结束还是因为长度限制被截断。在onError(ChatModelErrorContext context)里你能拿到具体异常对象和出错时的上下文。最后一个扩展方法用的场景比较少这里不重点展开。给模型构建器注册监听器的方式也很直白就是把监听器实例塞进listeners(...)参数里// 以你项目里实际接入的大模型服务商实现类为例这里用占位类名 YourModelProviderChatModel model YourModelProviderChatModel.builder() .apiKey(your-api-key) .modelName(your-model-name) .listeners(List.of(new StructuredLlmCallListener(repository))) .build();也就是说一次 LLM 调用从输入到输出再到异常所有关键数据都能通过监听器拿到。有了这些原始数据结构化的第一步就走完了。2.2 从监听事件到结构化日志实体的转换监听器拿到的是框架的事件对象不能直接丢给数据库必须转换成我们自己的日志实体。我的做法是在onRequest阶段先创建一个日志实体把请求侧的字段填进去然后暂存在上下文的共享属性里等onResponse或者onError触发时再从上下文里取出来补上响应侧和异常侧的字段最后统一异步写入。这样做的好处是无论成功还是失败最终都对应同一条日志记录不会出现成功记录和失败记录各是一套字段这种结构分裂。下面是我在实际项目里用过的简化版监听器实现public class StructuredLlmCallListener implements ChatModelListener { private final ObjectMapper objectMapper new ObjectMapper(); private final LlmCallLogRepository logRepository; public StructuredLlmCallListener(LlmCallLogRepository logRepository) { this.logRepository logRepository; } Override public void onRequest(ChatModelRequestContext context) { ChatModelRequest request context.request(); LlmCallLogEntity entity new LlmCallLogEntity(); entity.setTraceId(LogContext.getTraceId()); entity.setConversationId(LogContext.getConversationId()); entity.setRequestTime(LocalDateTime.now()); entity.setModel(request.model()); entity.setTemperature(request.temperature()); entity.setTopP(request.topP()); entity.setMaxTokens(request.maxTokens()); entity.setRequestMessagesJson(toJson(request.messages())); context.attributes().put(callLogEntity, entity); } Override public void onResponse(ChatModelResponseContext context) { LlmCallLogEntity entity (LlmCallLogEntity) context.attributes().get(callLogEntity); if (entity null) { return; } ChatModelResponse response context.response(); entity.setFinishReason(response.finishReason()); TokenUsage usage response.tokenUsage(); entity.setInputToken(usage.inputTokenCount()); entity.setOutputToken(usage.outputTokenCount()); entity.setTotalToken(usage.totalTokenCount()); entity.setDurationMs(context.duration().toMillis()); entity.setResponseTextJson(response.aiMessage().text()); entity.setStatus(0); logRepository.asyncSave(entity); } Override public void onError(ChatModelErrorContext context) { LlmCallLogEntity entity (LlmCallLogEntity) context.attributes().get(callLogEntity); if (entity null) { return; } entity.setStatus(1); entity.setErrorType(context.error().getClass().getSimpleName()); entity.setErrorMessage(context.error().getMessage()); entity.setDurationMs(context.duration().toMillis()); logRepository.asyncSave(entity); } private String toJson(Object obj) { try { return objectMapper.writeValueAsString(obj); } catch (Exception e) { return {}; } } }这里有个实现细节值得说明我选择用context.attributes()暂存实体而不是自己造一个 ThreadLocal 容器。ThreadLocal 在异步执行、线程复用的情况下非常容易出现数据串线问题框架自带的 attributes 是跟着这一次调用上下文走的生命周期清晰不容易泄漏。2.3 链路维度traceId 和 conversationId 必须贯穿单次调用的数据采集完成后还要解决怎么串起来的问题。一次用户请求可能不只调用一次大模型比如先调用模型做意图识别、再调用模型生成回答中间还穿插检索。如果每条日志都是一座孤岛分析时就没法知道这次线上故障影响了多少用户会话。我的做法是在请求入口生成traceId整个业务处理链路共用同一个值每次 LLM 调用都把它写入日志如果有对话业务再带一个conversationId用来关联同一个用户的多轮问答。有了这两个字段分析维度就能从单次调用上升到一次请求和一段会话后面做会话级成本归算、用户级异常分析时都会方便很多。监听器里那两行LogContext.getTraceId()就是从这来的。3. 存储层设计一张主表加一张明细表打天下3.1 主表字段的业务含义日志采集完之后下一步是落库。很多人第一反应是直接把 JSON 字符串存进数据库不就行了但这样会掉进假结构化的坑字段没有独立出来后续做聚合分析还是要靠字符串解析性能差且容易出错。我建议至少建一张主表把高频用于查询和分析的字段都独立成列把完整消息和响应原文作为 JSON 存档字段。下面是经过实际业务验证的主表 DDL可以作为参考CREATE TABLE ai_call_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, trace_id VARCHAR(64) NOT NULL COMMENT 链路追踪ID, conversation_id VARCHAR(64) NULL COMMENT 会话ID多轮对话关联用, request_id VARCHAR(64) NOT NULL COMMENT 模型请求ID, model_name VARCHAR(64) NOT NULL COMMENT 模型名称, temperature DOUBLE NULL COMMENT 采样温度, top_p DOUBLE NULL COMMENT 核采样参数, max_tokens INT NULL COMMENT 最大输出token数, prompt_version VARCHAR(64) NULL COMMENT 提示词版本标识, request_time DATETIME NOT NULL COMMENT 请求发起时间, duration_ms INT NOT NULL COMMENT 调用耗时毫秒, finish_reason VARCHAR(32) NULL COMMENT 完成原因stop/length/..., input_token INT NULL COMMENT 输入token数, output_token INT NULL COMMENT 输出token数, total_token INT NULL COMMENT 总token数, cost_estimate DECIMAL(12,6) NULL COMMENT 成本估算按单价换算, status TINYINT NOT NULL DEFAULT 0 COMMENT 0成功 1失败, error_type VARCHAR(64) NULL COMMENT 异常类型简写, error_message TEXT NULL COMMENT 异常消息, request_messages_json LONGTEXT NULL COMMENT 请求消息列表JSON存档, response_text_json LONGTEXT NULL COMMENT 响应文本JSON存档, created_at DATETIME NOT NULL COMMENT 写入时间, KEY idx_trace_id (trace_id), KEY idx_model_time (model_name, request_time), KEY idx_status_time (status, request_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTLLM调用日志表;逐个说下几个容易忽略的字段设计考量。status我用了TINYINT而不是字符串因为后续要按成功失败做聚合统计数值类型比字符串更快、更省空间0 和 1 的语义在代码里用常量维护就行。cost_estimate是冗余出来的成本字段入库时根据模型单价和 total_token 算好这样分析报表不用每次都去关联单价配置表。request_messages_json和response_text_json是还原现场用的存档平时不参与查询只用于审计、模型效果复盘和故障回溯。3.2 消息明细表与 JSON 字段怎么取舍主表里的请求消息是一个 JSON 数组这在多数时候够用。但如果你需要按角色做统计分析比如今天所有 user 消息的平均长度是多少、哪些请求里 system prompt 带了某个关键词那 JSON 字段就很不方便。这时候可以考虑加一张消息明细子表CREATE TABLE ai_call_message ( id BIGINT AUTO_INCREMENT PRIMARY KEY, call_log_id BIGINT NOT NULL COMMENT 关联主表ID, seq INT NOT NULL COMMENT 消息顺序, role VARCHAR(16) NOT NULL COMMENT system/user/assistant/tool, content LONGTEXT NOT NULL COMMENT 消息内容, created_at DATETIME NOT NULL, KEY idx_call_log (call_log_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENTLLM调用消息明细表;但我要提醒一句不要一上来就拆明细表。我见过不少团队在需求并不明确时就把消息拆到子表结果每条消息还要考虑seq、角色枚举、工具调用的嵌套结构存储和写入复杂度都上去了分析时还要 join 回去。比较稳妥的做法是初期主表一份 JSON 存档打天下等确实出现按角色过滤、按消息内容统计这种明确需求再迁移出明细表。先满足核心诉求再逐步演进。3.3 索引与生命周期管理索引设计要跟着查询模式走。在这张表上最常见的三类查询是按 trace_id 追一条调用链、按模型和时间范围看用量趋势、按状态和时间范围看异常分布。所以我建了三个联合索引idx_trace_id、idx_model_time (model_name, request_time)、idx_status_time (status, request_time)。注意联合索引的字段顺序不是随便写的等值条件的字段要放前面范围条件的字段放后面这样才能最大化索引利用率。还有一个必须提前想清楚的问题这张表增长极快一条调用记录带 JSON 存档的话单条可能就有 5KB 到几十 KB。按日均 10 万次调用、平均每条 5KB 来算一天就是 500MB一个月就是 15GB加上索引膨胀实际占用可能到 20GB 以上。生产环境一定要做保留策略我建议按月分区数据保留 90 天更早的归档到冷存储或直接清理。否则这张表会在几个月内变成一个查询极慢的大泥潭。4. 分析层落地四类 SQL 查询直接搬4.1 用量与成本趋势日志落在表里首先要做的分析就是钱花到哪了。下面这段 SQL 可以按天、按模型统计 token 消耗和成本是成本报表最基础的一张表SELECT DATE_FORMAT(request_time, %Y-%m-%d) AS dt, model_name, COUNT(*) AS call_count, SUM(input_token) AS input_token, SUM(output_token) AS output_token, SUM(total_token) AS total_token, ROUND(SUM(cost_estimate), 4) AS total_cost FROM ai_call_log WHERE request_time NOW() - INTERVAL 30 DAY GROUP BY dt, model_name ORDER BY dt DESC, total_cost DESC;光有这张表还不够成本异常要能定位。我的习惯是把结果和上周同期做对比比如发现某一天的 input_token 突然涨了 50%很可能是某个入口把同样的上下文重复塞进了提示词或者系统 prompt 悄悄变大。这时只要缩小时间范围按trace_id找出那几笔调用再打开request_messages_json对比一下内容问题原因基本就现形了。4.2 延迟与稳定性分析模型响应延迟直接决定用户体感但也不能只看平均值因为偶发的长尾请求会把平均值拉高掩盖真实水平。标准做法是看分位数。下面是按模型统计延迟分布情况的 SQLSELECT model_name, COUNT(*) AS call_count, ROUND(AVG(duration_ms), 2) AS avg_ms, ROUND(MAX(duration_ms), 2) AS max_ms FROM ai_call_log WHERE request_time NOW() - INTERVAL 7 DAY GROUP BY model_name ORDER BY avg_ms DESC;如果你的数据库支持窗口函数也可以用类似PERCENTILE_CONT的函数直接算 p95、p99。我遇到过一个真实案例某模型平均耗时 800ms看起来不错但 p95 到了 6 秒用户反馈经常转圈很久。靠平均值完全发现不了这个问题换成 p95 观察之后很快就定位到是某几个超大 context 请求触发了降速最终通过限制上下文长度和增加超时重试解决了问题。4.3 异常归因大模型调用不像普通接口那样出现异常就代码抛错更多的是超时、限流、语义审查拦截、内容截断。所以异常分析的第一件事是分类统计SELECT DATE_FORMAT(request_time, %Y-%m-%d) AS dt, error_type, COUNT(*) AS cnt, ROUND(SUM(status 1) * 100.0 / COUNT(*), 2) AS fail_rate FROM ai_call_log WHERE request_time NOW() - INTERVAL 3 DAY GROUP BY dt, error_type ORDER BY cnt DESC;如果某个error_type的数量突然成倍上涨优先去看那个时间段发布的模型配置、提示词版本或上游服务有没有变化。如果没有发现明显变更再捞几条失败记录的trace_id按链路去查。这套从指标下钻到单条记录的分析路径靠的就是前面表设计里独立出来的error_type、status、trace_id字段。4.4 提示词版本对比最后一个是很多团队容易忽略的分析场景提示词版本的效果对比。线上提示词不是一成不变的每次调整都可能影响回答质量、输出长度和成本。只要在写入日志时把当前提示词版本号带进prompt_version字段就能用 SQL 做版本对比SELECT prompt_version, COUNT(*) AS call_count, ROUND(AVG(duration_ms), 2) AS avg_ms, ROUND(AVG(total_token), 2) AS avg_token, SUM(CASE WHEN finish_reason length THEN 1 ELSE 0 END) AS truncated_cnt FROM ai_call_log WHERE prompt_version IS NOT NULL AND request_time NOW() - INTERVAL 14 DAY GROUP BY prompt_version ORDER BY call_count DESC;finish_reason length是一个很值得观察的信号它表示模型因为达到 max_tokens 上限而被强制截断也就是回答没写完。如果某个版本截断率明显升高说明提示词引导模型输出了更长内容或者 max_tokens 设置不合理。这种分析能力没有结构化日志是根本做不出来的。5. 生产落地时我踩过的坑5.1 同步入库把接口拖慢我第一次实现监听器时直接在回调里同步写了数据库结果接口 p99 涨了 300 毫秒。原因很好理解监听器是模型调用链路的一部分同步写库等于给原本可以并行的动作硬加了串行等待。后来我改成异步落库先用一个内存队列接收监听器传过来的日志实体再由单独的线程池批量写入数据库。这个改动让接口耗时基本归零批量写入也减轻了数据库压力。如果你的项目已经引入消息队列把日志实体发到队列再由消费端落库也是同样的思路。这里有一个特别注意的点异步写入意味着日志可能有少量丢失。所以在监听器里一定要先同步拼好完整实体再交给异步队列避免先返回后补全导致的字段缺失。对日志场景来说偶尔丢一条可以接受但绝不能丢字段。5.2 JSON 字段别当查询条件早期为了省事我把所有请求消息都塞在request_messages_json里后来产品要查哪些请求包含某个敏感词我直接对 JSON 字段做LIKE %敏感词%结果数据量一大查询秒级变分钟级还拖垮了线上数据库。教训就是JSON 字段只能当存档不能被当作查询条件。这类需求一定要在建表时就拆出独立字段或者在写入时把高频分析维度冗余出来比如单独存一个keywords字段或关联分析表。如果你想对消息内容做全文检索那应该考虑接入专门的全文检索服务而不是在关系库里用 LIKE 硬扛。5.3 数据量增长与保留策略一定要提前规划还有一个容易低估的问题是数据量增长。没有提前规划保留策略的话这张日志表会变成团队里最大的表。我在上文估算过日均 10 万次调用、每次 5KB 存档一个月就能到十几 GB。更麻烦的是数据量上来之后即使查询走了索引也会因为表太大而变慢归档操作还会锁住一部分写入。我的建议组合是核心分析字段保留 30 天完整存档保留 90 天更早的数据按月份归档到冷存储或者直接清理。业务上如果确实需要长期分析历史趋势可以在归档时只保留聚合后的结果表这个成本远低于保留全量明细。最后再分享一点个人体会。调用日志的结构化存储和分析不是一个有则更好的加分项而是 LLM 应用上线后的刚需。没有它你无法回答成本超支、回答质量下降、模型响应变慢这些问题只能凭感觉做优化。如果你想在自己项目里落地这套能力建议不要一上来就追求大而全先做一个最小闭环跑通监听器、把关键字段打到日志里、用几条最简单的 SQL 看到成本和延迟趋势然后再逐步把表结构、索引、分析场景补全。这个版本在面试和真实开发里都是最稳妥的起点。
