Hi dojo,
I’m trying to understand the expected behavior of a Correlation rule when multiple base alarms are grouped and the first base alarm clears.
I have a Correlation rule with Autoclear, Update base alarms and Root time of base alarm enabled.
Example:
- Alarm A is triggered first.
- It has an
Alarm.Descriptionproperty defined by the protocol. - The correlated alarm takes the root time and
Alarm.Descriptionassociated with Alarm A.
- It has an
- Alarm B is triggered and becomes part of the same correlation.
- Alarm A clears, while Alarm B remains active.
What I observe is:
- The correlated alarm keeps the Root Time of Alarm A, even though Alarm A is no longer active.
- With the New alarm action,
Alarm.Descriptionstill seems to be associated with the parameter used to create the correlated alarm. - If that parameter is a table parameter and the corresponding row is removed,
Alarm.Descriptionbecomes empty, while the correlated alarm remains active. - I also tested the newer Group alarms action. The group alarm still keeps the initial root time, and
Alarm.Descriptionfrom the source alarms is not propagated to the group alarm.
I understand that a group alarm only exposes specific derived information, such as the correlation rule as parameter description and the highest severity of its base alarms, so arbitrary base-alarm properties not being copied may be expected. [docs.datam...r.services]
My questions are:
- Is it expected that the correlated/group alarm keeps the root time associated with the first alarm, even after that alarm has cleared and other base alarms remain active?
- For the New alarm action, is it expected that alarm properties such as
Alarm.Descriptioncontinue to be associated with the original base alarm parameter instead of being updated based on the remaining base alarms? - Is it expected that
Alarm.Descriptionbecomes empty if the original alarm came from a table row and that row is subsequently removed? - Is there a recommended way to have the correlated alarm represent the currently active base alarms, including an alarm property such as
Alarm.Description, instead of remaining associated with the first base alarm?
Thanks!
Hi Rafael, the key distinction is between updating the linked base alarms and changing the identity of the correlated alarm.
- Is the unchanged root time expected?
Yes. The New Alarm documentation defines “Root time of base alarm” as using the root time of “the base alarm that triggered its creation.” “Update base alarms” updates the linked-alarm list afterward.
In your example, A establishes the root time at creation. When A clears while B remains and the rule conditions still match, the existing correlated alarm is updated rather than replaced. Its root time therefore stays unchanged. The Group alarms action follows the same creation-time principle.
- Should
Alarm.Descriptionswitch to the remaining base alarm?Not automatically. With New Alarm, leaving the element and parameter unspecified creates the correlated alarm on the triggering base alarm's element and parameter. Subsequent membership updates retain that association.
A protocol-defined
AlarmDescriptionis metadata for that parameter, potentially overridden by an information template. It is not automatically selected again from the remaining base alarms. - Is an empty description after deleting the original row expected?
I would not classify that as expected without checking the reproduction. The alarm's continued association with the original row explains why it does not adopt B's description, but does not establish that the description should become empty. The exact Dataminer/Cube versions, protocol definition, and information template are needed to investigate this separately.
- How can the alarm represent the currently active base alarms?
The newer Group alarms action avoids the original connector parameter/row association by using the generic Dataminer element. It represents the group through the linked alarms, correlation rule name, and highest severity, but does not automatically combine arbitrary source-alarm descriptions.
For a dynamic summary, an evaluated alarm value can show information such as the base-alarm count. Combining descriptions from all active base alarms would require explicit aggregation logic, for example in an Automation script.