| | | Event Configuration |
Events are generated by the different consolidators that are run out of cron every minute. They are some piece of information that has come into JFFNMS that it recognises.
Events come from pollers, syslog and SNMP traps. They have a type and a severity. Events then may cause an interface to have an alarm or for an alarm on an interface to be removed.
Events have 4 fields; Username, Interface, State and Info. The Username and Info fields are just generic containers to provide extra information about the event. Interface and State are used by the consolidators to map an event to a specific interface and set the alarm severity of a subsequent alarm respectively.
The event consolidator runs over the new list of events that have come in recently. An event that has its type configured in the Event Types Table to generate an alarm is then examined. The Event needs to have an interface associated with it, which means there is a host defined and the interface field in the event matches the name of one interface in the host. In addition the state field of the event needs to match one of the Descriptions in the Alarm States Table.
Each event has a severity. The severity changes the colour of the event and can be used for filtering. The list of event severities is found at Administration => Event Analyzer => Severities. The table lists each severity, the level of the severity (the higher being events that are more critical or important) and then the foreground and background colours used in the event viewer for events of that severity.
Do not get event severity confused with alarm levels which has its own table at Alarm States.
This page determines how a particular event is displayed. This does none of the selection but just shows what severity and text will be displayed.
The following fields are used to define an event type.
Event Text is a mixture of plain text and parameters derived from the event and the interface the event has occurred on. Parameters are described in <> signs, eg <user> for the user field, the following parameters are defined:
The standard set of fields that can come from all events are user, state, info which come from the syslog or SNMP trap consolidation. If the event also is associated with an interface then the Interface Parameters can also be used in the template.
The "Show in Event Viewer?" means by default you will see the alarm. If you want to record the event but don't want to see it by default don't click this option. You can use Filters to display the other events.
One of the sources for events is from the syslog daemon. The first thing to do is to get the relevant syslog messages into the JFFNMS Table, which is described in External Programs -Syslog
Now that the messages are coming into the raw syslog events table, JFFNMS needs to be told how to convert these items into events. The Syslog Events Types table is found in Administration menu item Internal Configuration => Event Analyzer => Syslog Message Rules.
Each row starts with the Text Match. This can either be a Perl-compatible regular expression (PCRE) or a literal string. The literal string cannot contain any brackets ( or ). Due to the flexibility and unambiguity, PCRE matches are preferred.
Next are the Interface, Username, State and Extra Info Fields. These can have various values and are described in table *.
If the syslog messages matches the Text Match, an event defined by the Event Type column, which is a selection of all event types from the Event Types table, is raised. The fields that are defined are put into the relevant event fields.
There may be many matches for the same syslog message. The position column does the order of evaluation. The syslog consolidator will examine each syslog match rule in order of position (lowest number to highest). This way if you have more specific rules give them a lower Position than more generic rules.
If you want the syslog messages to raise alarms on interfaces then the interface and state fields must match the name of an interface for the host and a Alarm State respectively.
|
Field | Description |
| Digit | Matches the Nth captured subpattern, or the thing in brackets in PCRE matches or the Nth word after the literal text. |
| * | The field will have the whole syslog message |
| D | Everything past the match |
| other | Anything else the field gets the value configured |
For example, if you have the syslog message show below and the fields you want to have filled in are show in table *.
1473: 4w2d: %SYS-5-CONFIG_I: Configured from console by craig on vty0 (192.168.1.25)
|
Field | Value |
| Interface | vty0 |
| Username | craig |
| Extra Info | console |
| Event Type | Configuration |
You would use text match field like this:
%SYS-5-CONFIG_I: Configured from (\S+) by (\S+) on (\S+)
We have three sets of brackets, so we have three substrings:
substring[1] = "console"
substring[2] = "craig"
substring[3] = "vty0"
We want the Interface field to be filled in with "vty0", so in the
Syslog Message Rules, we put 3 the Interface Field column. That tells jffnms
to fill in the Interface field with the first substring match. Similarly,
Username has 2 and Extra Info is 1. There is no need for the numbers to
be sequential or even for all of them to be there, however the number
of bracket pairs must equal the highest index; eg in our example putting
4 in any of the Fields columns is invalid.
We're not using the State field here, so its column is blank.
The full syslog event line in JFFNMS will look like table *.
|
Action | ID | Text Match | Interface Field | Username Field | State Field | Extra Info Field | Event Type | Position |
| Edit Del | 10001 | %SYS-5-CONFIG_I: Configured from (\ S+) by (\ S+) on (\ S+) | 3 | 2 | 1 | Configuration | 1 | |
You would then setup an event in the Event Types to display the information.
Every time the consolidator runs, it goes through the syslog table looking for any rows it has not yet analyzed. If it finds a new row, it then goes through the syslog_types table looking for a PCRE match to the syslog string.
If there is a match, the syslog consolidator will then fill in the fields using the given substring indexes and using the Event Id given for that particular PCRE.
If there is no match with any of the PCREs, the consolidator will use the default syslog event. PCREs are checked by their ID number.
Like all consolidator modules, the syslog consolidator will output any log information to jffnms/logs/consolidate-<todays date>.log The date is in the format YYYY-MM-DD
|
Column | Description |
| Description | A short description of the alarm level. This field is used by the event consolidator to match the state field to an alarm state. |
| Alarm Level | The importance of this level of state. The lower the number the more important. For example, a down state is more important than an up, so down has a default level of 10 and up has a level of 100. This means the state of an interface, if it has both active events with a state of up and down will be down. |
| Sound In | If an interface goes into this alarm level, send this sound to the GUI. |
| Internal State | The internal alarm state that this state should map to. There are only 4 alarm states, see table *. |
|
State | Description |
| Up | Interface is up and working and online |
| Down | Interface is down or not working or offline |
| Testing | Interface is testing or training, it cannot be currently used but is enabled |
| Alert | Interface is up but has had some warning or degradation |
It is the job of this table to convert from the various classes of alarm states and sort them into a smaller list of internal alarm states. The wide variety of Interface Types means there is a need for this mapping. In addition this table sorts the alarm levels and enables the sounds associated with the alarms.
The Alarm State table is found at Administration menu Event Analyzer => Alarm States & Sounds. Table * describes what each column does.
Of the alarm states foundin Table *, the first three states get their inspiration off the ifOperStatus SNMP OID as described in section 5.2.1 of RFC 1156 and you could use that as a guide for what to map your own Alarm Levels. The Alert level means that something bad has happened to the Interface but not too bad to take the interface offline.
JFFNMS Manual, last changed July 3, 2008
| | | Event Configuration |