125 lines
5.4 KiB
Text
125 lines
5.4 KiB
Text
Network Monitoring Dealer http://soft.risp.ru/netmond/
|
||
------------------------------------------------------
|
||
|
||
Netmond is an essential and flexible tool for network administrators.
|
||
Netmond is a daemon providing an interface between low level network
|
||
stack and a GUI monitoring program or a database.
|
||
|
||
Netmond accumulates network neighborhood data, periodicaly polling network
|
||
objects by several methods and collecting SNMP traps. Gathered information
|
||
is parsed so that client programs can comfortably request it via unified
|
||
interface.
|
||
|
||
Netmond can be used as primary data source and as a notification subsystem
|
||
in a network monitoring framework.
|
||
|
||
Netmond have a modular architecture. Modules work indepependently but use
|
||
common task scheduler, session multiplexor, topology correlator, variables
|
||
pool and output channels. The unique asynchronous polling algorithm
|
||
does not limit a number of simultaneously controlled objects.
|
||
|
||
Collected data can be saved by variuos methods periodically or conditionally.
|
||
Also, a client program can request the data dynamically via network.
|
||
|
||
Netmond considers the network as a collection of objects. All objects to be
|
||
monitored have to be described preliminary in a configuration file. Objects
|
||
polling works in parallel, not sequentially, like in other systems. Polling
|
||
requests are distributed over the poll interval as optimally as possible.
|
||
While executing, Netmond can dynamically determine topological dependences
|
||
of objects and interfaces and correct polling modes or even block polling for
|
||
subordinate objects.
|
||
|
||
The Netmond deal the with following object types:
|
||
|
||
* OBJECT - primary monitoring target, an object with IP address;
|
||
* INTERFACE - network interface, subobject of OBJECT;
|
||
* BGPAS - autonomous system number, subobject of OBJECT;
|
||
* BGPPEER - BGP peer for autonomous system, subobject of BGPAS;
|
||
* ENVTEMP - environment temperature (Cisco only), subobject of OBJECT;
|
||
* SERVICE - arbitrary network service, subobject of OBJECT;
|
||
|
||
For any OBJECT type instance operator can define:
|
||
|
||
* METHOD - list of polling methods;
|
||
* TRAP - list of traps methods;
|
||
* POLLING - polling interval (the time between METHOD calls);
|
||
* VARIABLE - list of variables, optional;
|
||
* SAVE - list of data saving methods, optional;
|
||
* SAVING - data saving interval (the time between SAVE methods calls);
|
||
* INTERFACE - list of network interfaces, optional;
|
||
* BGPAS - list of autonomous systems, optional;
|
||
* ENVTEMP - list of thermal sensors, optional;
|
||
* SERVICE - list of arbitrary services, optional;
|
||
|
||
If BGPPEER list is not defined for a BGPAS instance, Netmond builds
|
||
this list automatically.
|
||
|
||
The state of OBJECT is a result of execution of all associated methods from
|
||
METHOD and/or TRAP lists. Methods are evaluated sequentially until the first
|
||
error. The order of execution is defined by operator.
|
||
|
||
VARIABLE values and state of subobjects INTERFACE, BGPPEER, ENVTEMP and SERVICE
|
||
are also evaluated during execution of METHODs and TRAPs. All subobjects have
|
||
their own SAVE list.
|
||
|
||
Inside a METHOD definition the following protocols can be used:
|
||
|
||
* PING - ICMP echo <20> IP with Route Record option for topology discovery;
|
||
* SNMP - simple SNMP v1 request for specified VARIABLE OID;
|
||
* ROUTER - multiple SNMP v1 requests, indexing of certain tables,
|
||
extracting internal VARIABLEs values;
|
||
* TCP - simple TCP session with text chat capabilities, extracting
|
||
VARIABLEs values from answers;
|
||
* UDP - simple UDP sequence with arbitrary chat, extracting
|
||
VARIABLEs values from answers;
|
||
* DNS - DNS service check;
|
||
* RADIUS - RADIUS service check;
|
||
* TACACS - TACACS+ service check;
|
||
|
||
TRAP collector expects SNMP v1 traps, with BGP Enterprise (RFC1657),
|
||
Cisco Private Enterprise or an arbitrary Enterprise defined by operator.
|
||
|
||
The protocols are implemented as separate independent modules. New modules
|
||
could be added in the future.
|
||
|
||
A VARIABLE instance is reffered to by an unique alphanumeric name. The name
|
||
can be used in the configuration file and for dynamic data request
|
||
via NetState service. Typically, the list and the names of VARIABLEs are
|
||
defined by operator. Several predefined VARIABLEs exist for some METHODs.
|
||
|
||
A VARIABLE can be of any of the following types:
|
||
|
||
* integer
|
||
* float
|
||
* IP address
|
||
* string
|
||
* SNMP OID
|
||
|
||
The actual variable type is automatically determined on value assignment.
|
||
During Netmond execution the number of associated values for every
|
||
VARIABLE is maintained - the current value, previous value as well as
|
||
minimal, maximal, average and delta during the SAVING time interval,
|
||
if applicable.
|
||
|
||
Netmod provides three SAVE methods to output VARIABLE values:
|
||
|
||
* writing to a file;
|
||
* pushing to a pipe;
|
||
* passing as an argument for external program.
|
||
|
||
SAVE methods are evaluated -
|
||
|
||
* periodically, with SAVING interval
|
||
* on change of VARIABLE value;
|
||
* by condition - when a logical or expression with VARIABLE value become TRUE
|
||
|
||
NetState service is an independent module of Netmond providing asynchronous
|
||
network access to current VARIABLE values for client programs. The whole
|
||
variables pool is presented as a hierarchy of variables and their owners in
|
||
format: "object!subobject!variable = value". The request could contain an
|
||
optional regular expression to filter the required output. This feature was
|
||
introduced for flexible dynamic data transmission to operator's GUI.
|
||
|
||
Please, address all questions, proposals and complains regarding Netmond to
|
||
netmon@service.risp.ru mail list. To subscribe send a message with body text
|
||
'subscribe netmon' to majordomo@service.risp.ru.
|