IMC
cancel
Showing results for 
Search instead for 
Did you mean: 

IMC email notifications - stop duplications

itzafugazi
Occasional Visitor

IMC email notifications - stop duplications

Hi,

When an alert from IMC comes into our helpdesk, I'd like to be able to stop further notifications of the same issue coming in. One is enough to generate a ticket.

For example, we have a problem device at the moment which is alerting regularly for non-response to ping packets; it's a legimate alert and needs investigating, but other than going into IMC and unmanaging the device, is there another way to tell IMC not to keep sending alerts on the same issue? Even if it was "do not send the same alert more than once every x minutes".

 

3 REPLIES
LindsayHill
Honored Contributor

Re: IMC email notifications - stop duplications

The problem is that IMC thinks that this is a new issue, because the device has gone offline, then recovered again. When it recovers, it closes the original issue. 

Then when it goes offline again, that is a new issue. IMC does not see that as a continuation of the previous issue. 

No easy way to change that for IMC, other than to change the rules around that event - e.g. to change the ping retries, or the timeout. Depends on how often your device is going online/offline. 

Otherwise you'll need to figure out some sort of de-dup on the helpdesk side.

itzafugazi
Occasional Visitor

Re: IMC email notifications - stop duplications

Thanks Lindsay, I thought that might be the case.

As a possible solution...is it possible to delay how long it takes for IMC to consider a device recovered?

I presume when a device has lost enough pings to trigger an alart, it will consider it back online after x sucessful pings. Can this be changed? If I could make this a large number of pings, that would be a workaround I'd be happy with.

Thanks for your help. 

LindsayHill
Honored Contributor

Re: IMC email notifications - stop duplications

No, I don't think you can change it that way. You can make it do multiple retries to detect failure, but not multiple retries to determine success.

Rather than send email on "device down", you could maybe send an email when the device is unreachable for more than <x>% in the last hour. (Can't remember the exact alarm name, but should be easy enough to find). That alarm may support a re-arm threshold. 

Of course, you could always just fix the underlying cause...