alarm_enrichment Raw Configuration

The alarm_enrichment probe is configured using the Raw Configure option in the nas probe. The configuration settings for this probe are stored in the nas configuration file. Memory settings for the alarm_enrichment probe are maintained in the startup/opt section of the alarm_enrichment Raw Configure option.
uimpga-ga
The alarm_enrichment probe is configured using the Raw Configure option in the nas probe. The configuration settings for this probe are stored in the nas configuration file. Memory settings for the alarm_enrichment probe are maintained in the startup/opt section of the alarm_enrichment Raw Configure option.
The alarm_enrichment configuration settings are contained in the enrichment-source, enrichment-rules, and routing-rules sections of the raw configuration for the nas probe. The alarm_enrichment probe subscribes to "alarm" messages, modifies the alarm and submits a new message to the nas with a modified subject of "alarm2." The alarm_enrichment probe processes the enrichment and routing rules in alphanumeric order. The nas probe subscribes to the "alarm2" messages.
Users are allowed to change the subject (queue) names. By default, alarm_enrichment probe uses the "alarm" subject and forwards messages to the "alarm2" subject for the nas probe. If the subject name is changed, the content in the queues will be lost.
Note:
The alarm_enrichment probe processes the enrichment and routing rules in alphanumeric order. You can determine the order in which the rules are processed by using a naming convention for the section names that dictate the order, such as 1, 2, 3.
Contents
Setting up cmdbs Environment
In the CMDBs section you define one to many data sources from which to read data.
cmdb.png
Each CMDB requires a name/tag to uniquely identify the enrichment-source for subsequent enrichment-rules sections. In the example provided we have used os_enricher as the CMDB name. The CMDB allows you to set the following parameters:
  • active
    Allows you to activate or deactivate the CMDB
  • connection_url
    The url to the database
    Examples
    :
connection_url = jdbc:oracle:thin:@//172.17.4.12:1521/ORCL
connection_url = jdbc:sqlserver://172.17.8.12:1433;DatabaseName=CA_UIM;
connection_url = jdbc:mysql://172.17.0.12:3306/choslm
  • user
    The user login name for the database
  • password
    The password associated with the database user. The password is entered in plain text, however it is encrypted and stored in its encrypted form in the configuration file.
  • population_query
    The pre-population non-targeted query that will be executed on startup of the probe and at regular intervals. There should not be a "?" in this query as no ID substitution will occur. This query is placed in the alarm_enrichment cache for quick retrieval. The following example gathers
    name
    ,
    ip
    , and
    os_type
    .
    Name
    and
    ip
    are used to help match the alarm and
    os_type
    is used for updating
    custom_4
    .
    Example:
    select name,ip,os_type from cm_computer_system
  • query
    This query is a targeted query (of the population_query) used to gather a single item and is executed if the data required is not returned from cache. Specify a "
    ?
    " where the ID of the item can be filled in with your query.
    Example:
    select name,ip,os_type from cm_computer_system where name=?
Setting up Enrichment Rules
The enrichment rules define the actual alarm enrichment process. First you must define what alarms to match and then you must define the values to add/overwrite in the alarm.
enrichment_rules_IM.png
The alarm matching parameters are:
  • use_enricher
    Enter the name of the cmdb enrichment source
  • match_alarm_field
  • match_alarm_regexp
    This pair of parameters are used to identify messages to be enriched.
    The first identifies the PDS field to match upon and the second identifies legal values. In our example, we will use the value contained in the the “prid” field. And, we will enrich the message only apply enrichment when "prid" field (in the incoming message) matches one of the regular expressions "cdm" or "controller" or "hub."
  • lookup_by_alarm_field
  • lookup_by_regexp
    Identify the alarm field you want to match in the enrichment-source.
    Consider your enrichment-source specifies the following query:
    select name,ip,os_type from cm_computer_system where name=?
    In this example, the ‘name’ column (in our enrichment-source DB) happens to represent the computer name. Notice that the configuration suggests that the value for the "robot" field in the incoming message will be substituted (in prepareStatement) for the "?".
    If your robot name was 'robot123', then your query becomes:
    select name,ip,os_type from cm_computer_system where name='robot123';
    Enter the alarm field you want to match in the data source.
Example
If you configure alarm_enrichment using the following values:
  • match_alarm_field = udata.message
  • match_alarm_regexp = (enrich)
  • lookup_by_alarm_field = udata.source
  • lookup_by_regexp = ([test1-5]+)
Then the following occurs:
  1. alarm_enrichment checks to see if the udata.mesasge field in the alarm message contains the phrase "enrich".
  2. If no match is made, no further actions are taken on the alarm.
  3. alarm_enrichment then uses the value in the lookup_by_regexp field to further filter enrichment. In this case, alarm_enrichment checks to see if the udata.source field in the alarm message contains test1, test2, test3, test4, or test5.
  4. If no match is made, no further actions are taken on the alarm.
  5. If a match is made, the enricher looks in the database using the query that was defined in the query parameter. The “?” in the query is replaced with the value in the lookup_by_alarm_field.
  6. If a match is made, the alarm is enriched using the values configured in the overwrite-rules
Overwrite Rules
overwrite_rules.png
Many fields in a message can be enriched at the same time. The query may have many fields/columns returned. Each overwrite rule specifies one field in each alarm to be modified.
The key contained in the alarm will be replaced by the value returned from the query. Content in square brackets "[ ]" will be replaced based upon your query results. Contents without the square brackets will be static content.
Alarms can be multi-hierarchical and the parameter you want to modify might not be in the main structure of the incoming alarm, but in a substructure such as udata. You must use the full address (hierarchical path) to the parameter.
Setting up Routing Rules
The routing rules allow you to send alarms under different subjects, or even to different targets, depending on the field values.
Each routing rule needs a unique name. The routing rules are executed in alphanumeric order.
routing_rules.png
The routing rule parameters are:
  • active
    Indicates whether the rule is active or not.
  • post_subject
    The new subject the alarm will be sent with to the nas.
    The alarm_enrichment probe contains two default routing rules, one for alarms sent to the nas, the other for storm protection.
  • condition
    Condition must be set to
    true
    . If condition is not set to true, the rule will not run.
Flood protection
Flood (also called "storm") protection allows you to automatically enable/disable rules based on the amount of alarms being processed per minute. This functionality is configured in the nas GUI. You can specify one of four states for this protection: disabled, suppression id, probe or robot.
When flood/storm protection is enabled, the alarm messages considered part of a storm can be sent out using an alternate subject, such as "NAS_QUARANTINE". This will only work if another probe (or listener) subscribes to the subject "NAS_QUARANTINE".
Default flood protection requires the following parameters:
  • routing_rules_during_flood
    Determines the routing rule to use during a message storm. Default subject is NAS_QUARANTINE and the messages are sent to the subscriber for this subject.
  • routing_rules_no_flood
    Determines the routing rule to use for alarms not in a storm condition. Messages are sent to the nas probe.