Event Policies for Syslogs and Traps

This section describes how to set up Event Policies in Skylar One (formerly SL1) for events with a source of Syslog and Trap messages.

Use the following menu options to navigate the Skylar One 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

Skylar One includes predefined events for the most commonly encountered conditions on the most common platforms. However, if the predefined 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 for syslogs and traps:

Go to Event Policies page (Events > Event Policies).
In the Event Policies page, click the Create Event Policy button. The Event Policy Editor page appears, displaying the Basic tab.
On the Basic tab, define or edit the following fields:

Event Policy Name. Enter a name for the event policy.
Enable Event Policy. This checkbox allows you to enable and disable the event policy.

Configuring Event Source

Event Source. Specifies the source for the event. The fields below this field will change based on your selection. Select one of the following:

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 Skylar One. 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 Message ID. Type the message ID used by syslog to match an event message.
Syslog Process ID. Type the process ID used by syslog to match an event message.
For more information on the syslog fields for events, see https://datatracker.ietf.org/doc/html/rfc5424.

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 Skylar One. 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:

Link-Trap. Manually enter a custom trap object ID (OID) as an alternative to selecting a Link-Trap using the Select Existing 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.
Select Existing Link-Trap. Click this button to display a list of trap OIDs that are included in the management information base (MIB) files that have been compiled in Skylar One. 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.

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.
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 Skylar One, see the section on SNMP Traps.
- If a value is specified in this field, Skylar One 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 Skylar One, the resulting event will be aligned with that device.
- If a value is specified in this field, Skylar One 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 Skylar One, 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, Skylar One 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 Skylar One, 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, Skylar One will align the resulting event with the device that sent the trap.

After selecting and defining your Event Source, enter values in the following fields :

Type of Match. Use this field to select String or Regular Expression.
Match String (Optional). 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. Skylar One's expression matching is case-sensitive. This field is recommended for events generated with a source of Syslog.
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.

Message and Severity

Event Message. The message that appears in the 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.
  
  Skylar One 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, Skylar One 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"). For events with a source of "syslog" or "trap", 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 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 Interface Severity Modifier. If selected, when the event is triggered, Skylar One 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 Interface Severity Modifier checkbox selected, the event will appear in the Event Console with a severity of Minor.

Trigger Frequency And Expiry

Event Auto Expiration. If selected, 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:

Expiration Time Frame. Enter the amount of time before an active event will be cleared automatically if there is no reoccurence.
Unit of Time. Select minutes or hours.

Multiple Matches Required to Trigger Event. If selected, enter the number of alerts and the time in which an event requires multiple triggers to occur in the fields that appear:

Number of Alerts. Enter the number of alerts required to trigger an event within the time frame.
Time Frame. Enter the time frame within which multiple alerts will trigger an event.
Unit of Time. Select minutes or hours.

Event Policy Evaluation Configuration

Detection Weight. If two event definitions are very similar, this field specifies the order in which Skylar One 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).
Multimatch. By default, Skylar One will match a log message or alert to only one event policy. If a log message or alert matches multiple event polices, Skylar One will use the Detection Weight setting to determine which event policy the log message or alert will match. If you select the Multimatch checkbox in all event policies that can match the same log message or alert, Skylar One will generate an event for every event policy that matches that single log message or alert.
Message Match. If Skylar One has generated an event and then a second log message or alert matches the same event policy for the same entity, Skylar One 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.

Suppressions

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 on which it is not suppressed, the event will appear on the Events page and on the Events tab for that device.

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

Configure Suppressions. Click this button to specify the devices or device groups for which to suppress the event. The Select Suppressions window will appear on the Devices tab. Once you have selected the devices or device groups you want to suppress, click the Save button. The Select Suppressions window includes the following tabs:

Devices. To suppress the current event on one or more devices, select those devices from the list.

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

Device Groups. To suppress the current event on all devices in one or more device groups, select those device groups from the list. For information on device groups, see the section on Device Groups.

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

Device groups that have Event/View Suppression enabled will appear in this window. For information on creating device groups, see the section on Creating Device Groups.

Click Save.

After entering information in each tab, click the Save button to save your new event.
Click the Advanced tab. On the Advanced tab, you can define or edit the following fields:

Configurations for External System

Correlate events with an external system. Select this checkbox if you want to correlate the event with an external system. Enter the External ID in the field that appears when this is selected.
Categorize events with an external system. Select this checkbox if you want to categorize this event for an external system. Enter the External Category in the field that appears when this is selected.

Topology Masking

Masking. This option allows you to nest events under parent devices' events if there are parent-child relationships between devices.

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

Select one of the following options:
- Disabled. Topology masking is disabled for this event.
- Mask events on child devices. If this event occurs on a parent device, Skylar One will search all related children devices for masked events.
  - If you have assigned a Category to this event, Skylar One will search all the children devices and mask all events that have been defined as masked and are assigned to the same Category.
  - If you have not assigned a Category to this event, Skylar One will search all children devices and mask all events that have been defined as masked and are not assigned to a Category.
  - 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, Skylar One 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.
  - 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, Skylar One will search all children devices and mask all events that have been defined as maskable and are not assigned to a Category.
  - The maskable events will not appear on the Events page. They will be nested under the parent event.
- Both. If 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.
Choose Category. When you define a hierarchy between events, you can include a Category. A Category allows Skylar One 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 Choose 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.

If you assign a topology category to an event that is neither suppressing nor suppressible, Skylar One does not use the Category. The Category will have no effect.
- If you have assigned a Category to a masked event, Skylar One 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 Skylar One will search all children devices and suppress all events that have been defined as maskable and are not assigned to a Category.

Settings for Device Sub-Entities

Extract sub-entity using a regular expression. Select this checkbox 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, Skylar One 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 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. 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. This field is optional.
- Sub-entity type (y-type). 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 (for example, Interfaces = 7). If Skylar One knows an interface's "yName" (specified in the Identifier Pattern field) and the "yType" (specified in this field), Skylar One 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.
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.

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.

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.

Skylar One 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 Result order for multiple entities 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.

Auto-Clear

Auto-Clear. If enabled, this field specifies that the current event will clear each selected event. Select Auto-Clear, then click the Choose Event Policies button to select one or more events from the list. The Available Event Policies page appears. Select the event policies you want to auto-clear and then click the Select button.
When the current event occurs, Skylar One 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.

Click Save.

After entering information in each tab, click the Save button to save your new event.

Creating a Trap Event Policy in the Classic User Interface

Skylar One 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 Policy Manager page in the classic Skylar One 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 in the classic Skylar One user interface:

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.

Skylar One 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 Skylar One, 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, Skylar One 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 Skylar One. 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, Skylar One examines the OID specified in this field. If the value stored in the OID matches the IP address or hostname of a device in Skylar One, the resulting event will be aligned with that device.

If a value is specified in this field, Skylar One 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 Skylar One, 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, Skylar One 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 Skylar One, 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, Skylar One 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. Skylar One'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 Skylar One 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 Skylar One'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. Skylar One will use this value as the yName of the interface. By identifying the subentity, Skylar One 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. Skylar One's expression matching is case sensitive. For details on the regular expression syntax allowed by Skylar One, 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 Skylar One 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

To create an event definition in the classic Skylar One user interface:

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

Skylar One 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 Skylar One, 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, Skylar One 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 https://datatracker.ietf.org/doc/html/rfc5424 .

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. Skylar One'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 Skylar One 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. Skylar One will use this value as the yName of the interface. By identifying the subentity, Skylar One 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. Skylar One's expression matching is case sensitive. For details on the regular expression syntax allowed by Skylar One, 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.