Hi Dojo,
I've come across some alarm entries that are loaded in CUBE without the "correlated" icon,
despite being generated by the correlation engine:
This is found in
Server version : 10.3.0.0-13184 (10.3.0 CU5)
Client version : 10.3.2243.13316-c0f46547
Launcher version : 10.4.2413.720-1c47f2f3
Polling is used on the client as the ephemeral ports for eventing are not whitelisted on the server -wondering if this might play a part or if there's a different reason behind the different icons loaded.
Any steer will be helpful.
Thanks
Monitoring the behaviour after the upgrade to 10.5 CU4.
Will update this thread accordingly
Hi Alberto,
The 'correlation' icon is set when we receive 'CorrelationDetails' together with the alarm. This is an extra event we actually expect for every Correlation alarm that is active in the DMS, so for some reason, we have not received the 'CorrelationDetails' for those alarms.
What type of alarm list are we looking at actually? Does it contain history alarms maybe? (or maybe a sliding window, where active and history are mixed?) That would explain why we did not receive the 'CorrelationDetails'.
And we should probably change the software so we show the correlation icon whenever the source is Correlation Engine...
Thanks Pieter – indeed, the expectation was that the icon would reflect every entry where the correlation engine is the source: we can have sliding windows in some of our use cases, that might possibly explain – will monitor the behaviour in 10.5 CU4 and report back
Marking this as "solved" as the behaviour is no longer present in our environment – unsure if we that was because of the DM upgrade or the modification to remove sliding windows where viable: Pieter, would you be able to confirm if the behaviour changed with 10.5 CU4?
Thanks
Hi Alberto,
Thank you for keeping this question up2date with your recent findings!
I did a quick scan and could indeed find fixes that could explain why this is no longer affecting your DMS after the upgrade to 10.5 CU4. One that is most plausible is the fix with ID40934 where the issue was a race condition related to agents reconnecting after connection was lost.
Great news, Pieter – in case this comes up again, we'll use the fix ID to tell the differences – many thanks
I see that this question has been inactive for some time. Do you still need help with this? If not, could you select the answer (using the ✓ icon) to indicate that no further follow-up is needed?