Netmond V2. DesignThis is short description of architecture and basic algorithms of Netmond.
Basic algorithms.Netmond running is based on one main cycle of asynchronous socket and timer events processing. Single process operates multiple sessions concurrently. All monitoring operations are defined in single configuration file. Netmond consider The Network as a hierarchy of objects
of some type.
Two different ways exist to monitor objects:
This ways have benefits and disadvantages. To achieve maximum efficiency and flexibility Netmond use both. Queries are distributed on a polling time interval accordingly net distance (hop count) if possible, so close objects queried before distant objects. Distance metrics are evaluated automatically with ICMP echoRecord-Route option (built-in method PING). Returned data are saved in internal structures named variable
This structures hold current and previous value.
Variables can be global or can be bound to some object or subobject. A number of predefined variables are created and bound for every object. Additional variables can be defined in configuration file. With saving methods collected data can be passed for:
Also collected data are accessible via built-in NetState service. This is telnet-like service with simple textual protocol. Object types
Objects with similar behavior and characteristics are grouped in TYPE.
Netmond deal with following objects types:
Every OBJECT can have:
Every INTERFACE can have:
Every SERVICE can have:
Every BGPAS can have:
Every ENVTEMP can have:
Memory space for objects data structures allocated dynamically. Internal 'state' of any object changes when some object polling method get new data or SNMP trap caught from it. Polling (inquiry) methodsNetwork objects have been monitored with various polling methods METHOD.
Methods have been grouped to list and bound to objects.
Each method makes simple network interaction with this object to check it characteristics.
Methods in object's list have evaluated sequentially in order as defined by user.
Current list evaluation stops when any method in list fall (return error or timeout elapsed),
Only OBJECT and SERVICE objects can have arbitrary polling methods. Other objects have been checking during built-in ROUTER method evaluation for parent OBJECT. Data mined in METHOD evaluation can be stored to internal variable VARIABLE for this object. Following built-in methods METHOD can be bound to OBJECT or SERVICE: ATTENTION! not all OSes support ICMP Record-Route option. All protocols and scripts realized as separate independent modules with unified Netmond API. New modules can easily be added. SNMP trapsTo catch SNMP notifications from objects, Netmond have built-in
'trap' service listening on 162/UDP port. Such a notification consists of the number of SNMP variables.
Each variable presented as variable name and their value.
Notifications from objects utilized via extracting SNMP variables and their values to internal variables VARIABLE for corresponded object. In some cases object 'state' changes also.There are the number of trap messages supported by Netmond by default:
Traps of other sort have to be explicitly defined as TRAP methods and bound to corresponding objects with needed variables VARIABLE. Data representationAll useful information is stored in program memory as a VARIABLEs Some variables are 'read-only' constants - they cannot be changed until next
reconfiguration like object name. Some constants and variables are the part of program code - they exist
all the time the program run. They have some meaningful values.
These are - HardCode VARIABLEs.
Variables are grouped to lists and bound to objects of subobjects.
Some subobjects like INTERFACE BGPAS ENVMON
have only the number of individual predefined automatic variables.
Variable is the structure consisting of the name of and value.
Variable name reflect it's meaning and is collection of uppercase and lowercase
latin letters, digits and underscore signs - [a-zA-Z0-9_].
But while running letter case ignored. Variables values can be:
Soft VARIABLE untypified. The same variable can hold different value types in different times. String value is outputted in quotes. Undefined value is outputted as Unused keyword. Soft VARIABLE structure include:
For a numeric Soft VARIABLE with Integer, Unsigned or Floating type there are additional fields:
This fields are updated every data saving interval for parent object. The number of POLLING cycles can happen during this saving interval. Some Soft variables values can be outputted as a 'state' string (UP, DOWN, ESTABLISHED etc.). Additional fields for variable $Name accessible via variable name with suffixes:
Variable names can be used in a configuration file or in a request to built-in NetState service. Do not forget, letter case is ignored. Data savingData saving method SAVE is the way to output internal data to outside 'world'. Every object or subobject can have the number of different saving methods. Predefined simple saving methods SAVE exist for every object
type. This methods store data to a plain text file.
User can SAVE VARIABLEs following ways:
Saving can happen:
User can define output format. Using this way user can create simple network alerting framework. NetState serviceAs above mentioned, Netmond store colleted data in VARIABLEs. VARIABLE values are modified during polling and trapping and outputted with saving methods. So with SAVE methods Netmond himself decide when to save data,
and what data to save.
Built-in NetState service mission is to serve asynchronous authorized user requests and to provide read-only access to all VARIABLEs. All VARIABLEs considered as hierarchy of variable names and their parents names. Variable 'path' in this hierarchy is a sequence of object and subobjects names separated with special char '!' like this: Suffixed variable names also available this way. Initially NetState service was designed to provide actual data for operator interface. See also: © 1998-2002, Rinet Software
|