监控：调用 · 审计 · 系统日志

监控分组有三个菜单：调用日志看每次对话调了哪些工具、审计日志看谁动了什么配置、系统日志看原始进程输出。仅 super_admin 可见。日常排查从「调用日志 → 审计日志 → 系统日志」三层下钻最快。

10.1 三个监控菜单：分别看什么

监控分组只对 super_admin 可见，admin 角色侧边栏不会出现整个「监控」组。三个菜单职责严格不重叠，按「业务调用 → 配置变更 → 进程异常」由表及里排列。

提示： 权限提示：admin 看不到监控分组，是设计如此。如果运维同事需要查日志，要么升 super_admin，要么由 super_admin 截图发过去。不要把 super_admin 当默认角色分发。

10.2 调用日志 /admin/traces：每次对话调了什么

调用日志是一条「对话 → 工具调用链」的全息记录。一次用户提问可能触发一次模型调用 + 多次 skill / MCP 工具调用，traces 把它们串起来，每个节点带耗时和错误标记。

10.2.1 页面顶部 24h KPI（4 卡）

1. 24h 调用量：含工具轮次 / 失败次数
2. 平均耗时：副标当前显示「P95 待加」（未实装）
3. 错误率：百分比 + 失败/总次数
4. Token 总量：in / out 分别展示

10.2.2 查询步骤

1. 进 /admin/traces，默认按时间倒序分页展示。
2. 顶部 tab 切「全部 / 带工具 / 失败 / mock」四类。
3. 「按系统过滤」下拉按 server 维度筛选。
4. 搜索框可搜：用户提问、模型名、session_id、助手摘要。
5. 点行打开右侧抽屉 → 按 turn 渲染：上下文消息 + 用户提问 + 助手回复（含模型 / 耗时 / token + 扁平事件流 EventFlow，raw 模式展示原始事件）。

典型 trace 长这样（展开后右侧详情面板）：

session: sess_a1b2c3
duration: 4280 ms (p95 today: 3950)
└─ model.deepseek-chat        2340 ms   prompt 1.2k → 480 tokens
└─ tool: menu_get_top           120 ms   ok
└─ tool: da_query               980 ms   ok    rows=42
└─ tool: da_get_infos           640 ms   ERROR  field 'F_DEPT' not found
└─ model.deepseek-chat (retry)  200 ms   prompt 1.4k → 130 tokens

注意： 排查口诀：用户反馈「慢」先看 duration 是不是 > p95；反馈「错」先看哪行带红色 ERROR。8 成问题在这一屏看完。

10.3 审计日志 /admin/audit：谁动了什么

审计日志记录所有写操作（创建 / 修改 / 删除 / 登录），按 category 分类，每条带 target_label 人话描述和字段级 before-after diff。专治「昨天还好今天不行」「谁把配置改了」。

10.3.1 category 分档（顶部筛选 chip）

10.3.2 顶部 KPI 4 卡

1. 事件总数：副标显示当前时间范围（今天 / 近 7 天 / 近 30 天，默认 7 天）
2. 敏感操作：副标「删除 / 改超管 / 重置密码」
3. 失败 / 警告：副标「登录失败 / 删除 / 异常」
4. 操作人：副标显示爆破组数 或 「无异常聚类」

10.3.3 一条记录长什么样

1. category 标签：敏感 / 变更 / 登录 / 查询
2. target_label「人话」：把管理员 zhang3 角色改成 super_admin
3. 字段级 diff 表：字段 / 之前 / 之后 三列，删除线红 vs 绿
4. actor：操作人 + 角色 + 来源 IP + 浏览器 + 平台 + 服务器
5. 高级 payload：折叠展开看原始 action code + JSON payload

10.3.4 爆破聚类 + 时间线视图

同一 IP 短时间多次失败登录会聚类成 1 行「⚡ 疑似爆破 — 5 分钟内 N 次登录失败」，避免审计页被刷屏。点击 cluster 行展开看每一次子事件。

页面右上角切「时间线视图」（list-timeline 图标）：按操作人分组，每组显示事件计数和最高风险等级（🔴 含敏感 / ⚠️ 含失败登录），便于看哪些人当天动作最多。

提示： 敏感操作 KPI：顶部 KPI 第 2 卡「敏感操作」涵盖删除关键资源 / 新增管理员 / 改密码 / 角色变更。若数值 > 0 卡片会高亮红色左边条；建议每周点开核对一次。右上角还有「导出 CSV」按钮可把当前筛选结果导出。

10.4 系统日志 /admin/system-logs：原始日志流

系统日志是 agent 进程的原始 stdout / stderr，跟 docker logs / 控制台输出基本等价。前两个菜单查不到的疑难（比如「连不上 DeepSeek」「WebSocket 断了」）来这里 grep 堆栈。

10.4.1 使用步骤

1. 进 /admin/system-logs，顶部下拉框选要看的日志文件（默认选当前正在写入的那个，带绿色「当前正在写入」徽标）。
2. 默认 tail = 1000 行；下拉可切 500 / 1000 / 5000 / 10000 行。
3. grep 框输入关键词（如 ERROR / timeout / DeepSeek），按回车过滤。
4. 级别 chip：全部 / INFO / WARN / ERROR / DEBUG，按行首 [LEVEL] 头分类过滤（traceback 延续行跟随其上一行 header 的级别一起显示）。
5. 「滚到底部」按钮跳到最新；右上「下载」按钮直接下载整个日志文件（不带 grep 过滤）。

10.4.2 常用 grep 关键词

注意： 系统日志是诊断兜底，不是常规巡检入口。看到大段红色堆栈不要慌，先复制堆栈最后一行 + traceback 顶部 4 行，去群里问运维或附在 issue 里，比截整屏有用。

10.5 三层下钻：排查问题的标准动作

遇到用户反馈，按「调用日志 → 审计日志 → 系统日志」三层下钻，95% 问题能在前两层定位。

1. 第一层 · 调用日志：拿用户的 session_id 或时间 + 用户名，去 traces 找那次对话。看 duration、错误工具、错误信息。多数答错 / 答慢在这层结案。
2. 第二层 · 审计日志：如果用户说「昨天还好」，去 audit 查问题工具 / skill / 模型 / 服务器对应配置在最近 24h 是否被改过。看 before-after diff，找到那一刀回滚。
3. 第三层 · 系统日志：前两层都没线索（比如「整个服务挂了」「全员答不出」），来 system-logs grep ERROR / Traceback，看进程层异常。

10.5.1 三个典型场景

提示： 给到运维的最小信息：session_id（traces 顶部）+ 时间 + 截图三件套。这三样比口述「他说不行」管用 10 倍。

10.6 监控自身的健康：每周巡检 5 分钟

不出事的时候也建议每周快速扫一眼三个监控页，5 分钟搞定，能提前发现慢慢恶化的问题。

1. 周一上午看 traces 周 KPI：错误率 / p95 跟上周比，差超 20% 要查。
2. 周一上午看 audit 时间线：上周末是否有非预期的 security 类操作。
3. 周一上午看 system-logs：grep ERROR 看上周末有没有翻车堆栈被忽略。
4. 有问题在系统管理 / 系统设置里联动调整（订阅鉴权探测 / 数据迁移 / 桌面端升级）。

提示： 下一步：监控发现的配置类问题，去系统管理章节看怎么联动改账号、改系统设置、推桌面端升级。

相关

• Skill 技能包管理
• 提示词管理
• 系统管理：管理员 · 设置 · 桌面端升级