[Perfparse-devel] Re: Antwort: Re: [Nagios-users] Perf-Problem - Not more than 255 Childs?

[Ben C. <Be...@cl...>]

Andreas,

I totally agree.  A socket feeding PerfParse would be excellent.  For 
all the reasons you list.  I believe that this is in the pipe (no pun 
intended) for Nagios 2.0.  At which time my self and the other PerfParse 
developers will work 24x7 to make this work :)

However, the current method, apart for the 10 minute delay (depending on 
your cron) works without a major load increase.  The load on my system 
by just the 'perfparse' parser component is not massive.  Other work in 
the next few versions will ensure this load is lessened by moving daily 
administrative functions to a nightly on-shot.

I note your comment about the alternate status display.  You can see the 
start of this in the current version.  Which I use as it's faster than 
the Nagios status display.  At least in Nagios 1.2.  This will be 
developed further including easy to use filters and alternate displays. 
  (Possible a Java Bean app as well for instant refresh of changing data 
at lower load the HTML.)  However, having two systems, with two 
databases, two displays, seems pointless.  Accept that PerfParse gives 
access to all plugin output intrinsically, not just the current. 
PerfParse is *not* being developed as a replacement to Nagios GUI :)

Ben.

Andreas Ericsson wrote:

> Ben Clewett wrote:
> 
>> Nagios only needs to open *one* file for PerfParse to work.  This file 
>> is help open permanently.  (serviceperf.log)  The 256 limit per 
>> process is unlikely to be of any relevance.
>>
> 
> If it could open a socket instead, wouldn't that increase performance 
> and usability by about a zillion times?
> * Perfparse could have a single persistent connection to mysql.
> * Changes would be visible instantly.
> * Less filethrashing.
> * No need for exotic filetruncing log-rotation with risks of data-loss.
> * No need to set up cron-jobs.
> * Nagios still wouldn't have to fork.
> * In time, perfparse could well act as a statusdb engine for the nagios 
> GUI, making it always display the results of the last check (this 
> requires nagios to forward the entire output message along with relevant 
> host/service info though, but I hardly think that can be a serious 
> coding problem).
> 
> Just thinking out loud...
> 
> --[ snip ]---
> 
>>
>> Regards, Ben.
>>
>