Event Policies for Syslogs and Traps

This section describes how to set up Event Policies for events with a source of Syslog and Trap messages.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

Creating Event Policies for Syslogs and Traps

SL1 includes pre-defined events for the most commonly encountered conditions on the most common platforms. However, if the pre-defined events do not meet the needs of your organization, you can define new events that better suit your needs.

From the Event Policies page, you can define a new event. You can define custom events to meet your business requirements. You can also define events to be triggered by any custom Dynamic Application alerts you have created.

To create an event definition:

Go to Event Policies page (Events > Event Policies, or Registry > Events > Event Manager in the classic SL1 user interface).
Click the Create Event Policy button. The Event Policy Editor page appears.

In the Event Policy Editor page and set of tabs, you can define a new event. The Event Policy Editor pages contains the following fields and tabs:

Policy Name. Enter a name for the event policy.
Enable Event Policy. This toggle allows you to enable and disable the event policy.
Policy Description. Enter a description of the event policy.
Match Logic. Allows you to define pattern-matching for the event.
Event Message. Allows you to enter an event message and the severity of the event, as well as event masking.
Suppression. Allows you to suppress the event on selected devices and device groups.

Enabling a discovered device configured with CDP or LLDP topology in SL1 will cause the device to provide information on its neighbor. This information only identifies that there is a neighbor device, not which is the parent or the child. This may cause the parent-child relationship to switch which requires you to manually reverse the issue within the SL1 user interface. SL1 allows you to manually build parent-child relationships between specific device categories. For more information, see Defining Parent and Child Devices.

The Match Logic Tab

In the Match Logic tab, you can define or edit the following fields when creating event policies for Syslog or Trap messages:

Event Source. Specifies the source for the event. The fields below this field will change based on your selection. When defining an event policy for syslog or trap messages, your options are:

Syslog. Message is generated by the syslog protocol. Syslogs can be sent by devices and proxy devices such as managers of managers (MoM). A syslog is an unsolicited message from a device to SL1. Syslog is a standard log format supported by most networking and UNIX-based devices and applications. Windows log files can be converted to syslog format using conversion tools. For more information on syslogs, see the section on syslog messages. The following fields will appear:

Syslog Facility. Select the facility information used by syslog to match an event message.
Syslog Severity. Select the severity information used by syslog to match an event message.
Syslog Application Name. Type the application name used by syslog to match an event message.
Syslog Process ID. Type the Process ID used by syslog to match an event message.
Syslog Message ID. Type the Message ID used by syslog to match an event message.
NOTE: For more information on the syslog fields for events, see .http://www.rfc-archive.org/getrfc.php?rfc=5424 .

Trap. Message is generated by an SNMP trap. SNMP traps can be sent by devices and proxy devices like MoMs. An SNMP trap is an unsolicited message from a device to SL1. A trap indicates that an emergency condition or a condition that merits immediate attention has occurred on the device. For more information on traps, see the section on SNMP traps. The following options will appear:

Select Link-Trap. Click this button to display a list of trap OIDs that are included in the MIB files that have been compiled in SL1. Select one of the listed trap OIDs to associate with the event. The Link-Trap window will appear with a list of traps to select from. After you have selected a trap, click the Select button.

You can use the field at the top of the Link-Trap field to filter the list of SNMP traps. If you type an alpha-numeric string in the field, the Link-Trap field will include only traps that match the string.

NOTE: Before selecting a trap OID, check the SNMP Trap Filters page (Evnts > SNMP Trap Filters, or Registry > Events > SNMP Trap Filters in the classic SL1 user interface) to be sure that the trap is not being filtered out. For more information on the SNMP Trap Filters page, see the Filtering Traps section.

Link-Trap. Manually enter a custom trap OID as an alternative to selecting a Link-Trap using the Select Link-Trap button. You can use an asterisk (*) as a wildcard character at the end of the trap OID. If you add the wildcard character to the end of the trap OID, the event policy will match all trap OIDs that start with the specified OID string. This is useful for creating "catch all" event policies.
Source Host Varbind. For events with a source of "trap", specifies an OID that is included in the trap. This OID will contain either the IP address or hostname to align with the event. This field allows you to align an event with a device other than the trap's sender. For more information about traps in SL1, see the section on SNMP traps.

If a value is specified in this field, SL1 examines the OID specified in this field. If the value stored in the OID matches the primary IP address or hostname of a device in SL1, the resulting event will be aligned with that device.
If a value is specified in this field, SL1 examines the OID specified in this field. If the value stored in the OID does not match a primary IP address or hostname of a device in SL1, the resulting event will be aligned with the device that sent the trap.
If no value is specified in this field, but the trap includes the default snmpTrapAddress OID, SL1 will examine the value stored in the snmpTrapAddress OID. If the value stored in the default snmpTrapAddress OID matches the primary IP address or hostname of a device in SL1, the resulting event will be aligned with that device.
If no value is specified in this field and the trap does not include the snmpTrapAddress OID, SL1 will align the resulting event with the device that sent the trap.

After selecting and defining your Event Source, enter values in the fields on the right side of the Match Logic tab:

String/Regular Expression. Use this drop-down to select String or Regular Expression.
Match String. A string used to correlate the event with a log message. Can be up to 512 characters in length. To match this event policy, the text of a log message or alert must match the value you enter in this field. Can be any combination of alpha-numeric and multi-byte characters. SL1's expression matching is case-sensitive. This field is required for events generated with a source of Syslog, API, and Email.
Second Match String (Optional). A secondary string used to match against the originating log message. Can be up to 512 characters in length. Can be any combination of alpha-numeric and multi-byte characters. To match this event policy, the text of a log message or alert must match the value you enter in this field and the value you entered in the Match String field. This field is optional.
Allow event to expire if it doesn't reoccur within a time frame. If toggled on, enter the time in which an active event will be cleared automatically if there is no reoccurrence of the event in the fields that appear. You can enter time in minutes or hours.
Require multiple triggers within a time frame. If toggled on, enter the number of events and the time in which an event requires multiple triggers to occur in the fields that appear. You can enter time in minutes or hours.
Detection Weight. If two event definitions are very similar, the weight field specifies the order in which SL1 should match messages against the similar event definitions. The event definition with the lowest weight will be matched first. This field is most useful for events that use expression matching. Options range from 0 (first) - 20 (last).
Multi Match. By default, SL1 will match a log message or alert to only one event policy. If a log message or alert matches multiple event polices, SL1 will use the Detection Weight setting to determine which event policy the log message or alert will match. If you select the Multi Match checkbox in all event policies that can match the same log message or alert, SL1 will generate an event for every event policy that matches that single log message or alert.
Message Match. If SL1 has generated an event and then a second log message or alert matches the same event policy for the same entity, SL1 will not generate a second event, but will increase the count value for the original event on the Events page and in the Viewing Events page. By default, this behavior occurs regardless of whether the two log messages or alerts contain the same message. If you select the Message Match checkbox, this behavior will occur only if the log messages or alerts contain the same message.

The Event Message Tab

In the Event Message tab, you can define or edit the following fields:

Event Message. The message that appears in the Event Console page or the Viewing Events page when this event occurs. This field defaults to "%M" for new event policies upon creation. The message can be any combination of alphanumeric and multi-byte characters. Variables include the characters "%" (percent) and "|" (bar). You can also use regular expressions and variables that represent text from the original log message to create the Event Message:

To include regular expressions in the Event Message:

Surround the regular expression with %R and %/R. For example:

%RFilename: .*? %/R

This example would search for the first instance of the string "Filename: " (Filename-colon-space) followed by any number of any characters up to the line break. The %R indicates the beginning of a regular expression. The %/R indicates the end of a regular expression.

SL1 will use the regular expression to search the log message and use the matching text in the event message.

For details on regular expression syntax, see the documentation at http://www.python.org.

NOTE: If an event policy with a source of "Email" or "Trap" includes a poorly formed regular expression in the event message, SL1 will stop evaluating the event after 10 seconds and will generate a system event with a severity of Minor, alerting you to the issue.

You can also use the following variables in this field:

%I (capital "eye"). Depending on the context, this variable contains one of the following:

For events with a source of "dynamic", this variable contains the index value from SNMP; this index value will be displayed in the Event Message. For Dynamic Applications, %I maps to the raw index that comes back from SNMP. For example, a walk of the MIB at .1.3.6.1.4.1.999.3.2.1 might return the following OIDs, in which case %I would return .1.1, .2.1, and .3.1, respectively:

1.3.6.1.4.1.999.3.2.1.1.1

1.3.6.1.4.1.999.3.2.1.2.1,

1.3.6.1.4.1.999.3.2.1.3.1.

For events with a source of "syslog" or "trap", this variable contains the value that matches the Identifier Pattern field in the Advanced tab.
For events with a source of "internal", this variable contains the "yName" (sub-entity name) value that matches the Identifier Pattern field in the Advanced tab.

%M. The full text of the log message that triggered the event will be displayed in Event Message field.
%V. Data Value from log file will be displayed in the Event Message field.
%T. Threshold value from the log file will be displayed in Event Message field.

NOTE: Events with a Source of Rules Engine contain the variable %_event_detail_uri. This variable resolves to the URL of the incident and provides ScienceLogic users with more details about the event.

Event Severity. Defines the severity of the event. Choices are:

Healthy. Healthy events indicate that a device or condition has returned to a healthy state. Frequently, a healthy event is generated after a problem has been fixed.

Notice. Notice events indicate a condition that does not affect service but about which users should be aware.
Minor. Minor events indicate a condition that does not currently impair service, but the condition needs to be corrected before it becomes more severe.
Major. Major events indicate a condition that impacts service and requires immediate investigation.
Critical. Critical events indicate a condition that can seriously impair or curtail service and requires immediate attention (i.e., service or system outages).

Use Modifier. If selected, when the event is triggered, SL1 will check to see if the interface associated with this event has a custom severity modifier. If so, the event will appear in the Event Console with that custom severity modifier applied to the severity in the Event Severity field. For example, if an interface with an Event Severity Adjust setting of Sev -1 triggers an event with an Event Severity of Major and that event has the Use Modifier checkbox selected, the event will appear in the Event Console with a severity of Minor.
Correlate this event with external system. Toggle this on if you want to correlate the event with an external system. Enter the External ID in the field that appears when this is turned on.
Categorize event for external system. Toggle this on if you want to categorize this event for an external system. Enter the External Category in the field that appears when this is turned on.
Extract sub-entity using a regular expression. Toggle this on if you want to extract a sub-entity using a regular expression. Enter values in the following fields that appear when this is turned on:

Identifier pattern. A regular expression used to extract the name of a sub-entity (like the name of a network interface ) from within the log entry. By identifying the sub-entity, SL1 can create a unique event for each sub-entity, instead of a single event for the entire device. For an event to auto-clear another event, both events must have the same sub-entity name. The regular expression can be up to 512 characters in length and can include multi-byte characters.
Result order for multiple sub-entities. If the Identifier Pattern field returns multiple results, users can specify which results to use and in which order. Each result is represented by a variable. This field is optional. For example, users could specify "%2:%1" for "Interface %2: Peer %1" where %1 is the first match with identifier pattern and %2 is the second match with identifier pattern.
Y-type to override. Specifies a sub-entity type (yType). A sub-entity is a hardware component (CPU, disk, interface, etc). The "yType" value is stored as an integer in a database table; each sub-entity type is associated with a unique integer value (e.g. Interfaces = 7). If SL1 knows an interface's "yName" (specified in the Identifier Pattern field) and the "yType" (specified in the Override YType field), SL1 can determine the unique "yID" for the interface. The "yID" is stored in the table in which all instances of a specific sub-entity are stored. For example, for "yType" of "interface," the "yID" is a unique numeric ID for a specific interface on a specific device. This "yID" is stored in the table of all discovered interfaces (if_id in master_dev.device_interfaces) and is unique within this table.

NOTE: If you used the previous three fields to associate an event with an interface, then on the Events page, the link icon for this event will be for an interface and will lead to a performance report for the specific interface.

NOTE: The %Y variable (yName) and %y variable (yID) can be used in policies associated with events that use the previous three fields. That is, Run Book Action Policies and related Ticket Templates that are triggered by the event can use the %Y variable and the %y variable. For details on Run Book Actions Policies and using Ticket Templates, see the section on Creating an Action Policy that Creates a New Ticket.

NOTE: For events generated by Dynamic Application alerts, the %Y variable value is pre-populated with a unique index value that is used to ensure that events roll up correctly. If an event policy does not specifically override the %Y variable, this variable will be populated with the "yName" (sub-entity name) value, which is taken from an index value that might not be human-readable.

SL1 populates the "yName" (sub-entity name) value in varying ways based on the event source.

For example, for events generated by Dynamic Application alerts, the yName is typically pulled from the event message using the Identifier Pattern and Identifier Format that are defined in the event policy.

Meanwhile, for internal events, the yName is determined by the process that creates the alert, based on which element reported the condition. So, for instance, if a filesystem exceeds a particular threshold, the yName is the filesystem identifier.

Autoclear. If enabled, this field specifies that the current event will clear each selected event. Click the Add Event Policy button to select one or more events from the list. When the current event occurs, SL1 automatically removes each selected events event from the Events page.
For example, suppose you have a "Device not responding to ping" event. If the next polling session produces the "Device now responding normally to ping " event, the auto-clear feature could automatically clear the original event from the Events page.
Topology Masking.

Mask events on child devices. If this event occurs on a parent device, SL1 will search all related children devices for masked events.

If you have assigned a Category to this event, SL1 will search all the children devices and mask all events that have been defined as masked and are assigned to the same Category. For more details on event categories, see the section on event correlation.
If you have not assigned a Category to this event, SL1 will search all children devices and mask all events that have been defined as masked and are not assigned to a Category. For more details on event categories, see the section on event correlation.
The masked events will not appear on the Events page. They will be nested under the parent event.

Maskable under a parent device's event. This type of event is masked on a child device only when a maskable event occurs on the parent device.

If you have assigned a Category to this event, SL1 will mask this event when it occurs on a child device and an event that has been defined as masked occurs on its parent device. The masked event must have the same Category as the maskable event. For more details on event categories, see the section on event correlation.
If you have not assigned a Category to this event, when a masked event that is not assigned to a Category occurs on the parent device SL1 will search all children devices and mask all events that have been defined as maskable and are not assigned to a Category. For more details on event categories, see the section on event correlation.
The maskable events will not appear on the Events page. They will be nested under the parent event.

If both Mask events on child devices and Maskable under a parent device's event are selected, then if this event occurs on a parent device, it behaves as a masked event. If this event occurs on a child device, it behaves as a maskable event.

Add Category. When you define a hierarchy between events, you can include a Category. A Category allows SL1 to more efficiently align masked events with maskable events. When you align an event category to a masked or maskable event, that event will be correlated with only events that are aligned with the same category. An event can be aligned to multiple categories; for event correlation to occur, the masked event and the maskable event must both be aligned with a common category.
Click the Add Category button to open the Available Categories window and select the categories you want to add. For more details on event categories, see the section on event correlation.

NOTE: If you assign a topology category to an event that is neither suppressing nor suppressible, SL1 does not use the Category. The Category will have no effect.

If you have assigned a Category to a masked event, SL1 will search all the children devices and suppress all events that have been defined as maskable and are assigned to the same Category.
If you have not assigned a Category to a masked event, when the event occurs on the parent device SL1 will search all children devices and suppress all events that have been defined as maskable and are not assigned to a Category.

The Suppression Tab

On the Suppression tab, you can suppress the event on selected devices or all devices in selected device groups. When you suppress an event, you are specifying that, in the future, if this event occurs again on a specific device, the event will not appear on the Events tab for the device.

A manually suppressed event is suppressed only for the selected devices and devices in the selected device groups. If the event occurs on another device, the event will appear on the Events page.

NOTE: If you want to disable an event for all devices, see the section on disabling an event.

On the Suppressions tab, you can define or edit the following:

Devices. Devices on which you can suppress the current event. To suppress the current event on a device , click the Select Devices button and select one or more devices from the Available Devices window. The device(s) should now appear in a list under Devices. To remove a device from the list, click the Close icon () next to the device name in the list.

You can use the box at the top of the Available Devices field to filter the list of devices. You can enter an alpha-numeric string in the box, and the Available Devices field will include only devices that match the string.

Device Groups. Device groups on which you can suppress the current event. To suppress the current event on all devices in a device group, click the Select Device Groups button and select one or more device groups from the Available Device Groups window. The device group(s) should now appear in the list under Device Groups. To remove a device group from the list, click the Close icon () next to the device group in the list. For information on device groups, see the section on device groups.

You can use the box at the top of the Available Device Groups field to filter the list of device groups. You can enter an alpha-numeric string in the box, and the Available Device Groups field will include only device groups that match the string.

NOTE: Device groups that have Event/View Suppression enabled will appear in this field. For information on creating device groups, see the section on creating device groups.

Creating a Trap Event Policy in the Classic User Interface

From the Event Policy Manager page in the classic SL1 user interface, you can define a new event. You can define custom events to meet your business requirements. You can also define events to be triggered by any custom Dynamic Application alerts you have created.

To create an event definition:

Go to the Event Policy Manager page (Registry > Events > Event Manager).
In the Event Policy Manager page, click the Create button. The Event Policy Editor page appears.
In the Event Policy Editor page and set of tabs, you can define a new event. The Event Policy Editor page contains three tabs:

Policy. Allows you to define basic parameters for the event. This tab is described in the following section.
Advanced. Allows you to define pattern-matching for the event and also define event roll-ups and suppressions.
Suppressions. Allows you to suppress the event on selected devices. When you suppress an event, you are specifying that, in the future, if this event occurs again on a specific device, the event will not appear in the Event Console page or the Viewing Events page for the device.

Supply values in the following fields:

Event Source. Select Trap.

Policy Name. The name of the event. Can be any combination of alphanumeric characters, up to 48 characters in length.
Operational State. Specifies whether event is to be operational or not. Choices are Enabled or Disabled.

Event Message. The message that appears in the Event Console page or the Viewing Events page when this event occurs. Can be any combination of alphanumeric characters. Variables include the characters "%" (percent) and "|" (bar). You can also use regular expressions and variables that represent text from the original log message to create the Event Message:

To include regular expressions in the Event Message:

Surround the regular expression with %R and %/R. For example:

%RFilename: .*? %/R

Would search for the first instance of the string "Filename: " (Filename-colon-space) followed by any number of any characters up to the line break. The %R indicates the beginning of a regular expression. The %/R indicates the end of a regular expression.

SL1 will use the regular expression to search the log message and use the matching text in the event message.

For details on the regular expression syntax allowed by SL1, see http://www.python.org/doc/howto/.

You can also use the following variables in this field:

%I ("eye").This variable contains the value that matches the Identifier Pattern field in the Advanced tab.

%M. The full text of the log message that triggered the event will be displayed in Event Message field.
%V. Data Value from log file will be displayed in the Event Message field.
%T. Threshold value from the log file will be displayed in Event Message field.

Event Severity. Defines the severity of the event. Choices are:

Healthy. Healthy Events indicate that a device or condition has returned to a healthy state. Frequently, a healthy event is generated after a problem has been fixed.

Notice. Notice Events indicate a condition that does not affect service but about which users should be aware.
Minor. Minor Events indicate a condition that does not currently impair service, but the condition needs to be corrected before it becomes more severe.
Major. Major Events indicate a condition that is service impacting and requires immediate investigation.
Critical. Critical Events indicate a condition that can seriously impair or curtail service and require immediate attention (i.e. service or system outages).

Use Modifier. If selected, when the event is triggered, SL1 will check to see if the interface associated with this event has a custom severity modifier. If so, the event will appear in the Event Console with that custom severity modifier applied to the severity in the Event Severity field. For example, if an interface with an Event Severity Adjust setting of Sev -1 triggers an event with an Event Severity of Major and that event has the Use Modifier checkbox selected, the event will appear in the Event Console with a severity of Minor.
Policy Description. Text that explains what the event means and what possible causes are.

Defining Pattern Matching and Advanced Behavior

The Advanced tab in the Event Policy Editor page allows you to define or edit pattern-matching for the trap event and also define event roll-ups and suppressions. In the Advanced tab, you can define or edit the following fields that pertain to traps:

Link-Trap. For events with a source of Trap, displays a list of trap OIDs that are included in the MIB files that have been compiled in SL1. You can either select one of the listed trap OIDs to associate with the event or manually enter a custom trap OID. You can use an asterisk (*) as a wildcard character at the end of the trap OID. If you add the wildcard character to the end of the trap OID, the event policy will match all trap OIDs that start with the specified OID string. This is useful for creating "catch all" event policies.

Source Host Varbind. For events with a source of Trap, specifies an OID that is included in the trap. This OID will contain the IP address or hostname to align with the event.

If a value is specified in this field, SL1 examines the OID specified in this field. If the value stored in the OID matches the IP address or hostname of a device in SL1, the resulting event will be aligned with that device.

If a value is specified in this field, SL1 examines the OID specified in this field. If the value stored in the OID does not match the IP address or hostname of a device in SL1, the resulting event will be aligned with the device that sent the trap.
If no value is specified in this field, but the trap includes the default snmpTrapAddress OID, SL1 will examine the value stored in the snmpTrapAddress OID. If the value stored in the OID matches the IP address or hostname of a device in SL1, the resulting event will be aligned with that device.
If no value is specified in this field and the trap does not include the snmpTrapAddress OID, SL1 will align the resulting event with the device that sent the trap.

First Match String. A string used to correlate the event with a log message. To match this event policy, the text of a log message or alert must match the value you enter in this field. Can be any combination of alphanumeric characters. SL1's expression matching is case sensitive. This field is required for events generated with a source of Syslog, Security, 3rd Party, and Email.
Second Match String. A secondary string used to match against the originating log message. To match this event policy, the text of a log message or alert must match the value you enter in this field and the value you entered in the First Match String field. This field is optional.

NOTE: The Match Logic field specifies whether SL1 should process First Match String and Second Match String as simple text matches or as regular expressions.

NOTE: You can define an event so that it is triggered only when it occurs on a specific interface. You can then include the interface name and SL1's unique interface ID for the interface in the event message. When defining an event, you can use the following three fields below to associate an event with an interface.

Identifier Pattern. A regular expression used to extract the specific subentity (like the name of a network interface) within the log entry. SL1 will use this value as the yName of the interface. By identifying the subentity, SL1 can create a unique event for each subentity, instead of a single event for the entire device. For example, a log message indicating a link has gone down may include the network interface name. So this field could extract the network interface name from the log message. SL1's expression matching is case sensitive. For details on the regular expression syntax allowed by SL1, see http://www.python.org/doc/howto.

Identifier Format. If the Identifier Pattern field returns multiple results, users can specify which results to use and in which order. Each result is represented by a variable. This field is optional.

%1. First match with identifier pattern. This is the default behavior if no value is supplied in the Identifier Format field.

%2. Second match with identifier pattern.
For example, users could specify "%2:%1" for "Interface %2: Peer %1".

Select the Save button to save your settings when you have finished editing the fields pertaining to your trap event policy.

For more information on the remaining fields, as well as the Suppressions tab, see the Events manual.

Example Trap Event Policy in the Classic User Interface

Trap messages are sent from devices to SL1 in order to notify the platform of any issues or important events occurring on the device.

To create a Trap Event Policy:

Go to the Event Policy Manager page (Registry > Events > Event Manager).
Select the Create button, and the Event Policy Editor page will appear.
In the Event Policy Editor page, enter these values in the following fields:

Event Source. We selected Trap.
Operational State. We selected Enabled.
Event Severity. We selected Notice.
Policy Name. We entered "Example Trap Policy".
Event Message. We entered "%M".
Policy Description. We entered "Device Battery Low."

Select the Save button.
After saving those settings, select the Advanced tab. We entered the following values in the following fields:

Link-Trap. We entered the device's trap oid of "1.3.6.1.6.3.1.1.5.7".

We left the rest of the fields at their default settings, and then selected the Save button.
When the device's battery is low, it will send the trap message and trigger an event, which appears in the Event Console. Clicking on the graph icon () will bring up the Device Summary page for the device for which the event occurred. Clicking on the life ring icon () will create a ticket for the event.
Clicking on the graph icon () will bring up the Device Summary page. You will see the event listed in the Device Summary page, and you can click on the event to view the Event Summary modal page.
You can also select the Logs tab from the Device Summary page to view the Device Logs & Messages page. The trap message will appear in the device logs, and you can select the View Events icon () which will take you to the Viewing Active Events page for that device.
From the Viewing Active Events page, you can select the information icon () to view the Event Information modal page, filter the device's events based on event type, or view graphical reports about that device's events based on type.

Creating a Syslog Event Policy in the Classic User Interface

From the Event Policies page (or the Event Policy Manager page in the classic SL1 user interface), you can define a new event. You can define custom events to meet your business requirements. You can also define events to be triggered by any custom Dynamic Application alerts you have created.

To create an event definition:

Go to Event Policy Manager page (Registry > Events > Event Manager).

In the Event Policy Manager page, click the Create button. The Event Policy Editor page appears.

In the Event Policy Editor page and set of tabs, you can define a new event. The Event Policy Editor page contains three tabs:

Policy. Allows you to define basic parameters for the event. This tab is described in the following section.

Advanced. Allows you to define pattern-matching for the event and also define event roll-ups and suppressions.
Suppressions. Allows you to suppress the event on selected devices. When you suppress an event, you are specifying that, in the future, if this event occurs again on a specific device, the event will not appear in the Event Console page or the Viewing Events page for the device.

Supply values in the following fields:

Event Source. Select Syslog.

Policy Name. The name of the event. Can be any combination of alphanumeric characters, up to 48 characters in length.
Operational State. Specifies whether event is to be operational or not. Choices are Enabled or Disabled.

Event Message. The message that appears in the Event Console page or the Viewing Events page when this event occurs. Can be any combination of alphanumeric characters. Variables include the characters "%" (percent) and "|" (bar). You can also use regular expressions and variables that represent text from the original log message to create the Event Message:

To include regular expressions in the Event Message:

Surround the regular expression with %R and %/R. For example:

%RFilename: .*? %/R

SL1 will use the regular expression to search the log message and use the matching text in the event message.

For details on the regular expression syntax allowed by SL1, see http://www.python.org/doc/howto/.

You can also use the following variables in this field:

%I ("eye").This variable contains the value that matches the Identifier Pattern field in the Advanced tab.
%M. The full text of the log message that triggered the event will be displayed in Event Message field.
%V. Data Value from log file will be displayed in the Event Message field.
%T. Threshold value from the log file will be displayed in Event Message field.

Event Severity. Defines the severity of the event. Choices are:

Healthy. Healthy Events indicate that a device or condition has returned to a healthy state. Frequently, a healthy event is generated after a problem has been fixed.
Notice. Notice Events indicate a condition that does not affect service but about which users should be aware.
Minor. Minor Events indicate a condition that does not currently impair service, but the condition needs to be corrected before it becomes more severe.
Major. Major Events indicate a condition that is service impacting and requires immediate investigation.
Critical. Critical Events indicate a condition that can seriously impair or curtail service and require immediate attention (i.e. service or system outages).

Use Modifier. If selected, when the event is triggered, SL1 will check to see if the interface associated with this event has a custom severity modifier. If so, the event will appear in the Event Console with that custom severity modifier applied to the severity in the Event Severity field. For example, if an interface with an Event Severity Adjust setting of Sev -1 triggers an event with an Event Severity of Major and that event has the Use Modifier checkbox selected, the event will appear in the Event Console with a severity of Minor.
Policy Description. Text that explains what the event means and what possible causes are.

Defining Pattern Matching and Advanced Behavior

The Advanced tab in the Event Policy Editor page allows you to define or edit pattern-matching for the syslog event and also define event roll-ups and suppressions. In the Advanced tab, you can define or edit the following fields that pertain to syslogs:

Syslog Facility. Facility information used by syslog to match an event message.
Syslog Severity. Severity information used by syslog to match an event message.
Syslog Application Name. Application Name used by syslog to match an event message.
Syslog Process ID. Process ID used by syslog to match an event message.
Syslog Message ID. Message ID used by syslog to match an event message.

NOTE: For more information on the syslog fields for events, see http://www.rfc-archive.org/getrfc.php?rfc=5424 .

First Match String. A string used to correlate the event with a log message. To match this event policy, the text of a log message or alert must match the value you enter in this field. Can be any combination of alphanumeric characters. SL1's expression matching is case sensitive. This field is required for events generated with a source of Syslog, Security, 3rd Party, and Email.
Second Match String. A secondary string used to match against the originating log message. To match this event policy, the text of a log message or alert must match the value you enter in this field and the value you entered in the First Match String field. This field is optional.

NOTE: The Match Logic field specifies whether SL1 should process First Match String and Second Match String as simple text matches or as regular expressions.

Identifier Pattern. A regular expression used to extract the specific subentity (like the name of a network interface) within the log entry. SL1 will use this value as the yName of the interface. By identifying the subentity, SL1 can create a unique event for each subentity, instead of a single event for the entire device. For example, a log message indicating a link has gone down may include the network interface name. So this field could extract the network interface name from the log message. SL1's expression matching is case sensitive. For details on the regular expression syntax allowed by SL1, see http://www.python.org/doc/howto.
Identifier Format. If the Identifier Pattern field returns multiple results, users can specify which results to use and in which order. Each result is represented by a variable. This field is optional.

%1. First match with identifier pattern. This is the default behavior if no value is supplied in the Identifier Format field.
%2. Second match with identifier pattern.
For example, users could specify "%2:%1" for "Interface %2: Peer %1".

Select the Save button to save your settings when you have finished editing the fields pertaining to your syslog event policy.

For more information on the remaining fields, as well as the Suppressions tab, see the Events manual.

Example Syslog Event Policy in the Classic User Interface

This section will walk through the steps of creating an event policy for syslogs. We will be creating a policy that will send a syslog message when the device's disk space has reached 100% capacity.

To create a Syslog Event Policy:

Go to the Event Policy Manager page (Registry > Events > Event Manager).
Select the Create button, and the Event Policy Editor page will appear.
In the Event Policy Editor page, enter these values in the following fields:

Event Source. We selected Syslog.
Operational State. We selected Enabled.
Event Severity. We selected Notice.
Policy Name. We entered "Example Syslog Policy".
Event Message. We entered "%M".
Policy Description. We entered "Definition: Disk space has reached 100%."

Select the Save button.
After saving those settings, select the Advanced tab. We entered the following values in the following fields:

Syslog Facility. We selected Match Any.
Syslog Severity. We selected Match Any.
First Match String. We entered "Disk space 100%%".

We left the rest of the fields at their default settings, and then selected the Save button.
When the device reaches 100% capacity, it will trigger an event, which appears in the Event Console. Clicking on the graph icon () will bring up the Device Summary page for the device for which the event occurred. Clicking on the life ring icon () will create a ticket for the event.
Clicking on the graph icon () will bring up the Device Summary page. You will see the event listed in the Device Summary page, and you can click on the event to view the Event Summary modal page.
You can also select the Logs tab from the Device Summary page to view the Device Logs & Messages page. The syslog message will appear in the device logs, and you can select the View Events icon () which will take you to the Viewing Active Events page for that device.
From the Viewing Active Events page, you can select the information icon () to view the Event Information modal page, filter the device's events based on event type, or view graphical reports about that device's events based on type.