This plugin is to be used to track transactions in the Cacti database, when they were made, by what IP address and by what login account. This can be used to determine the root cause of issues created by users of the Cacti system.
This plugin allows Cacti Administrators to log user change activity
-
Log all $_POST activities to the Cacti Server that can change the contents of the system.
-
Captures CLI commands and who ran them
Audit entries generated by the config_insert hook begin with request status
started and are finalized as completed or failed when PHP shuts down. A
completed request does not necessarily prove that every page-specific database
operation succeeded.
Install just like any other plugin, just throw it in the plugin directory, and Install and Enabled from the Plugin Management Interface. Make sure the plugin directory is named 'audit' and not 'plugin_audit'.
Once this is done, you have to goto Configuration -> Settings -> Audit and define data retention and turn on auditing.
You can also enable file-based logging for ingestion by SIEM or log-analysis
tools such as Splunk. External records can be written as newline-delimited JSON
(one JSON object per line) or as single-line text using quoted key="value"
fields. Control characters in text values are escaped so every event remains on
one line. In JSON output, post and object_data are native nested structures,
not JSON-encoded strings. JSON is the default to preserve the format used by
earlier releases.
External file delivery is tracked on each database record. Failed appends are retried by the poller in batches and therefore have at-least-once delivery semantics; downstream ingestion should deduplicate when necessary.
Version 1.4 records a stable event UUID and request correlation UUID on new
events. External records are written only after request finalization, so SIEM
consumers receive the final request status instead of the earlier transient
started state. Consumers should deduplicate on event_uuid.
The normalized fields distinguish request processing from the result of the
requested Cacti operation. request_status=completed means that PHP request
processing completed without a fatal error or an HTTP error response. It does
not by itself prove that page-specific validation or database work succeeded.
operation_outcome remains unknown unless an authoritative Cacti 1.2.x hook
or plugin-owned operation supplies the result.
The plugin also audits access to its own event list, searches, event details,
exports and purge operations. Logout and session-timeout events are captured
through Cacti's supported logout_pre_session_destroy hook. Database-level
changes, API activity and MFA events are outside the current Cacti 1.2.x scope.
If you figure out this problem, see the Cacti forums!
Got any ideas or complaints, please log an issue on GitHub.
Copyright (c) 2004-2026 - The Cacti Group, Inc.