Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
LogicMonitor’s audit logs provide insight into recent account activity, such as user logins and configuration changes made to resources in the account. Each audit log entry provides a timestamp for the event, the username associated with the event, the IP address associated with the event, and a description of the event. For example, you could use the audit logs to identify when alerting was disabled for a particular device group, or which user updated a particular resource property, and so on.
The duration of time for which audit log entries are preserved is determined by the “alert history storage” level associated with your LogicMonitor package. For a breakdown of “alert history storage” levels by package, visit the LogicMonitor pricing page.
As discussed in this support article, there are several ways in which to access and query your platform’s audit logs: Audit Logs page, Audit Logs report, and LogicMonitor’s REST API.
Note: When reviewing audit logs, it is common to see consecutive login events with no log out—if the user does not explicitly log out, but simply lets the session go idle, then starts using LogicMonitor again (possibly from a different computer), a new login event will be recorded.
Accessible from Settings | Audit Logs, the Audit Logs page provides an interface from which you can view and filter audit logs.
The audit log entries that display on the Audit Logs page can be filtered according to time range and user name. Audit log entries can also be searched using keywords found in the User, IP and Description columns. Single keywords are automatically wildcarded on both ends. For example, a search term of “time” could return “time”, “uptime”, and “timeout.”
If multiple search terms are entered, they are automatically joined using the AND operator and are wildcarded at the beginning and end of the full search string (e.g. searching on “trigger alert” is the same as searching on “*trigger AND alert*”). Be sure to add additional wildcards when multiple search terms are in use if necessary. For example, if you want “trigger AND alert” to match on logs containing the keyword “trigger” or “triggers,” you’ll need to manually enter one more wildcard (i.e. “trigger* AND alert”).
An OR or an AND NOT operator can be used instead of the default AND operator. When using either of these operators, only a single keyword can be on either side of the operator. For example, searching on “trigger OR alert” will return results as expected, but searching on “trigger alert OR SAML” will not.
With the exception of manually entered operators (i.e. AND, OR, and AND NOT), keyword searches are not case sensitive. A keyword search is joined with other current active filters using an AND operator.
Note: The Audit Logs page only provides a month’s worth of audit log entries for dynamic viewing and filtering. In order to access entries further back, assuming your account’s “alert history storage” level supports a longer duration of historical log data, you’ll need to run the Audit Log report.
The current display of log entries on the Audit Logs page can be downloaded in one of two forms:
As discussed in Audit Log Report, the Audit Log report offers the same filter and search capabilities as the Audit Log page, but expanded capabilities when it comes to output formats, sorting, and duration of historical data available. And, as with all LogicMonitor reports, the Audit Log report can be scheduled to run on a recurring basis.
Audit log entries can be queried from the LogicMonitor REST API. These results can be further refined for post-processing and analysis. For more information, see Get Audit Log Entries.
In This Article