david.carmean at netap... wrote:
> I would (and do) worry about alert storms creating huge blobs of
> tickets.
>
I agree, and I'd even say that it is unwise to go directly from Zenoss to a
ticket system.
Not every alert will be a genuine problem, and you need someone to filter this,
someone who knows Zenoss.
What I would propose (and what we plan to do in our Zenoss deployment), is to
use Zenoss as a simple ticket system, and manually pass on important issues.
Our workflow is planned to be as follows:
A number of people (admins) are responsible for handling Zenoss events
The first one to take care of a new event marks it as "acknowledged".
That makes Zenoss store his/her name, and means "I'm handling this"
The person handling the event then resolves it, if it is trivial/false
alarm, or creates a ticket in the "real" ticketing system, adding information
that was found during preliminary investigation
I feel this makes more sense than directly creating tickets. False alarms aside
(which can always occur), by handling the events within Zenoss at first, it is
much easier to see correlations (e.g. disk full and db was shut down - maybe
one caused the other)?
By creating separate tickets which may be handeled by different persons, you
lose this information.
Plus, pragmatically speaking, some of the Zenoss alerts are very technical, and
it helps to have someone translate them first.
-------------------- m2f --------------------
Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=13637#13637
-------------------- m2f --------------------
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
