NSCA bottleneck / NSCA Timestamp
Ton Voon
ton.voon at altinity.com
Tue Nov 20 13:17:01 CET 2007
Hi Gerd,
On 19 Nov 2007, at 17:09, Gerd Mueller wrote:
> as many time before again I suffered from the NSCA bottle neck in
> Nagios. It's not new that NSCA can cause huge latency. Ton already
> mentioned this in his blog
> (http://altinity.blogs.com/dotorg/2006/11/caching_nsca_da.html).
>
> At my last project my workaround for this problem was to use the
> service_perfdat_file for caching and every 10 seconds the
> service_perfdata_file_processing_command to transfer this cached
> data to
> the master via one nsca call. This approach reduces/solves the latency
> problem. @Ton: with this approach there should be no need of any
> caching
> script and should work for hosts and services, or am I missing
> anything?
Actually, that's what we do sending results in Opsview now. Rather
than using ocsp, we use the service_perfdata_file to gather the data
to send and use processing_command to do the sending.
This seems to have given a small boost in performance, but I think we
sometimes get a bit more latency (because if a slave is very busy, I
think the processing command is given lower priority).
Not had time to blog about the change though :(
> Since nsca doesn't transfer any timestamps the reporting will not be
> correct at the master site! Ok, these 10 seconds delay isn't a big
> issue
> but I wonder why doesn't nsca transport the original timestamp?
>
> Because I would like the reporting to be as accurate as possible I
> would
> like to patch nsca. If changing nsca to include the timestamp would be
> worthwhile and there is any change for this patch to become part of
> nsca
> I write this patch.
>
> So anybody interested in this patch or any comments to this problem?
I agree this is a good idea because the master should evaluate the
result as it was at the time the result was checked on the slave, not
when the result was received on the master.
I think send_nsca was originally seen to be invoked at every result
(via ocsp), so appending the timestamp itself was probably easier at
the C program.
I'm guessing the change would just involve a new flag to send_nsca to
expect a timestamp from the input so (for example) the first field is
the timestamp to use. I'm guessing the nsca daemon doesn't need a
major amount of change because it expects a timestamp per packet anyway.
There maybe repercussions with this, for instance, with freshness
checking, but I think overall it is a good move. I'll be happy to help
out with any testing.
Ton
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
More information about the Developers
mailing list