Idea Details

UIM : Option to suppress robot inactive alerts when device is placed in maintenance from UMP

Last activity 07-08-2019 02:32 AM
Phani Devulapalli's profile image
09-20-2017 08:45 PM

Please add an option/logic to suppress robot inactive alerts when device is placed in maintenance from UMP.

 

Robot inactive alerts generated by HUB are not normally suppressed when the specific device is placed in maintenance mode. When ever a robot is placed in maintenance we expect all the alerts that are generated against that robot are to be suppressed, but this doesn't normally happen .

 

Just to avoid this situation we have to create a pre-processing rule in NAS to suppress all the alerts generated by the device . Maintenance mode in UMP seems to be completely useless against the robot inactive alerts and the purpose of the maintenance mode itself is defeated here .

 

Most of the cases devices are placed into maintenance by non administrative users like the Windows team or the Unix team who do not have access to the IM console or do not have the needed knowledge to open NAS probe and configure a rule in addition to setting the device in maintenance from UMP. In most of the cases a UIM admin needs to step in and create a pre-processing rule and this becomes quite a tedious task in a large scale environment where multiple changes are scheduled during the day.

 

In addition to the robot inactive alerts we do have a similar issue with alerts generated by net_connect probe for ping tests as they do not get suppressed when maintenance is set from UMP

 

Adding the logic to suppress all the alerts generated against the device/robot including the robot inactive alerts and alerts generated by other probes like net_connect would be of great help

 

Refer below

 

Robot inactive alerts not suppressed when device is placed in maintenance ? 


Comments

07-08-2019 02:32 AM

It's now July 2019, two years after the idea posted.

Has this been implemented at all? Can someone from Broadcom comment on this please.

This is a basic functionality that just isn't working at all. Don't talk about wishlisting, this is a bug!

Maintenance mode in UIM is completely useless. We now have a customer who is moving a part of his network to a new range, all robots are now spamming Robot and ping alarms. I now have to tell him that maintenance won't work.

Mark

01-31-2019 06:16 AM

I think device correlation (discovery_server) is crucial role much rather than focusing maintenance_mode behavior.

I have checked behavior in my lab, here are results.

 

"Robot AAA is inactive" alarm --- ignored after putting Robot AAA into maintenance

"Connection to 'AAA' (ping) failed" alarm --- ignored after putting Robot AAA into maintenance

 

Environment

UIM 8.5.1

Secondary hub 7.80

Robot AAA

Robot AAA reports to secondary hub.

Robot AAA is monitored by net_connect that is running in hub.

 

01-25-2019 03:47 AM

We're now January 2018 and running UIM 9.02. Still the same issue, maintenance mode in USM in useless.

 

Even netconnect alarms are getting through, because of the same reasoning: 'Alarms come from the hub and not from robot'.

 

Frankly, this is unacceptable for a monitoring tool. It baffles me to see this as an 'enhancement', because it's basic functionality that should work. I don't want to mess around with preprocessing rules, I don't want to explain to a customer why such a basic functionality needs a convoluted workaround.

 

Please fix this ...

 

Mark

09-18-2018 08:21 AM

Hi,

 

Does it work perfectly? No. If the dev_id cannot be found by the methods posted below it will fail but it works far more times than not. Others with better knowledge of the UIMDB structure will be able to make improvements to the dev_id query.

 

However, it does significantly reduce robot inactive alarms for systems that are offline and in maintenance mode. I would encourage all to test for themselves and see if it helps in their particular situation (post your results). The nas configuration sections are posted below. 

 

NOTE: Our DB is MySQL so you may/will have to modify the query syntax for MSSQL or Oracle depending on what you are utilizing as your UIM DB. You may/will also have to increase the memory allocated to alarm_enrichment as the query result is large. We do this for both hub and logmon but you can add any probes to the list just follow the regex syntax (we have a lot longer list in production).

 

<enrichment-source>
<cmdbs>
<dev_id>
active = true
connection_url = jdbc:mysql://<uim_db_host>.ca.com/<uimdb_name>
user = <uim_db_ro_user>
password = <uim_db_ro_user_password>
query = select dev.dev_id, cs.cs_attr_value from cm_computer_system_attr cs, cm_device dev where cs.cs_id = dev.cs_id and (cs.cs_attr_key = 'DisplayAlias' or cs.cs_attr_key = 'PrimaryIPV4Address') and cs.cs_attr_value=?
population_query = select dev.dev_id, cs.cs_attr_value from cm_computer_system_attr cs, cm_device dev where cs.cs_id = dev.cs_id and (cs.cs_attr_key = 'DisplayAlias' or cs.cs_attr_key = 'PrimaryIPV4Address') order by dev.dev_id desc
</dev_id>
</cmdbs>
</enrichment-source>

<enrichment-rules>
exclusive_enrichment = no
<2>
match_alarm_field = prid
match_alarm_regexp = (hub|logmon)
use_enricher = dev_id
lookup_by_alarm_field = udata.source
lookup_by_regexp =
<overwrite-rules>
dev_id = [cmdb.dev_id]
</overwrite-rules>
</2>
</enrichment-rules>

 

Disclaimer: I am a CA employee in the IT department. I have no insight into support or development. Just posting what we utilize with the hope it will help others. Strongly encourage that you test all suggestions.

09-17-2018 11:17 PM

Did this test work?

06-05-2018 07:51 PM

aggas01 Looks like this idea has some decent enough votes to be considered for including as planned ?

 

Maintenance mode in UIM is quite useless unless it stops all the alarms from being generated on the server . Anything to do with the maintenance mode should be considered as a basic feature of any monitoring solution , but i do not really understand why something like this needs to be requested by a customer at the first place .

 

Setting maintenance is a day to day activity and we need to assist the end users every time they want to set a server in maintenance by creating some pre processing rules as they would end up having an robot inactive alert even when the device is set in maintenance from UMP

 

Please enhance the maintenance mode feature 

10-31-2017 06:33 AM

Taking this valuable idea as wishlisted since not planned in the near term.

10-18-2017 08:34 AM

Hi kanba01

 

Based on the information we are sharing here and the support KB article my understanding is that the dev_id associated with the alarm is the hub dev_id not the robot's (currently inactive) dev_id. As a result, the robot being in maintenance mode does not suppress the alarm because the hub dev_id does not relate back to a cs_id that is currently in maintenance mode.

 

To get around this in alarm enrichment our plan is to look up the dev_id of the impacted robot using udata.source value against the UIM database then update the dev_id of the alarm with the dev_id of the robot instead of that of the hub. This in theory should tie the robot (currently inactive) back to it's cs_id which is in maintenance. 

10-17-2017 06:58 PM

Alquin,

What objective are you trying to achieve by changing the dev_id by alarm_enrichment?

10-17-2017 05:49 PM

This explains a lot. Thank you. 

 

Has anyone tried using alarm_enrichment to change the dev_id on the incoming alarm? I am going to give that a go and see what happens with this.