[Nagiosplug-help] NSClient fix needed

[Voon, Ton]

Tim,

Thanks for the report. Unfortunately, the nagiosplug project does not
maintain NSClient (though we will accept patches to check_nt) - you may want
to try http://nsclient.ready2run.nl/.

Ton

> -----Original Message-----
> From:	Tim Shouldice [SMTP:tim at mintoskatingclub.com]
> Sent:	Saturday, March 29, 2003 5:52 AM
> To:	nagiosplug-help at lists.sourceforge.net
> Subject:	[Nagiosplug-help] NSClient fix needed
> 
> I often been perplexed by the results returned by the NSClient for some of
> the counters. Some, like \\Processor(_Total)\\% Processor Time
> <file://\\Processor(_Total)\\% Processor Time> were returning 99 all the
> time, others returned 0 all the time, others returned data that was not
> consistent with the output from the Perfmon tools (same trends, different
> values, same host). While others worked perfectly fine! Additionally, the
> internal code called the same counter and seemed to be getting results.
>  
> After a review of the source code and review of Microsoft's documentation
> on the PDH api, it seems that some of the counters require two samples to
> report correct data. There are two separate functions -
> PdhGetRawCounterValue (which is raw, unformatted and uncalculated) and the
> more useful PdhGetFormattedCounterValue (which calculates formatted value
> and somtimes needs two data points to do it - eg. functions with
> percentages of usage and rates per second). The source code within
> NSClient uses PdhGetFormattedCounterValue as follows:
>  
> uNSClient.pas
> 
> // Collect the data
> 
> PdhCheck('Collect ' + sCounter, PdhCollectQueryData(qryPDHQuery));
> 
> // Process Custom counter
> 
> PdhCheck(sCounter, PdhGetFormattedCounterValue(custom_counter,
> PDH_FMT_DOUBLE, nil, CounterValue));
> 
> ...
> 
> However, in both the documentation, and in samples on MSDN, it is clear
> that two calls to PdhCollectQueryData with a sleep between are required.
> Here is an excerpt from Microsoft's sample code (in c):
> 
> // "Prime" counters that need two values to display a 
> //   formatted value.
> pdhStatus = PdhCollectQueryData (hQuery);
> 
> // Wait one interval.
> Sleep(SAMPLE_INTERVAL_MS);
> 
> // Get the current data values.
> pdhStatus = PdhCollectQueryData (hQuery);
> 
> SAMPLE_INTERVAL_MS was a constant defined as 1000.
> 
> I compiled and tested the samples and found when I used the query, wait,
> query method that my counters returned correctly, however if I commeneted
> out the 'prime counter' query and the sleep, then the results were the
> same funny ones I get with NSClient.
> 
> It seems the following two lines need to be added to NSClient
> 
> >PdhCheck('Collect ' + sCounter, PdhCollectQueryData(qryPDHQuery));
> 
> sleep(1000);
> 
> PdhCheck('Collect ' + sCounter, PdhCollectQueryData(qryPDHQuery));
> 
> >// Process Custom counter
> 
> >PdhCheck(sCounter, PdhGetFormattedCounterValue(custom_counter,
> PDH_FMT_DOUBLE, nil, CounterValue));
> 
> I do not have access to a Dephi environment to add these lines and
> recompile, is there anyone who can and then post the updated executable?
> 
> Additionally, it is not well documented but a review of the source code
> demonstrates that the counters.defs file is purely used for some of
> internal data collection for commands other than COUNTER, adding
> additional counters to this file is not required and they would not even
> be used. The file is used to compensate for the good folks at Microsoft
> changing the CPU usage counter between NT and Win2k and to enable the
> application to work with different language versions of the OS. The custom
> counter function does not use this file or the language definitions
> because it is the counter name itself that changes between language
> versions of the OS. Early programs that gathered counter information
> directly from the registry needed the language version because the counter
> values are stored under a registry key linked to the language. This not
> apply when using the PDH libraries.
> 
> Cheers,
> 
> Tim Shouldice
> 


This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.  
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.