Use qos_processor to enrich/modify QoS messages in DX UIM

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Guide on how to use qos_processor to enrich/modify QoS messages

Environment

• DX UIM 20.4.* / 23.4.*
• qos_processor any version

Cause

Guidance

Resolution

Background

The qos_processor probe is responsible for:

1. updating the Origin changes in the database when the Origin changes at the robot and hub
2. allowing custom enrichment of QoS metric properties

The qos_processor probe listens for QOS_MESSAGE subjects on the UIM bus, evaluates and potentially modifies some non-key attributes of the record corresponding to the monitor. The baseline_engine depends on qos_processor to save the QOS_BASELINE messages in the UIM database. Both the qos_processor and baseline_engine probes are automatically deployed to the primary hub by the CA UIM Server installer.


Instructions

Overview of QoS enrichment (modifying origin of QoS data)

The qos_processor probe uses a Ruby script (called "enrichment.rb") to specify "origin enrichment" - that is, adding a new/extra origin to an existing device through altering the origin on incoming QoS data.

A simple use case is included below. There is a lot of information on Ruby Scripting available on the web which you may find useful as well.

Example environment:

- A primary hub, with origin "OriginOne"
- A remote/secondary hub, with origin "OriginTwo"
- net_connect probe is on the primary hub, and sending net_connect data with "OriginOne" on the QoS
- net_connect probe monitors a Robot, called 'MyRobot', which reports to the secondary hub and has origin "OriginTwo" for the robot's discovered origin
- net_connect is set to send "MyRobot.Mycompany.com" as the QoS Profile name
- cdm probe is installed on MyRobot, and cdm QoS data has "OriginTwo" origin

Example Use case/purpose - you want the metrics from net_connect to show up for the same device as the robot metrics from CDM when it is displayed in UMP (USM).

Method: Automatcially alter the origin on the net_connect data to match the robot/cdm origin "OriginTwo" for that profile.

The enrichment.rb script contents would be as follows:

================= cut here =================
# lines starting with pound sign denote a comment
# sample enrichment.rb
require 'java'

if ( $monitor.probe == "net_connect")
if ( $monitor.source == "MyRobot.Mycompany.com" )
$monitor.origin = "OriginTwo"
end
end

# end of script
================= cut here =================

You could also decide to enrich any net_connect QoS which had "MyRobot" in it, whether FQDN or not:

================= cut here =================
# lines starting with pound sign denote a comment
# sample enrichment.rb
require 'java'

if ( $monitor.probe == "net_connect")
if ( $monitor.source.include? "MyRobot" )
$monitor.origin = "OriginTwo"
end
end

# end of script
================= cut here =================

Additional Information

• You can use the qos_processor probe to process raw QOS messages at their source, changing the origin before the messages are published to the data_engine/nas. The evaluation and modification of the attributes is done with the use of an enrichment script named enrichment.rb. – the qos_processor caches messages and then processes the script on an interval (by default every 60 minutes – controlled by a key in the qos_processor cfg file). The cache determines which qos messages to check and the update is done in the database. This is all done after the messages are stored by the data_engine.
  
  
  • Note: If an enrichment script exists for a QOS_MESSAGE, it will override an origin change done on the hub. However, an enrichment script is not required. If an enrichment script does not exist. only origin changes are made by the qos_processor.
• The qos_processor can function with and without a script. With a script you can control the origin changes. Without a script the probe will detect origin changes in the data being sent (ie a robot is moved from one hub to another and now sending data with the new hub’s origin) and update the origin based on the new one.

• This script should be located in <Nimsoft>/probes/slm/qos_processor/scripts/. Changes to the enrichment_rb script are dynamically loaded by the qos_processor probe. All fields will be bound into the script environment as member fields of a script object named "monitor." There is also a logging object named "logger" available for writing messages to the probe log file.
  
  
• Important! This probe cannot modify the QOS, SOURCE or TARGET fields as these are the keys that uniquely identify the data in the entire system.
  
  • Examples are provided in the Nimsoft\probes\slm\qos_processor\test directory.
    
    
  • Note that you can manually run your script and check the results. You run java -jar JRubyScriptRunner-1.1.jar and the output is logged to stdout:
    
    C:\Program Files (x86)\Nimsoft\probes\slm\qos_processor\test>"c:\Program Files (x86)\Nimsoft\jre\jre7\bin\java.exe" -jar JRubyScriptRunner-1.1.jar ..\scripts\enrichment.rb
    
    An additional sample script is attached to this Article.