[Nagiosplug-devel] Suggested alterations to the Performance P rotocoll
Yves Mettier
ymettier at libertysurf.fr
Mon Sep 13 14:31:15 CEST 2004
>> -----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/ -
More information about the Devel
mailing list