6.6.1 Event definitions

After the SNMP MIB has been uploaded for the trap, or if the event is Syslog based, the next step is the event definition configuration. The configuration page can be accessed from the Settings=>Thresholds=>Event definition menu. It is important to note that PVSR although supports SNMPv1, SNMPv2c and SNMPv3 traps, it doesn’t support authPriv SNMPv3 traps, only noAuthNoPriv and authNoPriv trap.

A basic understanding of the event receive module is needed to correctly configure this feature. The module operates according to the specified parameters as follows:

·       There can be multiple event definitions matching the same event, so PVSR processes them in the order specified by the Order parameter

·       Depending on whether receiving a trap or syslog event:

o   Trap: examines whether there is an event set for the received trap, and if yes, then that it matches the optionally specified filter conditions.

o   Syslog: examines whether any of the regular filter conditions matches the received syslog message 

·       If it finds a match, then it first looks at the “Generate event” parameter. If it is set to Yes then

o   It automatically creates an event instance with the help of the specified identifier fields, provided that no such existed before.

o   If these identifier fields are set and it is possible (there is a matching equipment and/or measurement in the PVSR), then it assigns the received instance to a PVSR object:

§  Based on the specified fields, it attempts to find an equipment. If it finds one, then it is already able to assign the instance on the equipment level reliably; for example, it can color the icon of the equipment according to the event under the Alarms menu item.

§  Within the equipment it tries to find an adequate measurement according to further options, so long as they exist:

• Only the type of measurement can is specified. In this case, it takes the first match, e.g., the alarm refers to the CPU of the equipment and there is a CPU load measurement on that equipment
• A further matching condition can be specified. In this case, however, it will search for an exact match for this measurement. Therefore, if there is no exact match, it will not accept the first adequate type as the right match. For example, a trap comes from an interface and it is assigned to a traffic measurement based on its interface index.

o   Depending on whether the received data is interpreted as a creating or deleting event, it will start or close an alarm.

·       Before moving on to the next event definition it looks at the “Ends processing” parameter. If it is set to Yes then it will not try to match any other event definition with the current message

On the figure below the configuration of a pair of an interface up-down SNMP trap is shown, where the system identifies the alarm equipment based on the IP address and the interface based on the index (the name can be different from that in PVSR because it should be unique, and it can also come from other sources, like from a Cisco interface description) and the event is named by the IP address of the alarming equipment and by the index and name of the interface.

The description of fields:

·       Name: Name of the event type, it must be unique.

·       Order: The events are processed in this order. If two events have the same Order parameter then they are processed in order according to their names

·       Level: Level of the alarm; similar to thresholds

·       Type: Type of the alarm; similar to thresholds

·       E-mail: To which address should the system send an e-mail message; similar to thresholds

·       Mobile notification: Which users or mobile notification groups must be notified when an alarm is raised

·       Command: What command should be executed; similar to thresholds. The parameters given to the command are the following:

o   Event definition internal identifier

o   Event definition name

o   Event instance internal identifier

o   Event instance name

o   C for closing and R for raising the alarm

o   When closing the alarm the alarm id within the PVSR is also included

·       Raise and Clear: In case of traps we can choose from the traps of the uploaded SNMP MIBs, and in case of syslog events the matching regular expression should be specified

·       Event identifying field: It identifies the event with the parameters selected here, and matches the raising and closing messages. The event name is formed by writing the fields successively one after the other. In both cases, the IP address records the address where the event came from. For traps we can choose from the common fields of the creating and deleting traps, and for syslogs from the match groups of the regular expression.

·       Equipment and measurement identifying field: Based on the above-described principles, the PVSR attempts to connect the event with an object in its own database. If it is not specified or there is no match, the event is created anyway; however, it is only shown under ROOT site on the Alarms page. There are two ways to find an object in PVSR: the simple and the advanced matching. The simple matching means that the application will take the value of one of the event identifying field and will look for the exact same value in the PVSR database. Although for most cases this is completely enough, in some cases the value from the event cannot be exactly found in the database or the value in the database is split into two or more event fields. In such cases the advanced matching has to be used, see 6.6.1.1

·       Name format: By default PVSR names the event by concatenating the identifier fields with spaces. This can be overwritten using this parameter, where the user can use any kind of Perl expression. It is important to note that when specified PVSR will actually identify the event using the result of this expression rather than the identifying fields

·       Event naming: When an alarm occurs for event definition D and instance I then what should PVSR show on the Alarms menu: “D I” or “I D”

·       Verbose logging: Should the received trap variables and syslog messages be saved separately.

·       Ends processing: If set then PVSR will not try to match any other event definition for a matched message

·       Generate event: If not set then PVSR will not create an event instance and alarm if a message matches this definition. The intended use of this parameter is to create “exclude” filters with “Ends processing” set to Yes,  i.e. “I do not want to have an alarm if this condition is true”

·       Raise and clear event filters: In case of traps we can set conditions for the source IP address and for the trap variables, and in case of syslogs for the Facility and Severity of the message.

For the events among the alarms the PVSR displays the event type name and the event instance name together as the name.

6.6.1.1 Advanced event matching

The "Custom expression" item has to be selected from the "In the event" drop-down list in order to use the advanced event matching function. During the advanced event matching configuration a freely editable field has to be used, similary to the advanced mode during the threshold or the chart element configuration. The "Add to" link can be used to add the selected event field below the text field to the expression, and the Validate link can be used to check whether the field has a valid value or not. It is strongly recommended to be familiar with the Perl language before creating such an advanced matching, since the expression will be evaluated as a Perl expression.