Event Policies for Syslogs and Traps

Download this manual as a PDF file

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 a Trap Event Policy

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 (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:

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

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

  1. 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.

  1. 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

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:

  1. Go to the Event Policy Manager page (Registry > Events > Event Manager).
  2. Select the Create button, and the Event Policy Editor page will appear.
  3. 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."
  1. Select the Save button.
  2. 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".
  1. We left the rest of the fields at their default settings, and then selected the Save button.

  1. 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.

  1. 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.

  1. 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.

  1. 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

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 (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:

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

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

  1. 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

    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 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.

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 syslog event policy.

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

Example Syslog Event Policy

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:

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

  1. Select the Create button, and the Event Policy Editor page will appear.

  1. 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%."
  1. Select the Save button.

  1. 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%%".
  1. We left the rest of the fields at their default settings, and then selected the Save button.

  1. 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.

  1. 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.

  1. 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.

  1. 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.