The XML configuration is compiled into the database representation by operator's manual request.
The compiled version of the configuration is not a one-to-one representation of the XML version. All aliases and templates are expanded. Thus, the backwards restoration of XML from the database is possible, but is not our urgent task.
Aliases are the way to represent the data in a more convinient format. An alias can point to a subtree or a leaf, and it works similarly as a symbolic link in a filesystem.
A template defines a piece of configuration which can be used in multiple places. Templates and aliases are not supported within a template.
The configuration can consist of several XML files. They will be processed in the specified order. Each new file is treated as an additive information to the existing tree.
The configuration processing module should contain information about parameter dependency and mandatority. Should the mandatory parameter be missing, the configuration processing should stop with an explanative error message.
All runtime data is stored in Berkeley DB database environment (http://www.sleepycat.com).
The compiled version of the configuration XML is stored in
the ds_config_INST.db and other_config_INST.db.
These databases have similar structure, and
ds_config_INST.db keeps all datasource-related information.
INST stands for the productive instance number, and has value 0 or 1.
Current productive instance numbers are stored in db_config_instances.db
database.
For each datasource tree, the database files are resided in $RRFW_HOME/var/db/sub/>tree_name< directory.
The runtime modules access the configuration via ConfigTree objects.
Each datasource subtree or leaf is identified by a token. Token is a short string of word characters, generated internally. Two types of tokens are recognized: single tokens and token sets.
Single token starts with letter T. The rest is a number of decimal digts.
Token set name starts with letter S. The rest is an arbitrary sequence of word characters.
The special token SS is reserved for tokensets list. Also tokenset parameters are inherited from this token's parameters.
View and monitor names must be unique, and must start with a small letter.
db_config_instances.db is a Hash database, with keys of form
ds:>tree_name< or other:>tree_name<, and 0 or 1 as
values.
ds_config_INST.db is a Btree database, with the keys and values defined as follows:
other_config.db is a Btree database, with the keys and values defined as follows:
aliases.db is a Btree database with aliase paths as keys and target tokens as values. It is used for quick alias expansion.
tokensets.db is a Hash database containing the token sets. The keys and values are as follows:
nodepcache.db is a Btree database containing the cached node parameter values. The keys and values are as follows:
U for undefined parameter, and
D for a parameter with value.
config_readers.db is a Hash database which contains the informaton about active processes which read the configuration. The configuration compiler waits until all readers finish using the current configuration database. Process IDs are used as keys, and the values contain timestamps.
timestamps.db is a Hash database containing various kinds of timestamps. The timestamp name is the key, and the number of seconds since epoch is the value.
render_cache.db keeps the status information about the graphs ready to display. Last known timestamp of the configuration is compared with the actual one. When the actual timestamp differs from known, the renderer cache is cleaned up. This is a Hash database, with the following keys and values:
monitor_cache.db is a Hash database used in order to avoid the unneccessary configuration tree walk. The keys are the leaf tokens, and the values are comma-separated monitor names. At each monitor invocation, the confguration timestamp is compared against the last known, and the cache database is rebuilt if needed.
monitor_alarms.db is a Hash database that keeps alarm status information from previous runs of Monitor, with the keys and values as follows:
When status is 1, the record is kept regardless of timestamps. When status is 0, and the current time is more than t_expires, the record is not reliable and may be deleted by Monitor.
collector_tokens.db is a Hash database used in order to avoid the unneccessary configuration tree walk. Keys and values are as follows:
scheduler_stats.db is a Btree database which stores the runtime statistics of Scheduler tasks. Each key is of structure <taskname>:<period>:<offset>:<variable>, and the value is a number representing the current value of the variable. Depending on variable purpose, the number is floating point or integer.
users.db is a Hash database containing user details, passwords, and group membership:
cn (Common name) or userPassword, are stored
here. For each user, there is a record consisting of the attribute uid,
with the value equal to the user identifier.
acl.db is a Hash database containing group privileges information:
DisplayTree, where
the object is the tree name.
The Framework will consist of several functional modules:
The configuration management module provides access methods for enumeration and enquery of the configuratin objects.
Upon activation, it checks the conditions for each leaf having a monitor. In case of the alarm, it executes the action instructions synchronousely.
Collector program supports two modes of invocation: daemon and one-time.
In daemon mode, it first runs all registered collectors. After that, the collectors are grouped depending on period and time offset, and launched periodically at the moments defined by formula:
time + period - (time mod period) + timeoffset
The datasources are grouped by collector type. For SNMP collector type, the datasources are grouped by host. SNMP requests are sent in non-blocking mode (see Net::SNMP Perl module manual).
For each SNMP host, system uptime is verified. For RRD datasource types ``COUNTER'', if the device reload is detected, the corresponding RRD file is updated with ``undefined'' value at the calculated moment of reload.
Copyright (c) 2002-2004 Stanislav Sinyagin ssinyagin@yahoo.com