Idea Details

Make UIM components compatible with each other, case ToT + ae

Last activity 12-19-2016 09:22 AM
ttahkapaa's profile image
09-05-2016 12:20 AM

UIM has had features for alarm_enrichment and ToT/TtT already for several versions, but we have found out (support and development have also confirmed) that we are not able to use those features together if we have more than one hub.


Currently alarm_enrichment probe is needed in every hub where you want monitor those advanced alarming features like Time-over-Threshold or Time-to-Threshold. Now this need of alarm_enrichment makes some things a bit nastier, it reads now all the "alarm" messages and converts them to "alarm2"s, OK those can then be sent to primary hub, but if we have an alarm_enrichment running on that primary hub doing the real enrichment there then the message flow is kind of broken because the primary hub gets alarm messages with subject "alarm" from its own probes + other robots connected directly to that hub, and it gets "alarm2" messages from other hubs. There is no way to make ae nor nas to read two messages types. Nor there is no way to make probes send "alarm2"s.


And the situation is still the same even if you use ems.


As I see it, this requires a magic that reverts those "alarm2"s to "alarm" messages before they hit the primary hub's alarm_enrichment probe. Or then ae should be able to read both subject types and send them like "alarm3" to nas/ems.


Current solution proposal for us has been: "build your own software to handle this!" "Works as designed".


09-06-2016 06:13 AM


so far support and development have informed that we need to have to alarm_enrichment probe in remote hubs also, handling those ToT/TtT monitoring, and that probe then converts those "alarm"s to "alarm2"s and that way remote nas is also handling "alarm2"s and forwarding them. And that way alarm messages from remote hubs are "alarm2" but those coming coming.


Then if we take the alarm_enrichment away from the remote hub, then no ToT/TtT. And the requirement is to have those advanced alarming AND enrich those messages centrally.


(Yes I have not [yet] debugged this, this information in based on answers from development and support)

09-05-2016 10:07 PM

It is ok that any robots in the Primary HUB sends "alarm" to the Primary HUB so that alarm_enrichment in the Primary HUB pick it up and convert that to "alarm2" for NAS in the Primary HUB.


This is how we can handle "alarm" subject coming from remote HUBs when NAS is also running in the remote HUBs.


- Let "alarm" subject (coming from remote HUB) to be carried out through NAS forwarding feature.

- Configure HUB queue NOT TO carry "alarm/alarm2" on.

09-05-2016 09:46 AM

Hi Yu,


nope, the issue is not sending those messages from a hub to another. The issue is that now remote hub sends "alarm2" messages and primary hub and its robots are sending "alarm" messages, then what we should send to alarm_enrichment probe that is running in primary hub? And what messages then sent to nas running on primary hub?


Need for alarm_enrichment probe in remote hubs is the real issue here, that breaks the normal alarm flow.



09-05-2016 01:21 AM


If you have multiple hubs where NAS/AE running, you can set up NAS forwarding feature to send alarm2 message from remote HUB to the Primary HUB. The NAS forwarding feature does not use HUB queue.

Does it resolve your concern ?