On Wed, 27 Oct 2010 12:44:49 +0800 Timothy Sipples
<***@US.IBM.COM> wrote:
:>Binyamin Dissen writes:
:>>If ALERTs are issued for normal events, they no longer have value
:>>as ALERTs.
:>Ah, but who decides whether they're "normal" or not (and then what actions,
:>if any, to take)?
The person taking the action that would cause the unneeded alert.
:>Any even moderately capable console that collects SNMP alerts also has the
:>capability to triage and filter them according to evolving rules that
:>define "normalcy." But if the alert never gets sent, then that filtering
:>decision has already been made -- and *could* be made very badly. I tend to
:>prefer reality and transparency.
:>As I alluded to, it is possible to initiate additional alerts, such as:
:>09:55 Information: Application XYZ123 will have 30 minute planned outage
:>starting in 5 minutes.
:>10:00 ALERT: Application XYZ123 is now offline.
That increases the number of ALERTs, as the one receiving the second message
has to pay attention to the first one in order to know that the ALERT is not
really an ALERT.
Of course, one could downgrade the level of the second message to
"information" in this context, but one may as well (from the context of
ALERTs) simply not deliver it (or, perhaps, always deliver "XVZ123 is now
offline" to those that wish to subscribe to "information" messages.
:>There's also the issue of testing at the console (and beyond). If the
:>alerts never get sent, how do you know that the real ones work (or even go
:>anywhere)? The above example is the equivalent of a fire drill, or alert
:>rehearsal. I tend to prefer that. Your opinions and practices may vary.
I am not arguing against drills. What I am arguing against is issuing an ALERT
when normal operations are taking place.
For example, let use say that XYZ123 is always scheduled offline on Sunday. Is
there a need for an ALERT when it goes down for Sunday? Or, perhaps, the ALERT
should only be delivered when it goes offline outside the schedule?
:>And there's yet another reason to avoid obfuscation: to measure SLAs
:>accurately. If you're "secretly" downing applications, is that getting
:>reflected in Service-Level Agreement measurements? Probably not, and
:>perhaps with accurate knowledge you wouldn't be downing applications so
:>often (or at all), and/or somebody else could make an informed decision
:>whether or not to improve the SLA of particular application functions. Way
:>too many IT folks think that SLAs are only about "unplanned" hard-stop
:>system-level outages. The end-user perspective is much more about "can I
:>get my work done?" and that really is the only correct perspective. "Can I
:>get my work done?" is answered by looking at end-to-end service delivery,
:>both planned and unplanned outages, missed response time goals (not just
:>"down" outages), plus some other factors (e.g. "I can't log in!")
Then, again, it is not an ALERT but an information message.
Perhaps the person subscribes to all messages on his work computer but only
subscribes to ALERTs from his PDA. By sending "XYZ123 is offline" as an ALERT,
there will not be the context that XYZ123 was scheduled to be offline.
:>Anyway, this discussion borders on the philosophical, but now you know my
:>philosophy. :-)
--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html