By default opEvents combines information from the actual input sources, NMIS and policy actions to populate an event with relevant details. However, for situations where the autoritative source of knowledge of nodes and environments is external to opEvents and NMIS, is also possible to collect such information from an SQL database. At present opEvents only support MySQL databases for external enrichment.
To use external enrichment it is necessary to define the relevant source databases and event actions that pull informaition from these databases.
The configuration file conf/EventDB.nmis contains the settings for the external databases, and is only consulted if the option opevents_db_enrichment (in conf/opCommon.nmis) is activated. Here is an example enrichment db setup:
"cmsdbA" => # db name cannot be be 'event' or 'node'
{
db_host=>"thor",
db_port=>"3306",
db_driver=>"mysql", # currently the only supported driver
db_name=>"opexport",
db_user=>"enrichment",
db_password=>"poor",
db_cache_age=>120, # how long until a query must be re-executed.
# all node.X and event.Y occurrences on the right of the WHERE are replaced by
# opEvent's node/event data.
# queries therefore CANNOT use column names or table.column expressions like node.X
# or event.Y in the WHERE expression.
queries=> {
"test1" => "SELECT * FROM nodeProperties WHERE node.name = name and property = 'util_out' ",
"test2" => "SELECT * FROM nodeStatus WHERE from_unixtime(event.time) > lastUpdate and node.name = name ",
},
},
The configuration above defines two access queries for use in an action policy, which will be rewritten at evaluation time: all tokens of the form node.X and event.Ywill be replaced by the respective node and event properties. As external queries can be expensive and time-consuming, opEvents supports the caching of query results - please note, however, that caching depends on all the input values to the query and as a consequence some queries like example test2 above are not cacheable in practice.
Making use of an external enrichment database takes place exclusively in an event action rule's IF clause, like in the following example:
# syntax: dbname.queryname.column_to_return
'30' => {
IF => 'cmsdbA.test1.id > 10 AND cmsdbA.test2.name eq node.name',
THEN => "log.tmp()"
}
In the example action rule, the expression cmsdbA.test1.id is interpreted as "execute query test1 on database cmsdbA with the details from this event and node, and return the column id from the result", which is then used in subsequent comparisons.