Re: [Perfparse-users] Service State

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

Hi Tim,

I am glad you like it :)

Let me answer your questions in-line:

Tim Wuyts wrote:
> I've been experimenting with perfparse for a few days now, and it's an
> impressive start. Here is a suggestion I'd like to make: why don't you store
> the service state anywhere? By this I mean the actual exit code as reported
> by the plugin. According to the Nagios doc it's available through the
> $SERVICESTATE$ macro, so adding it to the serviceperf.log file should not be
> a problem. You could then simply store it in the perfdata_service_raw table.

Yes, this is a bit of an over-sight.  In fact when I did the first 
version, either this macro was not available, or I entirelly missed it...

Unfortunatelly PerfParse expects the log file in an exacting format.  It 
is on our to-do list to amend this to inteperate this file depending on 
the format specified in nagios.cfg.  It just hasn't been done yet :)

PP at the moment doesn't store this value at all.  The 'bin' data, as 
you say, recalculated this.  This is not just that there is no data 
available, but also because the STATE from Nagios is specific to the 
entire service.  Each service may have many metrics.  Each metric may be 
in a different state :)

There is no real point in storing this as it can be re-calculated. 
Saves space that's all.

The 'Raw' data certainly has more reason to store this.  In fact, i will 
escalate this to-do item.  It has a best-guess at the state, but due to 
some badly coded plugins, doesn't always get it right.  As you say, 
historical data is sitting there ready to be reported on, and doesn't 
mean a lot without the state :)

PerfParse was designed to analyze data, as well as store it.  I wonder, 
do you know any SQL and 'c'?  Would you like to have a go at an 
availability report for the raw data?  If you do, I'll give you some 
details in another email.  You will be fully credited for any work.

Thanks for enjoying PP, please keep the feedback going!

Regards,

Ben