[Nagiosplug-devel] Suggested alterations to the Performance P rotocoll

[Yves Mettier]

>> -----Original Message-----
>> From:	Karl DeBisschop [SMTP:karl at debisschop.net]
>> Sent:	10 September 2004 01:36
>> To:	Ben Clewett
>> Cc:	Yves Mettier; nagiosplug-devel at lists.sourceforge.net
>> Subject:	Re: [Nagiosplug-devel] Suggested alterations to the
>> Performance Protocoll
>>
>> Ben Clewett wrote:
>> > 9.  Limit protocol to just numerical data:  No.  But will not be
>> > supported by some storage programs.  (Yves performance parsing engine to
>>
>> > allow such programs to do what they like with this data.  Hows this work
>>
>> > going?)
>>
>> Right - programs that are built for graphing would be expected to ignore
>> such data. But that does not give license to design the guideline such
>> that nothing but graphing can ever be done with the data.
>>
> 	[Voon, Ton]  [apologies for using Outlook]

:)

> 	Actually, I disagree on this fundamental point. I think perf data is
> **only** about graphing the data - this is why I am against strings and
> check_time labels.

Same opinion, except that I like to have open things when they can be left opened. See
below.

> 	I've been thinking a lot about this and I think what is required is
> the concept of "additional structured data". The status output gives an
> overview, the perf data gives the graphing and the "additional structured
> data" gives plugin-specific stuff that can be processed in some way.
>
> 	I've been playing with BMC Patrol and one thing that is quite clever
> is if it finds cpu usage is high on a server, it returns a list of the top 5
> processes bound on the CPU. So, with the above in mind, I can see this in
> future:
>
> 	$ check_procs --metric=CPU -c 90%
> 	CRITICAL: 2 processes over 90% CPU | process=2 |
> <process><name>httpd</name><cpu>93%</cpu></process><process><name>ora_pmon_W
> EB</name><cpu>95%</cpu></process>
>
> 	$ check_log -c 10 -e "killed"
> 	CRITICAL: 14 errors in log file /var/adm/messages | errors=14 |
> <error><time>{unixtime}</time><message>httpd killed - restarted
> automatically</message></error><error><time>{unixtime2}</time><message>Other
> message with killed in</message></error>etc,etc
>
> 	[Syntax and output not necessarily 100% accurate :)]

I like the concept. There is already a need for check_disk that prints all the disks.
You are creating the need for check_procs and check_log :)


> 	The use of XML is purely because it is easily extensible and people
> can write XLST to parse it any way they want. The | is the separator between
> overview, status and extra data. However, there are limits to the output of
> plugins which would need to be addressed first.

I also agree with XML and putting the extra data after a new |
I will add that in my parser as a new character to check, with the ' ', and '\0' chars.

There are things to discuss about what to put after the second |, what to put before the
1st |, but this is not our subject here.

> 	If this is the way to go, then that's great - in the future. I would
> like to focus on what is required with perfdata and, for me, that means only
> graphable data, so I still disagree with check_time and strings.
>
> 	But this is a nice lively debate, so I anxiously await your
> comments!

With the possibility to put a second | and data after that, you open a new way !

Back to perf data, in my opinion, we still have:
- do we replace "~" with "inf" in ranges, and do we allow "nan" for values ? (I vote for
yes)
- do we replace [min];[max] with a unique field with range format ? (I vote for yes only
if we change the protocol and make something not compatible)
- do we allow non numerical values ? (I vote no)
- do we add a separator between the value and the UOM ? (I vote yes only if we allow non
numerical data for values)

I will need the answers next week, to finish the parser and showing it to you.

Yves

PS. I don't read my mails often during the week-end. Feel free to fill my mailbox: I
like interesting debates :)
-- 
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -