企业官网建设流程全解析

做运维的人对日志有特殊的感情。平时没人看，出问题了第一个找的就是日志。

之前用其他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?aff=XVPz

对于运维来说，日志功能的要求就几个。记录要全，不能漏。查询要快，不能卡。导出要方便，不能缺字段。这几点v1.2.0基本都做到了。

当然也有可以改进的地方，比如模块粒度、搜索条件、保留策略这些。但核心功能是扎实的，满足企业级的审计需求没问题。

选型的时候，很多人只看模型接入数量、价格这些表面的东西，忽略了日志审计。真上线了才发现，日志不好用，排查问题能急死人。建议选型的时候把调用审计作为一个重点考察项，实际搭环境测一测。