Indeed, it seems to me that the whole group concept is a good way to work with us humans but breaks down wildly when dealing with computers. This is fine because most of us use the groups to save space on the screens, and configuration in the conf files.
<br><br>If you want tests for each process and ultimately different behaviours for each process, you need to be prepared to do the work and make the tests for each process.<br><br>Please don't overcomplicate hobbit for this - it's a corner case and will ultimately make the program more unwieldy.
<br><br><div><span class="gmail_quote">On 5/2/07, <b class="gmail_sendername">Henrik Stoerner</b> <<a href="mailto:henrik@hswn.dk">henrik@hswn.dk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, May 02, 2007 at 02:06:34PM -0500, Kruse, Jason K. wrote:<br>> Grouped items, such as the process check and log monitors, are issues.<br>> A single process down causes the whole check to go red.  A process<br>
> listed as alerting only operators can then mask another process on the<br>> same system from notifying the DBA's.  Setting the alert repeat interval<br>> to 0 shows the other problem, a recovery message is not generated for
<br>> each process that recovers, only when the whole group of processes<br>> recovers.<br><br>This will be difficult to handle - it's a very basic thing in the Hobbit<br>design that it only tracks the color of each status, not the details of
<br>which rule (out of many) causes e.g. the "procs" column to go red.<br><br>To do that, you would need to associate some "event ID" with each of the<br>settings that can cause a red/yellow status; e.g
. you'd have<br><br>   HOST=myhost<br>       PROC tnslistener 1 ID=100<br>       PROC httpd 4 ID=200<br><br>The "procs" status would then store the set of ID's that had been triggered<br>for a status, and whenever there was a change in the set of triggered
<br>rules it would pass this information to some process.<br><br>It can be done, but I am not particularly happy with it; it seems a bit too<br>complex for my taste. If anyone has a better idea, please speak up.<br><br>(And just in case you wonder why I've used a new "event ID" instead of
<br>re-using the existing "group" definition: I can easily imagine a<br>scenario where you have e.g. multiple processes monitored with alerts<br>going to one group of people (i.e. several PROC rules have the same
<br>GROUP setting), but you still want to track exactly which processes are<br>up or down - and then you need a unique ID for each PROC rule).<br><br><br>Regards,<br>Henrik<br><br><br>To unsubscribe from the hobbit list, send an e-mail to
<br><a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br><br><br></blockquote></div><br>