Table Of Contents
The Databases of STORE
Intelligent storage of data
The System database
Persistent storage for topology events
The Kernel database
Persistent storage for Fault Mediator events
The Fault database
The system database schema
Example configurations of the system database
The kernel database schema
Examples of the state rules for NMOS persistent storage
The fault database schemas
Examples of the state rules for event persistent storage
Conclusion
The Databases of STORE
This section gives a complete description of the databases of the MWFM NMOS persistent storage system, STORE.
Intelligent storage of data
STORE utilizes a main database called the System database to adapt riv_store to consume records on a particular subject (a subject may be topology traffic from MODEL, event traffic from MONITOR, etc.) and a database for each subject that riv_store is configured to consume. Figure 30-1 outlines the tables contained in each database. These databases and the related schemata are discussed in detail in subsequent sections of this chapter.
Figure 30-1 The databases of STORE
The System database
The System database (system) is used by STORE to completely define the listening methodology. This database defines the subjects that should be listened for and the actions that STORE should initiate when these subjects are detected. The System database gives a definition of the time intervals between checks for referential integrity of the stored data. The System database is made up of three database tables, the snoopers table (system.snoopers), the rollUps table (system.rollUps) and the stateRules table (system.stateRules), which are discussed in detail below.
The snoopers table
The snoopers table stores a record for each subject STORE is to listen on. The contents of each record in the snoopers table are listed below.
•
The unique name of the subject to listen to.
•The database that will be the target of the actions specified when the subjects are detected by STORE.
•The specific database table that will be acted upon when the subjects are detected by STORE. The database table must be a member of the database mentioned above.
•The name of the rule that defines the methodology for creating a new subject record in the target database table.
•The name of the rule that defines the methodology for updating a subject record in the target database table.
•The name of the rule that defines the methodology for deleting a subject record in the target database table.
You can interpret each record in the snoopers table as follows: listen for a subject on the TIBCO Rendezvous™ bus and insert incoming subjects into the target base table that is a member of the target database and ensure that the rules record creation, record updating and record deletion are executed when the incoming subject is a subject create, subject update or a subject delete respectively.
The rollUps table
The rollUps table is used to configure how often riv_store executes the rollup rules that govern the referential integrity of the STORE database tables. Each record in the database table is the name of a rollup rule. Information stored about each rule is listed below:
•The name of the rollup rule.
•The exact minute of the hour that the rule is scheduled to be executed. If set to zero, the rule execution criteria for this field will have been met.
•The exact hour of the day that the rollup rule is scheduled to run. If set to zero, the rule execution criteria for this field will have been met.
•The exact day of the month that the rollup rule is scheduled to run. If set to zero, the rule execution criteria for this field will have been met.
•The date when the rule should be run.
•The exact month of the year that the rollup rule is scheduled to run.
•The exact year that the rollup rule is scheduled to run.
•The database that will be the target of the presently defined rollup rule.
•The database table within the above database that will be the target of the presently defined rollup rule.
•The rollup rule that will be invoked by the presently defined rollup rule. This implies that it is possible for you to configure a rule that is made up of another predefined rollup rule.
You can interpret each record in the rollUps table as follows: run rule rule name when the time is hour, minute every day day or on the date date of the month month number of year year. In addition, rule rule name should run the rollup rule roll-up rule name on the table name database table of the database name database.
The stateRules table
The stateRules table is where all the rules to be used by STORE in the creation, updating, deletion, and manipulation of records are completely defined, as well as the criteria that must be met before the rule can be executed. The information stored about each rule is listed below:
•The name of the rule.
•The conditions that must be met before the rule is executed, i.e., the scope of the rule.
•The lines of code that define the rule. These are the lines of code that will be executed when the rule is run.
•An activity status flag to determine whether the rule is currently running.
You can interpret each record of the stateRules table as follows: The rule known as rule name can only be executed when filter conditions are satisfied. The rule rule name is defined as one or more lines of code and the rule is presently activity status.
Persistent storage for topology events
The concept of STORE being able to listen to the TIBCO Rendezvous™ message bus was introduced; the following section shows how STORE is configured to store topology events. Topology events refer to any changes that occur to the discovered network topology that is distributed by MODEL.
STORE uses a database for every subject it is to listen to and hence, in order to store topology events, the Kernel database must be created; it is discussed below.
The Kernel database
STORE uses the Kernel database (kernel) to store the topology event stream. The Kernel database consists of two tables, the modelLog table (kernel.modelLog) and the activeModel table (kernel.activeModel), which are mirrors of the entityByName table of the MODEL database. They differ in that the modelLog table is a record of all entities within the network topology, while the activeModel table is a store of the current active network topology. Each table is discussed below.
The modelLog table
The modelLog table is a store of all the entities known in the network topology, regardless of their current status on the network. The modelLog table is the specified target database table of the snoopers table entry for NMOS topology events. This table is populated automatically when STORE starts up, but because it is not the target of the rules specified within the snoopers table, it does not get updated and hence, remains the `persistent store' of the network topology. Each record in the table represents a device in the network topology. The information stored about each device is listed below:
•The ObjectID of the network entity.
•The descriptive name of the network entity.
•A list of the all addresses for Layers 1 - 7 of the OSI model.
•The value of the sysDescr MIB variable.
•The entity type of the network entity.
•The Active Object Class to which the network entity belongs (if applicable).
•The value of the sysOID MIB variable for the network entity.
•The activity 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 flag used to denote whether the current network entity warrants an Active Object Class.
•The time when the network entity record was created.
•The last time when the network entity record was changed.
•The type of action associated with the record.
The activeModel table
The activeModel table is a store of all the active entities in the network topology. Because the activeModel table is the target database table for the rules within the snoopers table entry for NMOS topology events, it is constantly updated by changes (creates, updates and deletes) that occur to the network topology as a result of STORE being able to pick up the create, update and delete topology messages passed between MODEL and other MWFM NMOS components and processes. Thus, it is able to keep track of the active network topology. Similar to the modelLog table, the activeModel table is also a mirror of the entityByName table of the MODEL database. Each record in the table represents an active device in the network topology. The information stored about each device is listed below:
•The unique ObjectID of the network entity.
•The descriptive name of the network entity.
•A list of the all addresses for Layers 1-7 of the OSI model.
•The value of the sysDescr MIB variable.
•The entity type of the network entity.
•The Active Object Class to which the network entity belongs.
•The value of the sysOID MIB variable for the network entity.
•The activity 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 flag used to denote whether the current network entity warrants an Active Object Class.
•The time when the network entity record was created.
•The last time when the network entity record was changed.
•The type of action associated with the record.
Persistent storage for Fault Mediator events
Another important feature of STORE is its extensibility. You can configure STORE to listen to events from other MWFM network management applications (Fault Mediator, etc.) as they become available. This section demonstrates how to configure STORE to listen in on the event stream generated by MWFM and maintain persistent storage of events as they are generated.
Once again, STORE uses a database for every subject it is to listen to and hence, in order to store events, a database for the FAULT subject must be created. This database is called the Fault database and is discussed in sections that follow.
The Fault database
STORE uses the Fault database (fault) to store the event stream. The Fault database consists of one table, the events table (fault.events), which is simply a mirror of the event records that are passed from MONITOR to the Fault Mediator.
The events table
The events table is a master record of all events in the system. Each record in the table represents a complete event record. The information stored for each event record is listed below:
•The unique event ID.
•The associated entity name.
•The associated active object.
•The class of the associated entity.
•A textual description of the event.
•The name of the poll definition that created the event.
•The event type (event/data/alert).
•The OSI severity code of the event.
•The contact person for the generated event.
•The person to which the event has been assigned.
•An event acknowledgement flag to denote whether the event has been formally acknowledged.
•The location of the entity that generated the event.
•A list of associated events by correlating the eventID.
•The group to which the event belongs.
•The alert display glyph.
•The time the event was generated.
•The last time the event was changed.
•Number of identical events that have occurred.
•The type of alert (root cause or symptom).
•Action type (create/change/delete).
•The internal action associated with the event.
The system database schema
The schemata of the snoopers, rollUps, and stateRules tables are shown below.
Table 30-1 Synopsis of the system database and its tables
Database name
|
|
Database definition location
|
$RIV_HOME/etc/StoreSchema.cfg
|
Fully qualified database table names
|
|
Table 30-2 The snoopers table: system.snoopers
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
Subject
|
PRIMARY KEY
UNIQUE
NOT NULL
|
Text
|
The subject to listen to.
|
DataArea
|
NOT NULL
|
Text
|
The target database of the actions specified when the subjects are detected.
|
BaseTable
|
NOT NULL
|
Text
|
The target database table of the actions specified when the subjects are detected by STORE.
|
CreateRule
|
|
Text
|
The rule that is run to create records in the persistent store.
|
ChangeRule
|
|
Text
|
The rule that is run to update records in the persistent store.
|
DeleteRule
|
|
Text
|
The rule that is run to delete records from the persistent store.
|
Volatile
|
|
|
The table constraint. See "The OQL Language," for more information about this table constraint.
|
Example configurations of the system database
Configuring STORE to listen for topology traffic
The following example shows the OQL statements that configure STORE to listen for topology events in the network.
insert into system.snoopers
values
(
'RIVERSOFT.3.0.MODEL.NOTIFY','kernel','modelLog',
'modelCreate','modelUpdate','modelDelete'
);
|
Configuring STORE to listen for event traffic
The following example shows the OQL statements that configure STORE to listen in on the event stream:
insert into system.snoopers
values
(
'RIVERSOFT.3.0.EVENT.NOTIFY','fault','events',
'eventCreate','eventUpdate','eventDelete'
);
|
Table 30-3 The rollUps table: system.rollUps
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
Name
|
PRIMARY KEY
NOT NULL
|
Text
|
Name of the rollup rule.
|
SchedMin
|
|
Integer
|
Run on this minute.
|
SchedHour
|
|
Integer
|
Run on this hour.
|
SchedDay
|
|
Integer
|
Run on this day.
|
SchedDate
|
|
Integer
|
Run on this date.
|
SchedMnth
|
|
Integer
|
Run on this month.
|
SchedYear
|
|
Integer
|
Run on this year.
|
DataArea
|
|
Text
|
The target database of the actions to be carried out on the rollup rule.
|
BaseTable
|
|
Text
|
The target database of the actions to be carried out on the rollup rule.
|
RollupRule
|
|
Text
|
The rule with which to run the rollup.
|
Volatile
|
|
|
The table constraint. See Chapter 32 for more information about this table constraint.
|
Table 30-4 The stateRules table: system.stateRules
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
Name
|
PRIMARY KEY
NOT NULL
|
Text
|
Name of the rule.
|
Filter
|
|
Text
|
Rule execute criteria.
|
Execute
|
|
Text
|
The OQL statements to execute.
|
IsActive
|
Externally defined boolean data type
|
Integer
|
An activity status flag to determine whether the rule is currently running.
|
Volatile
|
|
|
The table constraint. See "The OQL Language," for more information about this table constraint.
|
The kernel database schema
The schemata of the Kernel database and the modelLog and activeModel tables are shown below.
Table 30-5 Synopsis of the kernel database and its tables
Database name
|
|
Database definition location
|
$RIV_HOME/etc/StoreSchema.cfg
|
Fully qualified database table names
|
|
Table 30-6 The modelLog table: kernel.modelLog
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
|
NOT NULL
|
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
|
|
Text
|
Class name of the network entity (if applicable).
|
EntityOID
|
NOT NULL
|
Text
|
Value of sysOID MIB variable of the entity.
|
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.
|
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.
|
Table 30-7 The activeModel table: kernel.activeModel
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
|
NOT NULL
|
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
|
|
Text
|
Class name of network entity, if applicable.
|
EntityOID
|
NOT NULL
|
Text
|
Value of sysOID MIB variable of the entity.
|
Status
|
Externally defined status data type
|
Text
|
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.
|
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.
|
Examples of the state rules for NMOS persistent storage
Example state rules
The following examples illustrate of the OQL inserts that constitute the state rules specified by the inserts made into the system.snoopers table when configuring STORE to listen to topology event information.
The following configuration defines the modelCreate state rule:
insert into system.stateRules values
(
'modelCreate','',
'insert into kernel.activeModel values (
eval(long,"&ObjectId"),
eval(text,"&EntityName"),
eval(list type text,"&Address"),
eval(text,"&Description"),
eval(int type entityTypes,"&EntityType"),
eval(text,"&ClassName"),
eval(text,"&EntityOID"),
eval(int type status,"&Status"),
eval(text,"&Security"),
eval(list type text,"&RelatedTo"),
eval(list type text,"&Contains"),
eval(int type boolean,"&IsActive"),
eval(time,"&CreateTime"),
eval(time,"&ChangeTime"),
eval(int type actions,"&ActionType")
);',
1
);
|
The following configuration defines the modelUpdate state rule:
insert into system.stateRules values
(
'modelUpdate','',
'delete from kernel.activeModel
where
(
ObjectId=eval(long,"&ObjectId");
);',
'insert into kernel.activeModel
values
(
eval(long,"&ObjectId"),
eval(text,"&EntityName"),
eval(list type text,"&Address"),
eval(text,"&Description"),
eval(int,"&EntityType"),
eval(text,"&ClassName"),
eval(text,"&EntityOID"),
eval(int,"&Status"),
eval(text,"&Security"),
eval(list type text,"&RelatedTo"),
eval(list type text,"&Contains"),
eval(int,"&IsActive"),
eval(time,"&CreateTime"),
eval(time,"&ChangeTime"),
eval(int,"&ActionType")
);',
1
);
|
The following configuration defines the modelDelete state rule:
insert into system.stateRules values
(
'modelDelete','',
'delete from kernel.activeModel
where
(
ObjectId=eval(long,"&ObjectId")
);',
1
);
|
The fault database schemas
The schemata of the Fault database and the events table are shown below.
Table 30-8 Synopsis of the fault database and its tables
Database name
|
|
Database definition location
|
$RIV_HOME/etc/StoreSchema.cfg
|
Fully qualified database table names
|
|
Table 30-9 The events table: fault.events
Table column name
|
Properties (column constraints)
|
Column data type
|
Description
|
EventId
|
PRIMARY KEY
NOT NULL
UNIQUE
|
Long Integer
|
The event ID.
|
EntityName
|
PRIMARY KEY
NOT NULL
|
Text
|
The network entity associated with the event.
|
ObjectName
|
PRIMARY KEY
NOT NULL
|
Text
|
The associated Active Object.
|
ClassName
|
PRIMARY KEY
NOT NULL
|
Text
|
The associated entity.
|
Description
|
|
Text
|
A textual description of the event.
|
EventName
|
|
Varchar (256)
|
Name of the poll that created the event.
|
EventType
|
Externally defined eventType data type
|
Integer
|
Type of event (event/data/alert).
|
Severity
|
PRIMARY KEY
NOT NULL
Externally defined severity data type
|
Integer
|
The OSI Severity code.
|
Contact
|
|
Text
|
The contact person responsible for the device that generated the event.
|
AssignedTo
|
PRIMARY KEY
NOT NULL
|
Text
|
The person that has been assigned the event.
|
Acknowledged
|
PRIMARY KEY
NOT NULL
Externally defined boolean data type
|
Integer
|
Flag denoting whether or not an event has been acknowledged.
|
Location
|
|
Text
|
Location of the device that generated the event.
|
CorrelatedId
|
|
List of type Long Integer
|
List of associated eventIDs.
|
EventGroupId
|
PRIMARY KEY
NOT NULL
|
Long Integer
|
List of associated events.
|
ActionGlyph
|
|
Text
|
Alert display glyph.
|
CreateTime
|
|
Long
|
Time of first occurrence of event.
|
ChangeTime
|
|
Long
|
Time of last occurrence of event.
|
Occurred
|
|
Integer
|
Number of identical events that have occurred.
|
CauseType
|
Externally defined causes data type
|
Integer
|
The type of alert (symptom or root cause).
|
ActionType
|
Externally defined actions data type
|
Integer
|
The type of action that the event represents.
|
InternalAction
|
Externally defined internalActions data type
|
Integer
|
The internal action associated with the event (new/acknowledged/unacknowledged).
|
Examples of the state rules for event persistent storage
Example state rules
The following are examples of the OQL inserts that constitute the state rules specified by the inserts made into the system.snoopers table when configuring STORE to listen to event information.
The following configuration defines the eventCreate state rule:
insert into system.stateRules
values
(
'eventCreate','',
'insert into fault.activeEvents values (
eval(long,"&EventId"),
eval(text,"&EntityName"),
eval(text,"&ObjectName"),
eval(text,"&ClassName"),
eval(text,"&Description"),
eval(text,"&EventName"),
eval(int,"&EventType"),
eval(int,"&Severity"),
eval(text,"&Contact"),
eval(text,"&AssignedTo"),
eval(int,"&Acknowledged"),
eval(text,"&Location"),
eval(list type long,"set(&EventGroupId)"),
eval(int,"&EventGroupId"),
eval(text,"&ActionGlyph"),
eval(time,"&CreateTime"),
eval(time,"&ChangeTime"),
eval(int,"&Occurred"),
eval(int,"&CauseType"),
eval(int,"&ActionType"),
eval(int,"&InternalAction")
);',
1
);
|
The following configuration defines the eventUpdate state rule:
insert into system.stateRules values
(
'eventUpdate','',
'delete from fault.activeEvents
where
(
EventId=eval(long,"&EventId")
);',
'insert into fault.activeEvents values
(
eval(long,"&EventId"),
eval(text,"&EntityName"),
eval(text,"&ObjectName"),
eval(text,"&ClassName"),
eval(text,"&Description"),
eval(text,"&EventName"),
eval(int,"&EventType"),
eval(int,"&Severity"),
eval(text,"&Contact"),
eval(text,"&AssignedTo"),
eval(int,"&Acknowledged"),
eval(text,"&Location"),
eval(list type long,"&CorrelatedId"),
eval(int,"&EventGroupId"),
eval(text,"&ActionGlyph"),
eval(time,"&CreateTime"),
eval(time,"&ChangeTime"),
eval(int,"&Occurred"),
eval(int,"&CauseType"),
eval(int,"&ActionType"),
eval(int,"&InternalAction")
);',
1
);
|
The following configuration defines the eventDelete state rule:
insert into system.stateRules values
(
'eventDelete','',
'delete from fault.activeEvents
where
(
EventId = eval(long,"&EventId")
);',
1
);
|
Conclusion
This chapter has shown how STORE uses a series of databases to store information associated with FAULT specific or topology specific event streams. STORE essentially acts as a log of transactions between other MWFM NMOS components or network management applications.
The next chapter describes how to configure the NMOS component DIST.
