[PLUS] Audit log is a feature exclusive to Nightingale Enterprise (PLUS).

Overview

Audit log = a complete record of “who, when, on what resource, did what operation” on the platform.

Sidebar path: System Configuration → Audit Log, URL /system/audits.

Use cases:

• Compliance review: financial / government industry compliance requirements demand operation history traceability at any time;
• Fault retrospection: alert rule suddenly stopped working? See if someone recently changed it;
• Privilege abuse investigation: when sensitive operations are detected, locate the responsible party;
• Change management: after a release, audit the changes, find “missed” or “extra” configuration changes;
• Onboarding handover: through audit logs, quickly understand custom configurations made by the predecessor in the system.

Filter Conditions

Filters supported at the top of the page:

Field	Description
Operation type	Create (new) / Update (modify) / Delete (remove); query operations (Query) are recorded separately
Operation target	Resource type, e.g. alert_rule (alert rule), dashboard, user, notification_channel, etc.
Operation target ID	Exact match for a specific resource ID
Operator	Filter by username — see what a particular account has done
Time range	Default last 12 hours, no upper bound (depends on audit log retention policy)

Click “Query” after filling in to take effect.

List Fields

Column	Meaning
Operation time	Precise time of the operation
Operation type	Create / Update / Delete / Query
Operation target	Resource type + resource identifier (e.g. alert_rule:disk-usage-high)
Operator	Username of the operator account
Operator nickname	Display name (from user management)
Operations	Trailing “Diff” button, expanded for Create/Update/Delete

Diff (Core Capability)

Click “Diff” at the end of a list row to show the before/after differences of that operation, similar to a git diff view:

• Create: shows the full content after creation (highlighted in green, no comparison baseline);
• Update: two-column comparison “before vs after”, with field-by-field highlight of changes;
• Delete: shows the full content that was deleted (highlighted in red);
• Query: shows the query statement and data source executed at the time (no content change involved, no diff).

This is the core value of audit logs — recording not only “what was done” but also “exactly what was changed”, enabling precise reconstruction of historical state during incident retrospection.

Data Retention & Performance

• Audit logs are retained long-term by default (a separate table in the DB, not subject to N-day auto-cleanup);
• When data volume is large (millions+), opening the list slows down — narrow the range with filters first;
• For compliance scenarios requiring long-term archival: export periodically via OpenAPI to external storage (OSS / S3) for cold backup.

FAQ

Q1: Can audit logs see everyone’s operations or only my own?

A: Depends on permissions. Admin role can see all users’ operations across the platform by default; regular users can only see their own. If a non-Admin can’t see this menu, check Role Management for that role’s permission on the audit_log resource.

Q2: Which operations are audited? Which are not?

A: Default audit:

• Audited: all “write” APIs (POST/PUT/DELETE) covering core resources like alert rules, dashboards, notification configs, data sources, users, SSO settings, etc.; user login/logout; notification rule dispatch execution (optional).
• Not audited: pure frontend interactions (clicks/filters); GET read operations (default); ad-hoc metric queries (massive request rate per second, enabling audit would explode disk).
• Configurable: Query-type audit can be turned on in n9e.toml — suitable for finance / compliance scenarios but will significantly grow the audit table size.

Q3: Can audit logs be modified? Compliance requires tamper-resistance

A: From the platform UI, there is no entry to modify/delete audit records — the UI is read-only. But the data lives in MySQL/PostgreSQL, and a DBA modifying the DB directly can bypass it. For strong compliance scenarios:

• Synchronize audit logs periodically to external WORM (Write-Once-Read-Many) storage;
• Database audit + database account privilege segregation;
• Dual audit reconciliation between application-layer operations and database-layer operations.

Q4: Diff button shows “no data” — what happened?

A: Usually because this record is a Query type — query operations have no “before/after state” to compare. Query audit only records “who queried what”, not “what was returned”. The record is still useful for permission audit, just no diff.

References

• Role Management
• User Management
• Alert Rules