Table Of Contents
Monitor Database
Monitoring the network: MONITOR
Storing the topology: the TopoCache database
Storing the poll definitions: The PolldefCache database
Storing Agent information: The AgentInfo database
Database map
The topoCache database schema
The polldefCache database schema
The agentInfo database schema
Conclusion
Monitor Database
This chapter describes the databases used by MONITOR to distribute polling definitions and topology information to the Polling Agents.
Monitoring the network: MONITOR
In order to monitor the network, MONITOR must load up poll definitions from the class loader and management system CLASS and store all topology information obtained from the topology store MODEL. All this information is stored and distributed on demand to the Polling Agents once they have been started and have communicated to MONITOR their existence and readiness to poll the network.
MONITOR stores a copy of the topology from MODEL in a database called the TopoCache database. MONITOR holds a cache of the poll definitions in a database called the PolldefCache database, which is contained in the Active Object Classes.
MONITOR interprets the poll definitions and distributes the polling methodology to the Polling Agents. Additionally, MONITOR determines the status of the Polling Agents and tracks their operation, and stores this information in a database called the AgentInfo database. The TopoCache, PolldefCache, and AgentInfo databases are discussed in the following sections.
Storing the topology: the TopoCache database
The TopoCache database (topoCache) is responsible for holding all the network entities, their containments and their connections. The TopoCache database consists of a single table and is a simplification of the Master database within MODEL. The single constituent table is the entityByName table (topoCache.entityByName), which holds information about all the discovered entities on the network. MONITOR distributes the topology to the different Polling Agents from this table. The information held about each device in the entityByName table is listed below:
•
The unique ObjectID of the network entity.
•
The unique descriptive name of the network entity.
•
A list of all addresses for Layers 1 - 7 of the OSI model.
•
The value of the sysDescr MIB variable or a description of the network entity.
•
The entity type of the network entity.
•
The class to which the network entity belongs (if applicable).
•
The value of the sysOID MIB variable for the network entity.
•
A list of extra information associated with the object.
•
The status flag of the network entity.
•
The password needed to access the network entity if applicable.
•
A list of entities connected to the network entity.
•
A list of other entities contained within the network entity.
•
A list of other entities that the present network entity is contained within.
•
A flag used to denote whether the current network entity warrants an Active Object Class.
•
The time the network entity record was created.
•
The last time the network entity record was changed.
•
The type of record represented by the current database entry.
Storing the poll definitions: The PolldefCache database
The PolldefCache database (polldefCache) is responsible for holding the poll definitions loaded from CLASS. It is from this table that MONITOR distributes the polling methodology to the different Polling Agents. It consists of a single table called the polldefs table (polldefCache.polldefs), which stores the full definition of the polling methodology loaded from CLASS. The information held by the table on each poll definition is listed below:
•
The poll definition state (an internal flag).
•
The unique name of the poll definition.
•
The name of the Polling Agent used to conduct this poll.
•
The threshold condition, which is used in two ways. Firstly, it is used to specify the parameters to poll for in the case of SNMP, Trap and Syslog Agents. Secondly, it defines a logical condition which determines whether an event is generated or not.
•
The degree of severity associated with the event; this is sent to the event correlation engine as a result of the poll.
•
A function that extracts the textual description of the physical location where the event was generated from the network device.
•
A function that extracts the textual description of the contact information for the event to be generated, e.g., the person responsible for the network device.
•
The textual description of the name of the event to be generated by the poll.
•
An integer or function that determines how frequently the poll is carried out.
•
The timeout, i.e., how long the Polling Agent should wait for a response from the device before reporting a poll fail.
•
The scope of the poll, i.e., a list of constraints that restrict the device types, class types, instances etc. that the poll should restrict its application to.
•
The time-to-live value, i.e., the number of polls the Polling Agent is allowed to conduct before it is terminated.
•
The name of the Active Object Class to which the present poll definition belongs (determined by MONITOR).
•
A list of Polling Agent extensions, that can be used for specifying extended functionality within the Polling Agent.
•
The event correlation engine to which the results of the poll will be sent.
Storing Agent information: The AgentInfo database
The AgentInfo database (agentInfo) is responsible for holding information about the active Polling Agents. MONITOR can track the status of the different Polling Agents from this table. It consists of a single table called the master table (agentInfo.master), which stores the status information of every active Polling Agent. The information held by the table on each poll definition name is:
–
The name of the Polling Agent.
–
The process identification (PID) number of the Polling Agent executable.
–
The Host address where the Polling Agent is running.
–
The protocol being used by the Agent in carrying out its poll directives.
Database map
Figure 27-1 The databases of MONITOR
The topoCache database schema
The schema of the entityByName table of the TopoCache database is shown below.
Table 27-1 Synopsis of the topoCache database and its tables
Database name
|
|
Database definition location
|
$RIV_HOME/etc/MonitorSchema.cfg
|
Fully qualified database table name
|
|
Table 27-2 The entityByName table: topoCache.entityByName
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
ObjectId
|
PRIMARY KEY
NOT NULL
UNIQUE
|
Long Integer
|
Unique Object ID of the network entity.
|
EntityName
|
PRIMARY KEY
NOT NULL
UNIQUE
|
Text
|
Unique descriptive name of a network entity.
|
Address
|
|
List of Text data type
|
List of OSI model Layer 1-7 addresses for the entity.
|
Description
|
|
Text
|
Value of sysDescr MIB variable or other suitable description of the entity.
|
EntityType
|
Externally defined entityTypes data type
|
Integer
|
Element type of the entity.
|
ClassName
|
PRIMARY KEY
NOT NULL
|
Text
|
The Class name of network entity (if applicable).
|
EntityOID
|
NOT NULL
|
Text
|
Value of sysOID MIB variable of the entity.
|
ExtraInfo
|
Object
|
Externally-defined varbind list
|
List of additional information.
|
Status
|
Externally defined status data type
|
Integer
|
Flag showing status of the network entity.
|
Security
|
|
Text
|
Password to access network entity (if applicable).
|
RelatedTo
|
|
List of Text data type
|
List of connections to the network entity.
|
Contains
|
|
List of Text data type
|
List of elements or other containers contained by this entity.
|
PartOfName
|
|
List of Text data type
|
The name of the physical device to which the network entity belongs.
|
IsActive
|
Externally defined Boolean data type
|
Integer
|
Flag indicating whether an Active Object Class is needed.
|
CreateTime
|
|
Time
|
Creation time of network entity record in table.
|
ChangeTime
|
|
Time
|
Time of last modification to the network entity record.
|
ActionType
|
Externally defined Actions data type
|
Integer
|
Type of record.
|
The polldefCache database schema
The schemata of the PolldefCache database and polldefs table are shown below.
Table 27-3 Synopsis of the polldefCache database and its tables
Database name
|
|
Database definition location
|
$RIV_HOME/etc/MonitorSchema.cfg
|
Fully qualified database table name
|
|
Table 27-4 The polldefs table: polldefCache.polldefs
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
PollDefState
|
|
Integer
|
Internal flag.
|
PollName
|
PRIMARY KEY
NOT NULL
UNIQUE
|
Text
|
The unique name of the poll.
|
AgentName
|
|
Text
|
The name of the Polling Agent used to conduct this poll.
|
Threshold
|
NOT NULL
|
Text
|
The Threshold condition is used in two ways. Firstly, it is used to specify the parameters to poll for in the case of SNMP, Trap and Syslog Agents. Secondly, it defines a logical condition which determines whether or not an event is generated.
|
Severity
|
|
Integer of externally defined statusTypes data type
|
The degree of severity associated with the event that is sent to the event correlation engine as a result of the poll. The possible values are: Clear, Unknown, Warning, Minor, Major, Critical, or None.
|
Description
|
NOT NULL
|
Text
|
An extraction of the description of the event to be generated.
|
Location
|
|
Text
|
An extraction of the location where the event was generated.
|
Contact
|
|
Text
|
An extraction of the contact information relating to the event to be generated.
|
EventName
|
|
Text
|
The textual description of the event to be generated, e.g., `pingFail'.
|
Frequency
|
|
Integer
|
How often the poll is conducted.
|
ThreshFailList
|
|
List of Text data type
|
List of event record amendments or additions if the threshold condition fails.
|
PollFailList
|
|
List of Text data type
|
List of event record amendments or additions if the poll fails.
|
RestoreFailList
|
|
List of Text data type
|
List of event record amendments or additions if a formerly down device comes alive.
|
Timeout
|
|
Integer
|
The maximum time to wait for a response from a polled device.
|
Scope
|
|
List of Text data type
|
List of filters to constrain poll execution to certain devices, classes or instances.
|
Ttl
|
|
Integer
|
The number of polls that should be conducted by the Polling Agent before it is terminated.
|
ClassName
|
PRIMARY KEY
NOT NULL
|
Text
|
The name of the class to which the event belongs.
|
AgentExtensions
|
|
List of Text data type
|
A list of Polling Agent extensions, which can be used for specifying extended functionality within the Polling Agent.
|
Subject
|
NOT NULL
|
Text
|
The event correlation engine to which the results of the poll will be sent.
|
The topoCache
database schema
The schemata of the AgentInfo database and masters table are shown below.
Table 27-5 Synopsis of agentInfo database and its tables
Database name
|
|
Database definition location
|
$RIV_HOME/etc/MonitorSchema.cfg
|
Fully qualified database table name
|
|
Table 27-6 The master table: agentInfo.master
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
AgentName
|
NOT NULL
|
Text
|
The name of the Polling Agent.
|
Pid
|
NOT NULL
UNIQUE
|
Integer
|
The unique process ID of the Polling Agent executable.
|
HostAddress
|
NOT NULL
|
Text
|
The IP address where the Polling Agent is running.
|
Protocol
|
NOT NULL
UNIQUE
|
Integer
|
The protocol being used by the Polling Agent to carry out its poll.
|
Conclusion
This chapter has shown how MONITOR uses a series of databases to load topology information from MODEL. In conjunction with cached poll definition information, MONITOR supplies the Polling Agents with the polling methodology they should employ in retrieving device status information.
The next chapter describes the databases used by the Polling Agents to conduct their operation of polling network devices for status information.