The XML configuration is compiled into the database representation by operator's manual request.
The compiled version of configuration is not a one-to-one representation of the XML version. All aliases and templates are expanded. The backwards restoration of XML from the database is available with the snapshot utility.
Aliases are the way to represent the data in a more convenient 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 can be nested.
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 XML configuration compiler validates all the mandatory parameters.
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_DSINST.db and other_config_OINST.db.
These databases have similar structure, and
ds_config_DSINST.db keeps all datasource-related information.
DSINST
and OINST
stand for the productive instance number,
and have values of 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 /var/torrus/db/sub/>tree_name< directory.
The runtime modules access the configuration via ConfigTree
objects.
Each datasource subtree or leaf is identified by a token. A token is a short alphanumeric string, generated internally. Two types of tokens are recognized: single tokens and token sets.
Single token starts with letter T. The rest is made with 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 lower case 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. Also the compiler adds an entry compiling:<tree_name>
during the compilation time, in order to avoid two compiler processes
running at the same time on the same tree.
ds_config_DSINST.db is a Btree database, with the keys and values defined as follows:
Gives the token correspondig to the given element name.
Gives the path name by the given token.
For given subtree, contains the list of child tokens separated by comma.
For given subtree or leaf, contains the parent token.
Contains the parameter value for specified leaf or subtree. Each leaf or subtree inherits parameters from its parent. Thus, we must climb up the tree in order to get the parameter's value if not defined locally.
Contains the list of parameter names for specified leaf or subtree.
If this subtree or leaf is an alias, specifies the reference to the real node.
Specifies all alias subtrees or leaves pointing to this token.
Definition value for the given name
List of all known definitions
Defines a node type. Type is a number with the following values: 0 for subtree, 1 for leaf, 2 for alias.
other_config_OINST.db is a Btree database, with the keys and values defined as follows:
When nonzero, the configuration is ready for usage. Otherwise, the configuration status is undefined.
Contains the parameter value for specified view, monitor or action.
Contains the list of parameter names for specified view, monitor, or action.
Specifies comma-separated list of all views defined.
Specifies comma-separated list of view names for the path given. The first view in the list is interpreted as default.
Specifies comma-separated list of all monitor names defined
Comma-separated list of actions defined
paramprops_DSINST.db is a Btree database for storing the datasource parameter properties, such as expandable, list parameters, searchable, etc.:
aliases_DSINST.db is a Btree database with alias 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:
Keeps the list of all known token sets.
For given tokenset, keeps its contents.
nodepcache_DSINST.db is a Btree database containing the cached node parameter values. The keys and values are as follows:
Keeps the status and the value for a given token and parameter.
Status is a one-byte prefix, with values 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:
For the leaf/subtree and view name given, specifies two timestamps: the moment of last rendering and expiration time. The filename is automatically generated unique name in the spool directory. The contents type is determined by the MIME type.
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:
Key consists of the leaf token and monitor name. In the value, t_set is the time when the alarm was raised. If two subsequent runs of Monitor raise the same alarm, t_set does not change. t_expires is the timestamp that shows when it's still important to keep the entry after the alarm is cleared. status is 1 if the alarm is active, and 0 otherwise. t_last_change is the timestamp of last status change.
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:
For each leaf token, period and time offset values are stored.
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:
User attributes, such as 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.
Comma-separated list of attribute names for the given user.
For each user ID, stores the comma-separated list of groups it belongs to.
Group attributes, such as group description.
Comma-separated list of attribute names for the given group.
List of all groups
acl.db is a Hash database containing group privileges information:
The entry exists if and only if the group members have this privilege
over the object given. Most common privilege is DisplayTree
, where
the object is the tree name.
serviceid_params.db is a Btree database containing properties for each Service ID (exported collector information, usually stored in an SQL database):
Lists all known service IDs
Lists service IDs exported by a given datasource tree.
Parameter value for a given service ID. Mandatory parameters are:
tree
, token
, dstype
. Optional: units
.
List of parameter names for a service ID.
searchwords.db is a Btree database with DB_DUP and DB_DUPSORT flags. It contains the search strings for the given tree:
For a given keyword, refer to a path of a node that contains this word. If the node name matches the keyword, the param element is omitted. Otherwise it refers to the parameter that matches the keyword.
globsearchwords.db is a Btree database with DB_DUP and DB_DUPSORT flags. It contains the search strings for all trees:
For a given keyword, refer to a path of a node that contains this word. If the node name matches the keyword, the param element is omitted. Otherwise it refers to the parameter that matches the keyword.
The Torrus framework consists of several functional modules:
Once the configuration XML files get changed, the configuration compiler should be run manually. This guarantees that the actual framework configuration is changed only when the files are ready.
The configuration management module provides access methods for enumeration and enquery of the configuratin objects.
Collector program runs as a separate process for each datasource tree. Upon startup, 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.
This module performs the monitoring tasks periodically, based on each monitored leaf schedule. It checks the conditions for each leaf having a monitor. In case of the alarm, it executes the action instructions synchronously.
Upon a request, this module generates the graph and HTML files for the requested view and its subviews. It first checks availability of cached objects and avoids unneeded regeneration. It must be possible to force the renderer to flush the cache.
Web interface module passes the Renderer output to an HTTP client.
Copyright (c) 2002-2005 Stanislav Sinyagin ssinyagin@yahoo.com