Overview
Once you’ve configured an EventSource, you can perform test runs to ensure events are being filtered and captured as you intended. EventSource testing can be performed when you’re initially setting up the EventSource—or any time in the future as troubleshooting needs arise.
Note: The EventSource testing feature requires Collector version 28.400 or a higher numbered version.
Testing an EventSource
Testing functionality is available by clicking the Test Event Logging button found in the Filters area of an EventSource’s configurations, as shown next.
Note: The testing of Script EventSources works a bit differently than for other EventSource types. Script EventSources are tested from the Script Event Collector Attributes area of the EventSource and, due to the nature of how scripts operate, the format of test output is different as well.
Depending upon the type of EventSource you are testing, you’ll be prompted for varying test parameters. For Log File EventSources, you’ll need to identify the device, log file path, and the number of lines to scan in the log file. For SNMP Trap and Syslog EventSources, you’ll listen for events as they occur in real time, specifying a sending device and the conditions under which the test will end. For Windows Event Logs, you’ll specify a device and date/time range for which the test should check the logs (up to a 10-minute time period).
Test Results
The test results for Log File, SNMP Trap, Syslog, and Windows Event Log EventSources identify which events would—and would not—be captured based on the test parameters and filters defined for the EventSource.
The test results page displays up to three sections:
- Matched message(s). In this section, messages meeting the test parameters and filters defined in the EventSource configurations will display.
- Filter Statistics. In this section, all filter expressions that resulted in one or more messages being excluded from matching results are displayed, as well as the actual number of messages. Clicking the number of messages hyperlink will open a new window that displays the actual messages filtered (up to 50 per filter rule).
- Unrecognized Message Statistics. Only returned for Syslog EventSources, this section identifies any messages that couldn’t be parsed and therefore couldn’t be classified as meeting or failing to meet filter criteria.
EventSources monitor for the following types of events: IPMI event log events, SNMP traps, Windows event logs, and Syslog events. There are two types of EventSources:
- Templates that define asynchronous messages received by the Collector and used to trigger alerts.
- Templates that define how to collect and monitor textual data. This differs from DataSources, which collect numerical data.
Where to create an EventSource
EventSources are managed from Settings | EventSources. You can add an EventSource to your account using one of three methods:
- Importing an EventSource from LogicMonitor’s repository (Add | From LogicMonitor repository)
- Importing an EventSource from XML (see Importing/Exporting XML LogicModules for more details)
- Configuring a Brand New EventSource (discussed next)
Configuring a New EventSource
You can add a new EventSource from Settings | EventSources | Add | EventSource. There are three categories of settings that must be established in order to configure a new EventSource:
- General Information
- Collector Attributes
- Alert Settings
The settings in these three categories collectively determine the type of EventSource, which devices the EventSource will be applied to, and the conditions that must exist in order for the EventSource to trigger an alert.
General Information
In the General Information area of an EventSource’s configurations, complete the basic settings for your new EventSource. These settings are global across all types of EventSources.
Name and Description
Enter a name and description for your EventSource in the Name and Description fields
Technical Notes
Enter technical notes associated with this EventSource into the Technical Notes field. These notes can include an overview of the EventSource purpose, filters, and so on.
Applies To
The Applies To field accepts LogicMonitor’s AppliesTo scripting as input to determine which resources will be associated with this EventSource. For detailed information on using this field (including its wizard and test functionality), along with an overview of the AppliesTo scripting syntax, see AppliesTo Scripting Overview.
Type
There are up to 10 types of EventSources available from the Type field’s dropdown menu, but only five of these should ever be created as custom EventSources: Log File, SNMP Trap, SysLog, Windows Event Logging, and Script. (The other five support LM Cloud and are used for monitoring the status pages of public cloud providers. These EventSources are pre-built for the various public cloud providers and LogicMonitor does not recommend creating custom EventSources for this purpose.)
Depending upon the EventSource you are creating (defined by the Type field), you will see variations in the configurations that must be established, notably in the Collector Attributes and Filters configuration areas, which are discussed in the following sections.
Note: You cannot edit the Type of an EventSource once it has been saved.
Group
In the Group field, select the EventSource group to which this EventSource will be assigned. If no group is specified, the EventSource will be placed in the default “@ungrouped” group. If you specify a group name that doesn’t exist, that group will be created.
Collector Attributes
Collector attributes are only required for Log File and Script EventSources. These attributes exist to provide additional detail on how custom events will be accessed. See Log File Monitoring and Script EventSources respectively for more information on setting Collector attributes.
Filters
If you add filters, events must meet the filter criteria in order to be detected and alerted on. Available filtering options will change depending on your EventSource type; see the support article dedicated to the EventSource type you are creating for more details on filtering events.
LogicMonitor supports IN filters for EventSources, which allow you to include a list of individual events (e.g. IN 1 | 3 | 23). We also include an equivalent operator NOT IN for excluding a specific set of events (e.g. NOT IN 2 | 34 | 25).
As you’re defining filters, you can use the Test Event Logging button to perform test runs of your Log File, SNMP Trap, Syslog, and Windows Event Log EventSources to ensure events are being filtered and captured as you intended. You can also use the testing capability before any filters are defined in order to return all messages from a device and use this information to determine the parameter values that should be filtered on. This test feature requires Collector version 28.400 or a higher numbered version. See Testing EventSources for more information on testing EventSources.
Alert Settings
If you are creating a Script, SNMP Trap, or Windows Event Log EventSource, the first field you see here is one related to the level/severity of alert that is triggered. These fields are unique to your EventSource type; see the support article dedicated to the EventSource type you are creating for more details on setting alert level.
Regardless of EventSource type, the Clear After, Alert Subject, and Alert Message fields, discussed next, are always present in the Alert Settings area.
Clear After
The Clear After field allows you to define, in minutes, how long an alert triggered for this EventSource will remain active before it auto clears. By default, LogicMonitor sets this interval to 60 minutes, but you can reduce it (down to a minimum of five minutes) if desired. Checking the Acknowledgement option immediately below the Clear After field allows you to manually clear the EventSource alert once it is acknowledged.
Note: Like alerts triggered by datapoints, alert clear notifications can be sent when an EventSource alert clears. For alert clear notifications to be sent, the Send notification when alerts clear option must be checked in the governing alert rule, as discussed in Alert Rules.
LogicMonitor automatically suppresses some duplicate EventSource alerts received within the time range identified by the Clear After field. This is intended to streamline your experience and prevent you from being continuously alerted to the same event. Whether LogicMonitor suppresses duplicate alerts depends upon the type of EventSource:
- Log File. Duplicate alerts for Log File EventSources are suppressed for the duration of the interval set in the Clear After field.
- SNMP Trap. Duplicate alerts for SNMP Trap EventSources are never suppressed.
- Syslog. Duplicate alerts for Syslog EventSources (deemed duplicate if host, application name, and message are identical) are suppressed for the duration of the interval set in the Clear After field.
- Windows Event Log. Duplicate alerts for Windows Event Log EventSources (deemed duplicate if the host and EventID are identical—even if the messages are different) are suppressed for the duration of the interval set in the Clear After field.
Note: You can override this behavior by unchecking the Suppress duplicate EventIDs even when messages differ option, as discussed in Windows Event Log Monitoring.
- Script. The suppression of duplicate alerts for Script EventSources is controlled by the alerts per host. If alerts are suppressed, you should see Collector events on the collector such as “SEC: reaches threshold for.”
Note: If you are seeing too many duplicate alerts for Log File, Syslog, or Windows Event Log EventSources, consider lengthening the time of the Clear After interval.
Alert Subject and Message
Filling out one or both of these fields will override the default EventSource alert notification subject and/or message (as established in the alert message template) for this particular EventSource. You can choose to customize the alert subject or message using tokens, as discussed in Tokens Available in LogicModule Alert Messages.
Note: EventSource alerts automatically display in the LogicMonitor interface, but alert notification via email, text, or other method must be configured through alert rules, as discussed in Alert Rules.
