plugin_metric

Introduced in hub or robot version 7.96, plugin_metric is a dynamic library that is loaded into the spooler process. The plugin_metric post-processes QoS messages. The post-processing includes generating alarms according to static and dynamic thresholds, base-lining, or performing Time over Threshold. The plugin_metric is configured by default for the hub/spooler. The plugin_metric configuration file is the central place for all the alarm policies for all the probes of a robot.
uimpga-ga
HID_plugin_metric
Introduced in hub or robot version 7.96, plugin_metric is a dynamic library that is loaded into the spooler process. The plugin_metric post-processes QoS messages. The post-processing includes generating alarms according to static and dynamic thresholds, base-lining, or performing Time over Threshold. The plugin_metric is configured by default for the hub/spooler. The plugin_metric configuration file is the central place for all the alarm policies for all the probes of a robot.
Profile Updates
When you create a profile in UMP, the profile information is updated in the respective probe configuration file under the 
profile name
 tag. The spooler metric information is written to the plugin_metric configuration file under the
spooler-metrics
tag.
For example, if you create a profile "
Profile_"
for the dirscan probe, and the profile ID is
191
, then the profile-related information is displayed as follows in the dirscan.cfg file:
dirscan_cfg.PNG
Similarly, you can view the spooler metric information for the preceding example in the plugin_metric configuration file, under spooler-metric> probes> dirscan> and the profile ID -
191
plugin_metric_sample.PNG
Policy Updates
The thresholds and alarm variable-mapping information are written in the plugin_metric configuration file. When you create a policy in the Operator Console, the policy information is updated in the spooler plugin_metric configuration file, under the
spooler metrics
tag. This configuration also filters QoS (by mentioning what is enabled and what is not). If the alarm parameter is set to false, then no alarm processing is done on that QoS. 
If you configure the plugin_metric for probes which generate a large number of entries. We recommend that you create a dirscan alarm to calculate and monitor the number of files, size, and the space of the specified directory.
For example, if you create a policy that is named
28
for the dirscan probe, then the policy-related information such as, qos_name: 
QOS_DIR_NUMBER
and alarm threshold: 
345.0
 are displayed as follows:
Policy_spooler_metric.PNG
If a user configures Time To Threshold (TTT) and Time Over Threshold (TOT) with the probe UI, those will still be calculated in addition to TOT calculated by the spooler.
Verify plugin_metric Configuration
The plugin_metric is configured by default for the hub/spooler. You can verify the configuration in the hub or spooler configuration file.
Follow these steps:
  1. In the Admin Console, search for the spooler probe, and select
    View Config File
    .
  2. You find the
    plugin_metric
    tag in the plugins section as the following spooler.cfg illustrates:
    <spooler>
      debug = 5
      interval = 5
      duration = 5
      logfile = spooler.log
      spooling = off
      flush_timeout = 15 min
      flush_priority = 5
      flush_records = 1000
      expire = 7 day
      logsize = 10000
        <plugins>
        <plugin_metric>
             pluginPath = plugins/plugin_metric/plugin_metric.dll
             pluginName = plugin_metric
             configPath = plugins/plugin_metric/plugin_metric.cfg
             configSection = variables
             active = 1
        </plugin_metric>
      </plugins>
    </spooler>
Disable plugin_metric Configuration
To disable the plugin_metric configuration, follow these steps:
  1. Take a backup copy of the spooler.cfg file.
  2. Open the file in a text editor.
  3. Remove the
    plugin_metric
    section from the configuration file as the following snapshot illustrates:
    disbale_plugin_metric.png
  4. Save your changes.
  5. Restart the robot to implement the changes.
Review plugin_metric Information Using Spooler Callback
You can use the Infrastructure Management interface to check the plugin_metric information using the spooler plugin callback.
Follow these steps:
  1. Access the IM interface.
  2. Select spooler.
  3. Press Ctrl+P.
  4. Select and run the metric_plugin_info callback.
The metric_plugin_info callback shows the metric information; for example, version number, alarms sent, QoS messages processed, stored metrics, and so on.
Supported Alarm Policy Message Variables
plugin_metric supports the following alarm policy message variables:
  • ${metric_value}
     
    The current sample value for a metric.
  • ${qos_name}
    The name of the QoS metric.
  • ${metric_name}
    The name of a metric.
  • ${met_id}
    The ID of a metric.
  • ${component_name}
    The name of the component being monitored. For example: C:/ or CPU-0.
  • ${device_name}
    The name of a device being monitored.
  • ${device_target}
    The target of the QoS metric that generated an alarm.
  • ${probe_name}
    The name of a probe; for example, cdm.
  • ${threshold_type}
    The localized threshold type: static or dynamic %
  • ${threshold_sign}
    Use this variable before the ${threshold} variable. The ${threshold_sign} variable generates a + (plus) sign when the threshold is a positive integer.
  • ${threshold_symbol}
    Use this variable after the ${threshold} variable. The ${threshold_symbol} variable generates a percent symbol for dynamic percentage thresholds or a sigma symbol for dynamic standard deviation thresholds.
  • ${threshold_value}
    For static alarms, it is the configured threshold value. For dynamic alarms, it is the calculated threshold. For example, if the threshold is 5 percent of a baseline of 10, then the evaluated threshold value is 0.5.
  • ${policy_id}
    The ID of an alarm policy.
  • ${alarm_level}
    The numeric severity of an alarm. The severities are displayed as: 5 (critical), 4 (major), 3 (minor), 2 (warning), 1 (information), or 0 (clear).
  • ${threshold_operator}
    The operator that is configured with the alarm threshold. The operators are: >, >=, <, <=, ==, or !=
  • ${alarm_severity}
    The localized alarm severity. The levels are critical (5), major (4), minor (3), warning (2), information (1), or clear (0).
  • ${tot_time_window}
    The total window of time for which alarms are collected.
  • ${tot_sliding_window}
    The accumulated amount of time the metric needs to be over the threshold value within the total window ($tot_time_window} before for an alarm is issued.
  • ${tot_slider_window}
    The 'Time over' duration to calculate the time over threshold.
  • ${tot_time_window_unit}
    The localized measure of time: mins, hours, days.
  • ${tot_sliding_window_unit}
    The localized measure of time: mins, hours, days.
  • ${tot_slider_window_unit}
    The localized measure of time in mins, hours, days for 'Time over' duration to calculate the time over threshold.
  • ${metric_unit_short}
    The metric unit of metric_value in short format.
  • ${metric_unit}
    The localized unit of measure for a metric value. For example, 50 MHz.
  • ${metric_unit_long}
    The metric unit of metric_value in long format.
  • ${metric_baseline}
    The computed baseline value. 
     We recommend that you use the metric_baseline variable for dynamic threshold conditions because baseline is calculated for dynamic alarms.
  • ${origin}
    The origin that a probe publishes with each device. The published origin typically matches the origin of the robot where the probe is running.
  • ${subsys}
    The subsystem ID of the message.