Master "Shut-Off" Valve For Alerts, And Possibly Other Features Too.

It would be nice to be able to disable the alerting system, temporarily, without actually modifying any of the alerts, actions, or nodes. Currently, we can mute nodes/alerts, or go into the alerts/actions directly, and disable them. For various maintenance reasons, it would be nice to be able to easily disable alerting, on a global/system level, with a single click of a button, without needing to go into the SMTP settings and impose an incorrect value.

nickzourdos meech #bumpsquad

Find more posts tagged with

shakkalakka

bumpsquad

alert bypass

alert master shutoff valve

meow

Status: None

Comments

nickzourdos

Hear, hear!

sja

We use the Pause action is just fine ...

if you like to stop the SMS GW to send alerts ...

vinay.by

If its to make the feature much more simple (which freezes all alerts and only brings back the one's that were available before the freeze then its a great idea)

wluther

sja Thank you for pointing that out. I had seen that, but my brain was telling me it was only for all existing alerts. If this works for future alerts too, then it would appear this feature request is null and void... or whatever the saying should be.

bourlis

On the surface I like this idea and I see where your coming from, however there's a couple issues with this request in it's current form that would need to be addressed.

Logging - Solarwinds does a horrible job in logging who does what at the admin level. Who disabled global alerting would have to be logged. This is even more the case in a large enterprise where you have multiple Solarwinds admins. It would only take one admin to "accidentally" disable global alarming to cause a major issue. I would want to see a log of who disabled global alarming so that way questions can be asked, if need be.
Outage window - There would have to be a mandatory auto re-enable global alarming setting. It would be too easy to disable global alarming and forget about it. Again in a large enterprise this could be a major issue.
Dashboard notification - If this were to happen I would like to see something on the dashboard to let all users know alarming is disabled on the global level. In a large enterprise, there can be a large number of people who use Solarwinds. While the admin might know global alarming is disabled, the users wouldn't. While this should be something covered in a 'change management' meeting it might not get relayed to all users. Having a dashboard notification would let all uses know that alarming is disabled at a global level.
Admin rights - Kind of goes back to my first issue. Anyone with admin rights would be able to disable alarming at a global level. If you have a large number of admins that might not be a good thing. There should be tired admin levels that allow/disallow the ability to globally disable alarming.

For these reasons I can't vote this up, but I like the idea so I'm not going to vote it down. I guess I just needed to make a point and maybe suggest editing and/or resubmitting the request with tighter security constraints around globally disable alarming. I would then vote this up if it had tighter security constraints.

wluther

bourlis I agree with your points. #2 & #3 can be handled with a few SDK scripts, but the logging and admin rights are long overdue for a refresh.