NSCA bottleneck / NSCA Timestamp

[Ton Voon]

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/