什么是调用日志？排查与审计，通俗版解释

AI 应用出问题，用户反馈一进来，老手的第一个动作永远是打开调用日志。这篇讲清日志里到底记了什么、为什么它既能排查故障又能支撑审计。

日志记下每一次敲门

每一次调用接口，都像有人敲了一次门：谁敲的、几点敲的、问了什么、门开没开、屋里花了多少功夫。调用日志就是把每一次敲门都记成一行流水，事后随时翻查。没有日志的服务像不装行车记录仪的车，出了事全靠回忆，而回忆在排障时是最不可靠的东西。

日志通常由两层产生：平台侧有调用记录，自建网关和服务也有自己的访问日志，两边对照着看，才能分清问题出在谁家。

一条日志里都有什么

拆开一条典型记录，字段大致几类。身份类：用了哪把密钥、哪个账户、哪个应用发起的。时间类：请求到达的精确时刻、服务处理花了多久。内容类：请求的模型名、参数设置、输入输出各多少 token。结果类：状态码是成功还是限流、报了什么错、本次计了多少量。

四类字段各自记什么、排查时看哪一类：

这些字段单看平常，串起来就是破案线索。比如某个时段突然全部超时，看时间字段锁定区间；再看身份字段发现全是同一把密钥，矛头就指向那个应用；再看内容字段发现输入长度暴增，原因可能就是某个上游业务开始塞长文档了。

日志排查三步

• 先按时间和状态码过滤，圈出异常请求的范围
• 再看密钥和应用维度，定位是全局问题还是个例
• 最后比对请求内容的变化，找到引发异常的变量

从宽到窄收网，比盯着单条报错硬猜快得多。

排查用日志，审计也用日志

排查是日志最常见的用法，但它还有另一副面孔：审计。团队想知道 AI 接口被谁用在了什么地方、有没有超出约定的用途、费用和用量对不对得上账，答案都在日志里。排查面向过去的一次故障，审计面向一段时间的全量行为，前者求快，后者求全。

审计场景对日志提出额外要求：记录要完整不能抽样，保存要够久通常按月起步，敏感内容要按规范处理——日志里往往有用户的提问原文，留存策略要跟上公司的数据管理规定。自建服务时容易忽略这一点，出事想回溯才发现日志只留了三天。

记多久、看什么

个人项目记一周到一个月，够排查用就行；团队服务按审计需求定，常见一到一个季度。日常不用天天翻，抓住三个时机看它：接到报错反馈时、账单异常时、做变更前后——变更前留个基线，变更后对比，出了问题立刻知道是不是刚才那次改动引入的。通义千问、讯飞星火这类开放平台都在控制台提供调用明细，自建服务则要自己把访问日志落到文件或日志系统里，两边的详略程度不同，排查时以最细的那份为准。

让日志替你记着

日志是服务的行车记录仪：平时没人看，出事时它是唯一的目击者。养成三个习惯——变更前后各看一眼、报错先翻日志再猜原因、定期确认日志保存策略还在生效。限流报错怎么对着日志判断，回看什么是网关限流？给 API 加一道闸；换钥匙前后靠它确认无缝，见什么是密钥轮换？定期换钥匙，看完就会判断；日志里的用量数据汇总起来就是什么是用量看板？花费的可视化，新手版入门；账要守住底线还差一道什么是预算告警？超支前提醒，别再混淆了；日志之外服务挂了怎么兜底，读什么是降级路由？主模型不可用时。

关于调用日志再多问三句

• 日志会记录用户提问的完整原文吗？：多数平台会留存请求内容用于排查，具体保存时长和范围以各家说明为准，对接入方来说要按自己的数据管理要求评估。
• 排查时先看平台日志还是自家日志？：先看自家网关日志确认请求发出去了，再看平台记录确认收到了什么、回了什么，两头一比边界就出来了。
• 日志量太大存不起怎么办？：分层保存——原始明细留短期，聚合后的统计留长期，既保住排查能力又控住存储开销。