| | | Interface Types |
The various interface types in JFFNMS determine what sort of things can be monitored, graphed and alarmed. A particular device, such as a Cisco router, consists of many interface types. Some of these interface types will be specific for that class of equipment, such as Cisco CPU Load, while there could also be generic interface types, such as a physical interface.
This chapter describes what interface types JFFNMS has, what JFFNMS can do with them and what you will be able to see. Armed with that knowledge you will know how useful JFFNMS is for monitoring a particular sort of equipment.
The Apache webserver is able to provide a set of statistics about how busy the processes serving webpages are. JFFNMS uses this information to present some graphs. As long as Apache is configured correctly, any webserver that is reachable from the JFFNMS host can be monitored this way.
By default, most Apache webservers do not provide this information, you need to enable and configure the mod_status module first.
Apache status is found by connecting to the HTTP port (TCP port 80) and successfully geting the URL "/server-status?auto".
The apache poller regularly visits the URL (shown above) and then parses the results. The following 7 values are displayed in the associated graphs:
The graphs get their data directly from the Apache status poller. Some values are combined into a single graph to aid in comparison.
|
Graph | Description |
| Hits | Througput of the webserver in accesses per second |
| KBytes | Throughput of the webserver in Bytes per second |
| Apache CPU Load | The load that the Apache processes place on CPU |
| Bytes Per Request | Bytes per Request. The average size of the web accesses |
| Workers | A graph showing the red busy workers and green idle workers |
The target Apache webserver needs to be correctly setup to first enable the status module and then to allow access from the JFFNMS server.
For the Apache server to display status, first enable the status module, you will then need to permit access to the status URL from the JFFNMS server. For example, if your JFFNMS server's IP address is 192.168.1.10 then the listing would look like:
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 192.168.1.10
</Location>
ExtendedStatus On
The Location clause can either go in the main section of the configuration file or into a virtual host. The ExtendedStatus line needs to go into the main section.
BGP stands for Border Gateway Protocol. It is the routing protcol that is used by ISPs to transfer routes across The Internet. An ISP's routers speak BGP to other ISP's routers. These remote routers are called BGP peers.
JFFNMS discovers BGP peers by determining if the BGP peer OIDs are valid. If they are each entry in the BGP Peer table is a new interface.
The poller checks the BGP operational status and alarms if it changes from up. In addition it collects inbound and outbound updates plus BGP peer uptime.
There is only one graph for BGP Interfaces. This graph shows the number of Inbound (peer to your router) or outbound updates per 5 minutes. A large and sustained level of updates may mean route flapping is occuring. Be careful if you have a large sustained level of outbound route updates because you may be dampened.
None.
Cisco Service Assurance Agent is a feature of Cisco devices where the device can inject packets into the network and measure various attributes of the network between devices. SAA is part of Cisco's IPSLA system.
Once a device that is capable of SAA is configured to start collecting information a new SNMP table is created. The JFFNMS discovery engine, if it finds this table populated, will display new SAA interfaces.
The Cisco SA Agent poller collects the following information for each SA group: forward and backward jitter, round trip latency, forward and backward packet loss. There is no status polling.
Interfaces of this type have 3 graphs. Round Trip Latency, Forward and Backward Jitter, and Forward and Backward Packet loss (as a percentage).
While there are many types of SAA probes, the only ones that are correctly detected and polled are the jitter probes. Any other type of probe will be detected but will probably display graphs with 0 all the time for all attributes.
There are many parameters that can go into the router configuration and you should check with Cisco documentation about how to configure the router correctly so the probes do not cause any undue performance hits. However a basic configuration, assuming the remote end has IP address 192.168.100.1, would look like:
rtr 1 type jitter dest-ipaddr 192.168.100.1 dest-port 16384 rtr schedule 1 start-time now
IIS is the default Webserver that comes with most Microsoft operating systems.
Discovery of an IIS server happens when the plugin is able to SNMP poll a certain OID that sits under the Microsoft MIB. If the SNMP get was successful an IIS Webserver interface is created.
The IIS pollers use SNMP to find the Total numbers of: bytes received, CGI requests, files sent, GETs and POSTs.
There are 4 graphs for an IIS Webserver interface. One each showing the values for bytes received, CGI requests and files sent. The number of GETs and POSTs are combined on one graph with a green area for POSTs and then a blue area on top for GETs.
Unline the Apache module, this one is dependent on SNMP setup correctly on both JFFNMS and the target servers, as well as a path between them. Devices such as firewalls may allow HTTP traffic but drop SNMP.
This uses a Windows-specific MIB to find a CPU. You can then see information about Load.
SNMP is used for the discovery. Presence of the specific private OID is enough for the interface to be found. The parameters tell which OID to look for to find the CPU.
Nil.
The poller collects information on the following: Average CPU Utilization, Number of Processes, Number of Users, Number of Active Opens, Number of Passive Opens, Number of Established connections.
The TCP information (active and passive opens, established connections) are graphed together on the TCP Connection Status Graph. Likewise the number of users and processes are on the Processes/Users graph. Only CPU utilization gets its own graph.
Currently the poller assumes there is a single CPU.
This is the externally found TCP ports. The host running JFFNMS actively connects to the target using this interface. From there JFFNMS can determine how long it takes to connect and do some simple content checking. This interface type requires the nmap program to be installed and JFFNMS to be told of the binary's location.
The Administrator has the option of sending something to the port and doing a simple check of the return information. This option is called Content Checking.
The Auto-discovery parameters determine the range of TCP ports to probe. This range is then connected by the nmap program. Any open ports are then created into interfaces.
The poller checks that the port is open (contactable from JFFNMS) and, optionally that the returned content matches what has been given. Failure of either check raises an alarm.
Response time is collected for all interfaces. If there is SNMP, the number of established connections is also collected and graphed. That feature requires access to the tcpConnEntry table.
The text sent needs to be a URL starting with http, https, ftp or ftps and the check is a simple needle in haystack non-regular expression check.
The Storage interface is used to collect information about disks. It is for hosts that are running the UCD/NET snmp daemon.
Discovery is done by polling the specific UCD-SNMP OID. The number of blocks on the device, total and used, are collected. In addition, the block size (to convert blocks to bytes) is also found.
None.
Values for Total and Used Blocks plus block size are regularly collected. The graph shows Total and Used values in Bytes.
Another platform-specific system information interface type, this time for hosts running Solaris.
Interfaces of this type are discovered by polling the system OID and matching it to a list of known host OIDs.
None
The pollers collect information about the CPU, Swap, Memory and Load. The graphs are the same as in the UCD Host interface type.
It is assumed there is only one CPU.
Reachability Interface types are ones that are used to ping remote hosts. The pings originate from the server running the JFFNMS pollers so there needs to be an IP path from the polling server to the remote location.
If JFFNMS has been setup with the fping binary and it can execute it then any host with an IP address has a Reachability interface.
The poller will obtain the round trip time (RTT) and packet loss to the remote host. If the packet loss exceeds the threshold for the interface (the default is 70
For each reachability interface JFFNMS can show graphs of the RTT and packet loss.
Almost any SNMP-capable device will have Physical Interfaces. These are the entries found in the ifTable part of the MIB. However each class of device has a different way of presenting its interfaces.
Depending on the device, physical interfaces could include actual device interfaces, Etherchannel groups, vlans, layer-3 interfaces in switch/router combinations and loopback/localhost interfaces.
Problems occur with several popular SNMP-capable devices that do not set their description correctly or non-uniquely.
In addition, on some devices, such as Cisco routers and switches, the poller can set
JFFNMS scans the ifTable SNMP interface table to discover Physical Interfaces.
Some interfaces, such as ATM aal5, ISL and 802.1q trunks have their descriptions slightly modified to remove the identifier.
The Physical Interface poller collects several statistics about the interface. The first two are the administrative and operational status of the interface. The states are then used to determine the state of the interfaces alarm icon.
Input and Output rate of packets, octets and errors are collected. As well as the
Problems are likely to occur if the description (ifDescr OID) is the same for different interfaces.
JFFNMS Manual, last changed July 3, 2008
| | | Interface Types |