| | | Configuring JFFNMS |
There are a wide variety of objects (internally called structures) within JFFNMS. To really understand JFFNMS, you have to get a good understanding of its objects and the relationships between them.
The objects are arranged in order as you would see them in the administration screens. This is done to help you find the object you need and also the administration menus are arranged in a logical order.
Before getting into how to configure JFFNMS it is important to understand how it handles various pieces of information and what definitions it uses for the pieces of data.
Raw events are brought in via their relevant processes. That is msyslog or syslog-ng import raw events into the syslog table, or snmptrapd imports raw events into the traps table (with the variables going into the varbinds).
Every minute the consolidator is run from cron. There are two main parts of the consolidator. The first is the raw event specific part. This takes the raw events and compares them to a match list. For example the syslog consolidator will look at all non-analyzed raw events in the syslog table and will compare each one with the list that is found in the table you create on the Syslog Events screen and place any matching into the events table.
An event is a one-off occurrence that is essentially a cleaning up and categorizing of a raw event. A syslog raw event has a time, host and a message. The consolidator, if there is a match, will give it an event type, a host and then optionally an interface, state, username and information. Events are visible in the event viewer (the display with the horizontal colored bars).
The second part of the consolidator is the event consolidator. It is run after all the raw event consolidators have run and it looks at the new events that have been created. It's job is to convert an event into an alarm.
An alarm has a type (the same as the event being processed), a start and stop time, an interface id (which also specifies its host) and a state (from Alarm States) called active. An alarm is started and stopped by the consolidation of events. For this to happen, the consolidator needs to find an event that has a known host, interface and state. There is no concept of an alarm with no interface. Alarms are visible by the colors of the interfaces (or their hosts) in the map views.
When the consolidator finds an event with Alarm State DOWN (ie the interface is now down or broken) it first goes to find any existing alarms for the same interface and type if so makes them inactive and sets the stop time based on the event time. It then creates a new alarm with the event time as the start time.
A new event with state UP will make the consolidator set any alarms with matching interfaces and type to inactive and set their stop time to the event time. This means the interface on the map should go back to OK state.
The Start Time, Stop Time and Duration are used in the State Report to calculate Availability.
To find out what interface an potential alarm is for, the consolidator matches the event's host with each host. If that matches it then tries to match the event's interface field with the interfaces name (or interfaces.interfaces variable internally)
JFFNMS Manual, last changed July 3, 2008
| | | Configuring JFFNMS |