--On Thursday, August 24, 2006 10:14:48 -0400 Jim Trocki <[EMAIL PROTECTED]> wrote:
> 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. > I could see benefits to that capability, in addition to the current redistribute support. My original idea for redistribute was that it could be used to integrate mon with other systems as well, because its just an arbitrary script that you can provide. i.e. it could send status updates to Open View, or log status updates to a database, or anything else you might want. The ability to use it for integration with remote mon servers is just a bonus... > 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. For the record, my master server is a 2.8Ghz P4, and basically runs at zero load while processing the trap load I described earlier, and running a few tests of its own. I'm sure there is a limit to reasonable trap load, but we haven't hit it yet. > > this probably requires much more thought and a better understanding of the > usage scenario. > I agree. I suspect Tim's usage scenario involves large numbers of servers sending monitoring relatively small environments, so I doubt he'll have any processing load problem. But we're not quite sure of the scale of Tim's setup. -David _______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
