审计日志

[PLUS] 审计日志是夜莺企业版（PLUS）独有功能。

概述

审计日志 = 平台所有"谁，什么时候，对什么资源，做了什么操作“的完整记录。

侧栏路径：系统配置 → 审计日志，URL /system/audits。

适用场景：

• 合规审查：金融/政企等行业的合规要求，需要任意时点回溯操作历史；
• 故障回溯：告警规则突然不工作了？看下最近有没有人改过；
• 权限滥用排查：发现敏感操作时定位是谁干的；
• 变更管理：发版后核对变更项，找出"被遗漏的"或"被多做的"配置改动；
• 新人交接：通过审计日志快速了解前任在系统里做过哪些自定义配置。

筛选条件

页面顶部支持的过滤：

字段	说明
操作类型	Create（新增） / Update（修改） / Delete（删除）；查询操作（Query）单独记录
操作对象	资源类型，如 alert_rule（告警规则）、dashboard（仪表盘）、user（用户）、notification_channel（通知媒介）等
操作对象 ID	精确匹配某个具体资源的 ID
操作人	按用户名筛 — 看某个特定账号做过什么
时间范围	默认最近 12 小时，最长不限（取决于审计日志保留策略）

填好后点「查询」生效。

列表字段

列	含义
操作时间	操作发生的精确时间
操作类型	Create / Update / Delete / Query
操作对象	资源类型 + 资源标识（如 alert_rule:disk-usage-high）
操作人	操作账号的用户名
操作人昵称	显示名（来自用户管理）
操作	末尾「变更对比」按钮，对 Create/Update/Delete 类操作展开 diff

变更对比（核心能力）

点列表行末尾的「变更对比」，会展示该次操作的前后差异，类似 git diff 的视图：

• 新增（Create）：显示新建后的完整内容（绿色高亮，无对比基准）；
• 修改（Update）：左右双栏对比"变更前 vs 变更后”，逐字段高亮变化点；
• 删除（Delete）：显示被删除的完整内容（红色高亮）；
• 查询（Query）：显示当时执行的查询语句和数据源（不涉及内容变更，无 diff）。

这是审计日志的核心价值 — 不仅记录"做了什么"，还记录"具体改了什么"，复盘故障时能精确还原历史状态。

数据保留 & 性能

• 审计日志默认长期保留（在数据库里独立表，不参与 N 天自动清理）；
• 数据量大时（百万 +），列表打开会慢 — 优先用过滤条件缩小范围再查；
• 合规场景需要长期归档：建议用 OpenAPI 定期导出到外部存储（OSS / S3）做冷备。

常见问题

Q1：审计日志能看到所有人的操作还是只能看自己的？

A：取决于权限。Admin 角色默认能看全平台所有用户的操作，普通用户只能看自己的。如果非 Admin 看不到这个菜单，去检查 角色管理 里这个角色对 audit_log 资源的权限设置。

Q2：哪些操作会被审计？哪些不会？

A：默认审计：

• 会审计：所有"写"类 API（POST/PUT/DELETE），覆盖告警规则、仪表盘、通知配置、数据源、用户、SSO 设置等核心资源；用户登录/登出；通知规则的派发执行（可选）。
• 不审计：纯前端交互（点击/筛选）；GET 类读操作（默认）；指标即时查询（每秒大量请求，开了审计会爆磁盘）。
• 可配置：Query 类型审计在 n9e.toml 里可以打开 — 适合金融/合规场景，但会显著增加审计表大小。

Q3：审计日志能不能改？合规上需要保证不可篡改

A：从平台 UI 上没有提供修改/删除审计记录的入口 — UI 层面是只读的。但数据存在 MySQL/PostgreSQL 里，DBA 直接改库可以绕过。强合规场景推荐：

• 把审计日志定时同步到外部 WORM（Write-Once-Read-Many）存储；
• 数据库审计 + 数据库账号权限隔离；
• 应用层操作 + 数据库底层操作的双重审计对账。

Q4：变更对比按钮显示"无数据"，怎么回事？

A：通常是这条记录是 Query 类型 — 查询操作没有"前后状态"可对比。Query 审计只记录"谁查了什么"，不记录"查到了什么"。这条记录仍然可用于权限审计，只是没有 diff。

参考资料

• 角色管理
• 用户管理
• 告警规则