--- title: "Monitor Event Logs" slug: "monitor-event-logs" description: "Set event log rules in a SysTrack role to raise alarms on Windows events, choose which events to keep, and avoid high agent CPU use." status: "update" updated: 2026-10-26T10:40:25Z published: 2026-10-26T10:40:25Z canonical: "documentation.lakesidesoftware.com/monitor-event-logs" --- > ## Documentation Index > Fetch the complete documentation index at: https://documentation.lakesidesoftware.com/llms.txt > Use this file to discover all available pages before exploring further. # Monitor Event Logs Use **Events** on the Roles page to start alarms when specified events are found in the Windows event log and establish the rules applied to events that are detected in the log. The event log monitor periodically inspects all of the logs on a system, checking to see if anything new has happened since the last time the log was inspected. A newly discovered event is run through a set of filters to determine whether or not a notification is to be sent or what action should be taken. The applied filters can be the default settings, completely defined by the user, or a combination. Furthermore, event log alarms can be triggered by specific character strings found in any of the event properties. ![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/event_logs1.png?sv=2026-02-06&spr=https&st=2026-11-03T04%3A25%3A37Z&se=2026-11-03T05%3A25%3A37Z&sr=c&sp=r&sig=UfKADsPmJfWPTOYgejkQRJZUoBDhcZgkRe9k9lDO0io%3D) ## Configure Event Log Retention and Alarms 1. Go to **Configure** > **System Configuration** > **Roles**. 2. Click the lock icon in the upper-right corner to unlock Configure for editing. 3. Select the role. 4. From the **Additional Settings** list, select **Events**. 5. Expand **Settings**. Under **Record Retainment**, select the check box for each **Retain all … events** item that you want the agent to keep. All five items are cleared by default. > [!CAUTION] > **WARNING**: Selecting **Retain all information events** can greatly raise agent CPU use. Test it on a small group of systems first. 6. (Optional) In **Event log data retention period**, enter how many days to keep event log data. The default is 30 days, and the range is 0 to 365. A shorter retention period keeps less event log history on each system. > [!CAUTION] > **WARNING**: Systems that use the role delete event log data older than the retention period at each purge, by default once a day. If you shorten the period, the older data is deleted at the next purge. 7. (Optional) In **New events will be ignored if there are more pending alarms than the number specified here**, enter the upper limit of pending event log alarms. The default is 300. 8. The Event Log Monitoring comes equipped with a default setting to monitor **All Other Logs** of events and to raise an alarm on errors. However, you can add new sources, select alarms for those sources, and select which information (Error, Warnings, Audit Success, etc.) you wish to retain in the logs for the selected **Notification** and **Action**. (Select the desired **Notification** and **Action** from the drop down list to the right of the check box items). For a new source, both are **None** by default. 9. Click **Save Changes**. ## Event Sources 1. To add an event source to the **Events** settings of a role, expand **Event Sources** and click the **plus icon**. The **Add New Setting** dialog box opens. ![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/event_sources_add.png?sv=2026-02-06&spr=https&st=2026-11-03T04%3A25%3A37Z&se=2026-11-03T05%3A25%3A37Z&sr=c&sp=r&sig=UfKADsPmJfWPTOYgejkQRJZUoBDhcZgkRe9k9lDO0io%3D) 2. Under **Select sources from a model system**, select the system whose event sources you want to list. 3. Under **Display sources from the following category**, select the event log category. 4. Under **Sources**, select the sources to monitor, or select **All Other Logs**. 5. Click **Create**. 6. Click **Save Changes**. ## Text Rules In the **Text Rules** pane, the following two options will perform two separate evaluations and apply the alarm appropriately: - **Always Send:** If the event log contains a text field and is found to match the string entered on one of the rows, then an alarm will be triggered. All notification settings will be used. - **Never Send:** If the event log contains a text field and is found to match the string entered on one of the rows, then an alarm will not be sent. This suppresses the alarm for the specific instance. This method of controlling alarms and notifications can be as simple as cutting and pasting a text string from the actual event log fields to the desired grid row. This will ensure consistency of the text string in formulating a match between the SysTrack Agent and the event log. There is no defined limit to the number of rows that can be added to the Text Rules. ![](https://cdn.document360.io/87d11426-6b1f-4b19-b593-b71e55a81af3/Images/Documentation/event_logs_textrules.png?sv=2026-02-06&spr=https&st=2026-11-03T04%3A25%3A37Z&se=2026-11-03T05%3A25%3A37Z&sr=c&sp=r&sig=UfKADsPmJfWPTOYgejkQRJZUoBDhcZgkRe9k9lDO0io%3D) ### Add a New Text Rule 1. Click the plus **+** icon under **Always Send** or **Never Send** on the **Text Rules** pane. 2. Enter a name. 3. Click **Create**. 4. Click **Save Changes**. > [!WARNING] > **IMPORTANT**: Additional Notes > > - Event log alarming is one area of the product where, because of the sometimes unpredictable actions of both logs and/or configured rules, the agent and database could become burdened. > - A poorly configured **Always Send** text rule or event alarm can cause high CPU utilization and a large child database. An **Always Send** text rule can cause CPU spikes even when it has no notification or action. Event log retention also falls into this category. > - Retention of highly active event log sources means a busy agent and child database. It is highly recommended that event log alarming and retention is tested with a small group of systems before being deployed across a large enterprise. > - Event log alarming should be used selectively, it is not designed as a catch all tool