| | | Introduction |
JFFNMS stands for Just For Fun Network Management System. It uses the PHP scripting
language to collect and display the information about various devices
that can be found in a computer network. The main building block for
JFFNMS is the Interface which are collected together by a Host .
The concept of interfaces is expanded from the usual meaning. While it does include physical network ports, for JFFNMS it means something that either has a state, one or more values or both.
JFFNMS can report on the Interfaces condition via events, alarms, graphs or actions. It can be setup so that an action, such as an email, is sent on a changed state of an interface, an event happening or even when a value for an interface exceeds a specified level.
A Network Management System or NMS is a system of computer hardware and software that is used to manage the state of devices. The devices could be things like routers, switches or servers and they are called network elements generally, though JFFNMS calls them Hosts.
There are two ways for a NMS to determine the state of network elements. They can poll for the information or they can wait for triggers. JFFNMS does both types of state checking. Typical polling is SNMP gets and connections to TCP ports, while triggers would be SNMP traps and syslog messages.
The lowest level of NMS is the Element Manager, which means it directly looks after the network elements. There can then be additional NMSs that can give a network or system-wide view. JFFNMS is more a element manager, though it does have some features of the higher level NMS.
JFFNMS is deceptive. Most people use it to satisfy a small set of requirements and initially use it for those reasons alone. Then exploring JFFNMS you can see it does a lot more. Some of the features include:
The types of devices, or "Interface Types" that JFFNMS can monitor is large and, thanks to the efforts of the JFFNMS developers and users, growing all the time. For a list of what devices you can monitor, see Interface Types.
It is important to understand the various entities and their relationships within JFFNMS. Many hours of wasted debugging and configuration time can be saved if you understand what JFFNMS is trying to do and the terminology used.
All network devices or network elements are called hosts. Hosts are basically a container for interfaces. Both hosts and interfaces can have IP addresses as well as other properties. Generally a host is some device out on the network that has an IP address.
The definition of an interface is a bit more complex. It's better to think of an interface as an attribute or property of a host. More specifically, its something you want to monitor on the host. Each interface has an interface type, which describes what information needs to be collected (by a poller group, what information needs to be stored and how it is discovered. The easiest interface type to understand is a physical interface on a router, switch or server; but a process, a TCP port or even a fan is also an interface.
The way that information flows within JFFNMS can be a bit daunting at first. This section describes how the information gets into JFFNMS and what happens to it within JFFNMS.
There are three main ways that information comes from a Network Element (such as a router, switch or server). They are information from the JFFNMS pollers, syslog messages or SNMP traps.
Every 5 minutes cron kicks off the poll sequence. Pollers then do various bits of prodding of the network element. The information that comes from the pollers then ends up either as an event or as a data point in a RRD file.
The network element may decide to send a SNMP trap or syslog message to JFFNMS. In this case the piece of information will hit either an external program snmptrapd or syslogd. If they have been setup correctly (see External Programs for details) then the trap or message will end up in the particular database table for that message type.
Once again, cron kicks off another job every minute called the consolidator. The consolidator is actually made up of various types of consolidators that generally work on three sets of tables: An input table, a rule matching table and a output table. The general idea of the consolidators is that they take new rows of the input table, attempt to match them to the rule matching table and if there is a match, modify the data and add them to the output table.
The traps and syslog consolidator examine the relevant table, attempt to find known traps or syslog messages and, if matched, will create new events based upon the information for the matching rule in the traps_type or syslog_type table.
Another consolidator is the event consolidator. Unlike most other consolidator, this one has a rather fixed set of criteria. The consolidator takes the event table as its input and the alarm table for its output. It examines each new event and if it can find a matching interface and the event type is one that generates an alarm, it will toggle the alarm state of that interface (if the event would change it).
Finally there is the alarm consolidator. This one is used to fire the triggers which then activate the actions. It examines the event and alarm tables for matching enabled triggers. This consolidator is the one responsible for generating emails or pagers when an event or alarm happens.
In addition to syslog and snmp events, the pollers can directly or indirectly set events. The direct method means the poller is using the alarm (or similar) backend and is used for things like interface state changes. The indirect method is via the SLA analyzer.
The SLA analyzer examines specified interfaces' RRD files and matches the data against the SLA criteria. If there is a SLA hit, an event is created for that interface. The SLA analyzer is run out of cron every 30 minutes.
JFFNMS has an email list that is hosted on sourceforge, the subscription information is found at http://lists.sourceforge.net/lists/listinfo/jffnms-users.
If you are stuck then you can try looking in the archives first and if that doesn't answer your question then feel free to post into the list. You will have to subscribe first.
JFFNMS Manual, last changed March 29, 2008
| | | Introduction |