[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。

參考資料

• 角色管理
• 使用者管理
• 告警規則