On Thu, 24 Aug 2006, David Nolan wrote: > --On Thursday, August 24, 2006 08:21:16 -0500 Tim Carr <[EMAIL PROTECTED]> >> >> The problem is that we're going to need to turn the monitoring period >> for several of the remote site monitors in each location way up - like >> checking every 10 seconds (i.e., "interval 10s"). That mean we're going >> to see a huge increase in the number of traps we're seeing at the >> corporate site.
> Or we could implement a redistributeevery option, similar to alertevery. > That wouldn't be too hard, but would take a little work. yeah the issue here is the processing and communication overhead of dealing with the traps sent remotely. it would make sense to batch up the 10s traps from the remote systems and send them out in a bundle say, once every minute, and that would, you know, save you 6x the processing overhead on the remote mon server, or at least give you a way to control the processing overhead to suit your needs. this use case might mean that it would make sense to move the remote trap stuff into the mon server itself, rather than implement it with the trap alert. the trap alert is a nice simple abstraction that works well for the simpler cases, and an elegant way of extending the functionality of mon without having to change the server code, but at the cost of efficiency. you would really want the ability to batch up only the trap transmissions rather than all alerts. for example, schedule a "trap queue" flush every minute performed by the mon server rather than in the trap alert. then this brings up the issue of trap processing overhead on the rx end. i wonder if the behavior would be acceptable by just processing the trap receptions serially, the way it is done now, or if it would require a change in processing method to scale it up efficiently. this probably requires much more thought and a better understanding of the usage scenario. _______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
