It is easy to configure based on your comfort level with MRL [refine rule phase] or Policy [Enrichment Policy]. Below links are for TrueSight version 10.5.00 but functionality and syntax remains same for lower versions of BPPM as well.
Hope it helps
Can you do any example of configuration?
Can you provide the use case scenario, I will explain the same.
Step 1) event generated by BPPM;
Step 2) If this event is about to change its severity then I want that BPPM create a new event equal to previous event described with the new severity.
The first event must remain with first severity that it had.
This is out of box feature of BPPM [default enabled MRL in cell]. For example, you are monitoring CPU Utilization of a server with 80% threshold for Warning and 90% threshold for CRITICAL. For instance, when utilization is 82% during 10:00 AM poll, then a WARNING event will be received in cell and during 10:15 poll, if utilization is 94%, a new event will be received in cell but default enabled MRL will de-duplicate the existing event and update the event slots [severity, parameter value, message, etc.,] and drop the NEW event.
But if you have a requirement to keep WARNING event OPEN and create a NEW CRITICAL severity event, it is very well possible. You need to identify the MRL for de-duplication and review it and disable it from .load file or comment out a specific section in default rule.
Can you export a sample event in baroc format and share it. This will provide the default MRLs execution and which rule is responsible for de-duplication
Hope it helps
I cannot to identify the MRL for de-duplication...
Please could you suggest me any MRL custom code to reach my feature desired?
I'm not sure why you would want to do this, and do not necessarily suggest it. I think you'll unnecessarily generate many events, and eventually force good events to be cleaned out of the event database to make room for these new events. So, I think that you may not like the long term results... however, I do not know the full use case.
Plus, you would not want to do this on internal events (ALARM, ABNORMALITY) generated by rate, because those new events would not have any correlation in the database to the alarm that rate knows about.
So, such an example should only be used on external (non Rate generated) events. Is that your intention?
That being said, here's an example (use at your own risk):
execute generate_new_severity_event: EVENT ($EV)
where [ CLASS: outside [ALARM, ABNORMALITY] ]
if ($EV.severity != $EV.mc_original_severity) then
$NEWSEVERITY = $EV.severity;
$EV.severity = $EV.mc_original_severity;
msg = $EV.msg,
mc_parameter = $EV.mc_parameter,
severity = $NEWSEVERITY
#continue adding as much to the new event as you like
I haven't tested this rule, and I do not necessarily recommend using it because of the above stated reasons... You may not like what this does to your environment.
As you mentioned, this is not a recommended approach however I have seen Customers requesting the functionality mainly for Reporting & Incident tracking.
In my opinion, it will be easier to identify the default MRL responsible for de-duplication and comment it out or customize to the requirement [for instance, have ECF for rate events and exempt for external events].
From BPPM Operations console, export a sample event in BAROC format where same event is updated with new severity and share it. This will provide details of default MRLs executed for the event.
Below I insert the export of event updated with new severity:
itsm_model_version='ProLiant DL360 G4p';
mc_operations=['0x587276c3','user10','','IBRSDBEM','ibrsd','0x586d16ca','mc_ci_policies.mrl:refine ci_based_enrich_policy_rule','ITSM_Categorie','CI based enrichment',''];
msg='Logical Disk Free Space < 4% for 30 min.';