做运维的人对日志有特殊的感情。平时没人看出问题了第一个找的就是日志。之前用其他AI网关的时候日志这块普遍做得比较糙。有的只有调用日志没有操作日志有的搜索功能不好使有的导出数据缺字段。真到排查问题的时候急得团团转。最近搭了MAI Gateway v1.2.0的环境专门测了一下调用审计这块。把实际看到的功能、操作过程、踩过的点都记下来给需要选型的同行一个参考。一、先看整体结构v1.2.0的日志审计菜单下有三个子项API请求日志、日志审计白名单、操作日志。三个功能分开各管一块。操作日志记的是后台管理操作谁登录了、谁改配置了、谁加模型了。API请求日志记的是每一次模型调用请求参数是什么、返回了什么、耗时多少。白名单是过滤用的有些不需要记日志的请求加进去。这个结构比较清晰。很多产品把操作日志塞在系统设置里面藏得很深找半天找不到。单独拉出来做一级菜单用的时候方便很多。二、操作日志实测先测操作日志。我故意做了几个操作加了一个令牌、改了一下脱敏规则、删了一个测试用户然后去操作日志里看能不能查到。打开页面第一眼是四个统计卡片。今日操作数、活跃用户数、敏感操作数、异常操作数。这四个卡片设计得不错。日常运维不用一条条翻日志扫一眼这四个数就行。我测的时候因为刚做了几个操作今日操作数涨了几个活跃用户是1个就是我自己敏感操作数1个改脱敏规则算敏感操作异常操作数0。都对得上。下面是操作记录表。每条记录六个字段时间、用户、模块、操作类型、IP地址、结果。我刚才做的三个操作都在里面时间对得上操作类型分了新增和修改颜色不一样蓝色是新增橙色是修改。IP地址显示的是我本机的IP。结果都是成功。试了一下搜索功能。按用户搜输入我的用户名出来我所有的操作。按模块搜选安全管理只显示脱敏规则的修改记录。按操作类型搜选新增只显示加令牌的那条。筛选组合起来用定位挺快的。导出功能也试了。导出的是CSV格式字段跟页面上的一致能用Excel打开。做合规报告的时候直接导出来就行不用自己拼数据。三、API请求日志实测操作日志是给管理员用的API请求日志才是运维天天查的东西。我发了几个测试请求然后去请求日志里看。v1.2.0的对话视图做了优化区分了工具调用和请求参数。之前用其他产品的时候工具调用的参数跟正常请求混在一起排查问题特别费劲。这里分开了看起来清楚很多。还有一个细节耗时展示统一用秒了。之前碰到过有的地方显示毫秒有的地方显示秒对数据的时候经常搞错。统一单位之后省事不少。我故意发了一个报错的请求看看错误信息显示得全不全。错误码、错误信息、返回头都能看到。排查问题的时候这些信息很重要。有的产品只给一个调用失败啥细节没有根本没法定位。链路监控页面的数据来源就是API请求日志。每条链路的模型对接状态、延迟、成功率都是从日志里统计出来的。链路监控适合日常巡检。每天早上扫一眼哪个模型延迟高了、哪个模型成功率掉了一眼就能看到。有异常再去请求日志里深挖。四、日志审计白名单实测白名单这个功能我之前没太在意。测的时候发现还挺实用的。我们有个健康检查的脚本每分钟调用一次接口探活。这笔调用记日志的话一天就是1440条占存储空间不说查日志的时候还干扰视线。加到白名单里之后这些请求就不记日志了日志里干净很多。加白名单的时候要注意不能什么都往里加。涉及敏感数据的、涉及费用的、涉及权限的绝对不能加。只加那些明确无风险的、纯探测性的、高频次的请求。还有一点白名单本身的操作也要记日志。谁加了白名单、加了什么、什么时候加的操作日志里要有记录。不然有人偷偷把自己的请求加了白名单审计就有漏洞了。我测了一下加白名单的操作确实在操作日志里有记录这点没问题。五、场景演练配置变更排查光看功能说明太虚模拟一个实际场景试试。场景是这样的假设某天早上客服系统的AI助手突然不好使了用户报障。作为运维怎么排查。第一步先看链路监控。打开链路监控页面看各个模型的状态。发现客服常用的那个模型成功率掉到了30%延迟也涨了不少。初步判断是模型这边的问题。第二步查操作日志。看看最近有没有人改过这个模型的配置。选模型管理模块看最近24小时的操作。发现凌晨两点有一条修改路由权重的操作记录是另一个同事改的。他把另一个模型的权重调高了客服模型的权重被压下去了。第三步回滚配置。把权重改回去等两分钟再看链路监控成功率恢复了。然后通知业务方验证确认没问题。第四步写事件报告。把操作日志里的记录导出来附在报告里。什么时间、谁改的、改了什么、影响多大、怎么恢复的写清楚。整个过程下来十几分钟搞定。要是没有操作日志光排查是谁改了配置就得花半天。六、场景演练费用异常排查再练一个场景。月底对账的时候发现这个月的费用比上个月涨了不少得查原因。第一步看消费明细。切到部门维度看是哪个部门涨的。发现研发部涨得最多。再切到项目维度看研发部下哪个项目涨的。定位到一个新上线的内部工具项目。第二步看成本优化。高耗用户排名里这个项目的开发者排第一。点归因分析看他的调用模式。发现输出Token特别大输入反而不大。说明可能是生成场景每次让模型输出很长的内容。第三步查API请求日志。搜这个用户的令牌看最近的调用记录。发现他在做代码生成每次让模型生成大段代码输出Token是输入的好几倍。而且同一个问题反复调说明效果不好一直在试。第四步跟开发者沟通。告诉他成本情况建议他调整prompt或者换一个更便宜的模型做代码生成。如果网关支持智能路由的话可以让网关自动路由到性价比更高的模型。这个场景里消费数据定方向请求日志查细节两层配合很快就能定位原因。七、不足的地方说了这么多好的也说点不足。第一个操作日志的模块粒度有点粗。比如费用中心下面有好几个子页面消费明细、成本优化、配额使用但操作日志里的模块字段只显示费用中心不显示具体是哪个子页面。排查的时候还得点进去看详情稍微麻烦一点。第二个API请求日志的搜索条件可以再加几个。现在主要是按时间和用户查如果能按模型、按状态码、按Token范围搜就更方便了。排查特定模型的问题的时候按模型筛选比一条条翻快多了。第三个日志保留策略没看到在哪里配置。日志存多久、什么时候归档、什么时候清理这些应该有个配置页面。不同企业的合规要求不一样保留周期也不一样。这几个都是体验层面的问题不影响核心功能。但日常用得多了这些细节就很影响效率。希望后续版本能优化一下。八、总结整体测下来MAI Gateway v1.2.0的调用审计功能是够用的。操作日志的四个统计卡片是亮点日常巡检很方便。API请求日志的对话视图区分了工具调用排查问题更清楚。白名单功能实用能过滤掉无价值的日志。注册即可获得200W超高试用额度和企业级AI网关试用魔芋AI大模型网关I全球大模型一站式调用及服务平台魔芋AI大模型聚合平台大模型网关平台专注于提供高效能、低成本的多品类 AI 模型服务助力开发者和企业聚焦产品创新。https://www.moyu.cn/register?affXVPz对于运维来说日志功能的要求就几个。记录要全不能漏。查询要快不能卡。导出要方便不能缺字段。这几点v1.2.0基本都做到了。当然也有可以改进的地方比如模块粒度、搜索条件、保留策略这些。但核心功能是扎实的满足企业级的审计需求没问题。选型的时候很多人只看模型接入数量、价格这些表面的东西忽略了日志审计。真上线了才发现日志不好用排查问题能急死人。建议选型的时候把调用审计作为一个重点考察项实际搭环境测一测。