CA UIM - log_monitoring_service alarm message customization
Article ID: 111224
Updated On:
Products
DX Infrastructure Management
NIMSOFT PROBES
Issue/Introduction
I have some questions regarding the log_monitoring_service probe for log analytics.
Which is the full list of variables that can be used in the alarm message when configuring a log_monitoring_service alarm with MCS?
For instance, the MCS template proposes this message when configuring an alarm:
"Match found for $profileName search string $query in message: $result"
which is using 3 different variables. I would like to know the full list of variables that can be used.
Environment
Release:
Component: UIMLMS
Component: UIMLMS
Resolution
The default alarm message variables($profileName, $query and $result) are specific to log_monitoring_service probe itself and not generic. These are actually placeholder variables which are replaced by associated values in the generated alarm messages. Please find their specific replacement values for respective variables as under:
- $profileName: In the actual alarm message generated by the probe, this variable would be replaced by name of the probe profile which caused the generated alarm.
- $query: In the actual alarm message generated by the probe, this variable would be replaced by the Elasticsearch string/query against which the match was found which generated an alarm.
- $result: In the actual alarm message generated by the probe, this variable would be replaced by elasticseach document’s key-value pairs. This elasticsearch document contains any attribute(s) satisfying the matching criteria. Also, this document would be part of an elasticsearch index on which the search applies.
If you are using the latest version of the probe(i.e. log_monitoring_service-1.2.0), then you would get $message variable as well which gets replaced by message attribute’s value of ingested logs.
Typing ${ in the message field via the Admin Console allowed me to list these variable (it does not work via the MCS profile).
baseline, level, operator, predictionValue, qosReference, qos_name, qos_source, qos_target, source, target, threshold, threshold_sign, threshold_symbol, threshold_value, tttTime, tttTimeUnit, tttValue, unit, value.
If you go to the below link, under Section 8 is a list of alarm variables and descriptions:
https://docops.ca.com/ca-unified-infrastructure-management-probes/ga/en/how-to-articles/configuring-alarm-thresholds#ConfiguringAlarmThresholds-dynamicppmv3.24ForHubsRunningppmv3.24andLater
- $profileName: In the actual alarm message generated by the probe, this variable would be replaced by name of the probe profile which caused the generated alarm.
- $query: In the actual alarm message generated by the probe, this variable would be replaced by the Elasticsearch string/query against which the match was found which generated an alarm.
- $result: In the actual alarm message generated by the probe, this variable would be replaced by elasticseach document’s key-value pairs. This elasticsearch document contains any attribute(s) satisfying the matching criteria. Also, this document would be part of an elasticsearch index on which the search applies.
If you are using the latest version of the probe(i.e. log_monitoring_service-1.2.0), then you would get $message variable as well which gets replaced by message attribute’s value of ingested logs.
Typing ${ in the message field via the Admin Console allowed me to list these variable (it does not work via the MCS profile).
baseline, level, operator, predictionValue, qosReference, qos_name, qos_source, qos_target, source, target, threshold, threshold_sign, threshold_symbol, threshold_value, tttTime, tttTimeUnit, tttValue, unit, value.
If you go to the below link, under Section 8 is a list of alarm variables and descriptions:
https://docops.ca.com/ca-unified-infrastructure-management-probes/ga/en/how-to-articles/configuring-alarm-thresholds#ConfiguringAlarmThresholds-dynamicppmv3.24ForHubsRunningppmv3.24andLater
Feedback
Powered by
