Yet one more to our long lists of requests…..
Dirk Bulinckx. From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jason Passow Sent: Friday, November 07, 2008 5:35 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Feature Request: Escalation Management I like this idea. In case it needs support in order to get implemented. Jason Passow Mississippi Welders Supply http://www.mwsco.com [EMAIL PROTECTED] ph: (507) 494-5178 fax: (507) 454-8104 -------------------------------------------------------------------------------- From: Vogl, Tom [mailto:[EMAIL PROTECTED] To: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] Sent: Fri, 07 Nov 2008 10:05:17 -0600 Subject: RE: [SA-list] Feature Request: Escalation Management You got it. Create a group of alerts independent of any specific entry, give it a name ("Mission Critical alert plan"), and then assign it to one or more entries which would "inherit" that set of alerts. Would want to be able to create more than one alert group within SA, but an entry could only be linked to one plan. Calling these alert groups "escalation plans" really conveys what the intended purpose is: a series of notifications that go through various steps/people as the alarm condition remains - applied CONSISTENTLY across checks and they would now be very easy to modify/maintain. -tom -------------------------------------------------------------------------------- From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Dirk Sent: Friday, November 07, 2008 10:01 AM To: Servers Alive Discussion List Subject: RE: [SA-list] Feature Request: Escalation Management If I understand it correctly you mean a option to create a group of alerts and then per entry you're able to "add 1 group of alerts" - "add alert(s)" - "-copy group of alerts". When adding the "group of alerts" then you can NOT change the individual alerts that are part of the group, for that specific entry. But if you change the alert within it's group, then all entries that use that group of alerts also automaticly use that updated alert. (like currently you send the alert to a team and if the team changes then all that use the team use the updated team info). Dirk Bulinckx. From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Vogl, Tom Sent: Friday, November 07, 2008 3:15 PM To: Servers Alive Discussion List Subject: [SA-list] Feature Request: Escalation Management Dirk, I have an idea for an improvement to SA. Its not really a new capability, it's more of a change to the way current capabilities are managed. Every one of our checks has several notifications. (first down, 4th down, etc) for issue escalation. What I would like to see is a better way to manage that process than at the individual check level. I'd like be able to build an "Escalation Plan" that outlines a series of notifications steps based on number of downs and then simply apply that plan to one or more checks. I think this can currently be accomplished via some group editing - but I'm looking for more that that. It would be great if we could then sort/manage/report on checks based on the PLAN they were tied to (or ones that didn't have an escalation plan). Also, a single change to the escalation plan would automatically be used (inherited) by all the checks tied to that plan. In the ideal world, you could have several "escalation plans" built in SA (mission critical, casual systems, FYI notifications) and any given check could be assigned to a single plan - but it could also have additional notifications at the check level. In my mind I am seeing the Notification page have a drop down to select an Escalation Plan, and if selected, all the alerts for that plan are visible at the check level as grayed out or "read only" values, but you could always add in additional checks as well. You could not delete an inherited notification from a check, but there could also be a button to "Copy Escalation Plan notification to this check" that, if picked, would copy the plan notifications into the check as "local" and clear the selected plan field (break the inheritance link). The result is an easy way to make sure check notifications are consistent and greatly simplify the management of one of the most powerful features of SA. -tom To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
