[Nagiosplug-devel] Nagiosplug-devel Digest, Vol 49, Issue 3

[Matthias Weiß]

Am 16.06.10 22:36 schrieb "nagiosplug-devel-request at lists.sourceforge.net"
unter <nagiosplug-devel-request at lists.sourceforge.net>:

> Send Nagiosplug-devel mailing list submissions to
> nagiosplug-devel at lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> or, via email, send a message with subject or body 'help' to
> nagiosplug-devel-request at lists.sourceforge.net
> 
> You can reach the person managing the list at
> nagiosplug-devel-owner at lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Nagiosplug-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: State retention functionality (William Preston)
>    2. Re: State retention functionality (Holger Wei?)
>    3. Enc: Suggest Improvement plugin "check_oracle"
>       (Eduardo Willame (Valentim))
>    4. Re: State retention functionality (William Preston)
>    5. Re: State retention functionality (Flyinvap)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 16 Jun 2010 18:27:48 +0200
> From: William Preston <nagiosplug-devel at spidalinx.co.uk>
> Subject: Re: [Nagiosplug-devel] State retention functionality
> To: Nagios Plugin Development Mailing List
> <nagiosplug-devel at lists.sourceforge.net>
> Message-ID: <C6D46902-BB48-4B69-9A95-E83356D79561 at spidalinx.co.uk>
> Content-Type: text/plain; charset=us-ascii
> 
> On Jun 16, 2010, at 5:29 PM, Ton Voon wrote:
>> I have a need to enhance check_snmp to provide support for differences
>> between counters and so I'm going to create some library functions for
>> handling state between invocations of a plugin. I've been working with
>> Holger on the design and we're happy with this:
>>   http://nagiosplugins.org/rfc/state_retention
>> 
>> This is based on the email threads some time ago started by Alain.
>> I've taken all the comments and tried to get something small and neat.
>> 
>> Any comments welcome. I'm planning on starting to code this tomorrow.
> 
> I realise I've come a bit late to the party here, but
> have you considered memcached?
> 
> It seems to me to be a tried and trusted mechanism that many
> admins are already familiar with, is distributed, cached, scaleable etc.
> And it should be less work to implement than building something new :-)
> 
> William
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 16 Jun 2010 19:16:38 +0200
> From: Holger Wei? <holger at CIS.FU-Berlin.DE>
> Subject: Re: [Nagiosplug-devel] State retention functionality
> To: Nagios Plugin Development <nagiosplug-devel at lists.sourceforge.net>
> Message-ID: <20100616171637.GF21104317 at CIS.FU-Berlin.DE>
> Content-Type: text/plain; charset=us-ascii
> 
> * William Preston <nagiosplug-devel at spidalinx.co.uk> [2010-06-16 18:27]:
>> On Jun 16, 2010, at 5:29 PM, Ton Voon wrote:
>>> I have a need to enhance check_snmp to provide support for differences
>>> between counters and so I'm going to create some library functions for
>>> handling state between invocations of a plugin. I've been working with
>>> Holger on the design and we're happy with this:
>>>   http://nagiosplugins.org/rfc/state_retention
>>> 
>>> This is based on the email threads some time ago started by Alain.
>>> I've taken all the comments and tried to get something small and neat.
>>> 
>>> Any comments welcome. I'm planning on starting to code this tomorrow.
>> 
>> I realise I've come a bit late to the party here, but
>> have you considered memcached?
>> 
>> It seems to me to be a tried and trusted mechanism that many
>> admins are already familiar with, is distributed, cached, scaleable etc.
> 
> While I'm all for reusing code, memcached really solves a different
> problem.  We just need a simple solution to store and retrieve trivial
> amounts of data in a specific way.  Admins shouldn't be bothered with
> setting up and maintaining the storage at all.  So a "distributed,
> cached, scaleable etc." client-server solution seems to be overkill to
> me.
> 
>> And it should be less work to implement than building something new :-)
> 
> In this case, I think the opposite is true.
> 
> Holger
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 16 Jun 2010 11:22:14 -0700 (PDT)
> From: "Eduardo Willame \(Valentim\)" <eduardowillame at yahoo.com.br>
> Subject: [Nagiosplug-devel] Enc: Suggest Improvement plugin
> "check_oracle"
> To: Nagios Development Team <nagiosplug-devel at lists.sourceforge.net>
> Message-ID: <403965.37492.qm at web52902.mail.re2.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Dear Dev Team,
> 
> 
> I have noticed that the plugin "check_oracle" on "nagios-plugins package"
> doesn't monitor Oracle Temporary Tablespaces and I put this resource on new
> script "check_oracle".
> 
> Please consider this on future nagios-plugins releases, because it is very
> important for DBAs monitor Temporary Tablespaces TOO.
Hi Eduardo,

Check_oracle currently contains an function to monitor any tablespaces. In
this case it should be also possible to check the temp tablespaces by it's
name. 
Or do you need some additional data to be monitored?

> 
> Thanks,
> Eduardo Valentim
> DBA Oracle 10g
> 
> Fortaleza-CE
> Brazil
> 
> 
>       
> -------------- next part --------------
> An HTML attachment was scrubbed...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: check_oracle
> Type: application/octet-stream
> Size: 9156 bytes
> Desc: not available
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 16 Jun 2010 20:53:31 +0200
> From: William Preston <nagiosplug-devel at spidalinx.co.uk>
> Subject: Re: [Nagiosplug-devel] State retention functionality
> To: Nagios Plugin Development Mailing List
> <nagiosplug-devel at lists.sourceforge.net>
> Message-ID: <084EBE7B-107C-477F-9984-70153496F1D7 at spidalinx.co.uk>
> Content-Type: text/plain; charset=iso-8859-1
> 
> 
> On Jun 16, 2010, at 7:16 PM, Holger Wei? wrote:
>> While I'm all for reusing code, memcached really solves a different
>> problem.  We just need a simple solution to store and retrieve trivial
>> amounts of data in a specific way.  Admins shouldn't be bothered with
>> setting up and maintaining the storage at all.  So a "distributed,
>> cached, scaleable etc." client-server solution seems to be overkill to
>> me.
> 
> I think we may be coming at this from opposite ends of the spectrum!
> I'm thinking of large setups with hundreds of thousands of checks and
> clustered
> nagios servers.  I suspect the DNX people would also have a problem with
> state data being stored on a particular node.
> 
> The current solution of storing state data in the perfdata field and passing
> it as
> an option may not be pretty, but at least it works in such situations.
> 
> Some concerns I have are;
> 
> * Will you be supplying bindings for perl, shell, python etc.?
> * In what format will the data be stored? I'm not keen on binary data being
> stored without
> knowing if it is 32/64bit, big or little endian
> * Unique identifier: I would offer the user a key option (e.g. --statekey
> '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last resort because it may
> change with on-demand macros.
> * Performance -> file I/O is a problem in large setups
> * What about plugins that want to share state data?
> * Validity: I can think of a few situations where a check is costly and a
> cacheing mechanism with a "valid till" field would really help.
> 
> 
> Don't misunderstand me - I agree with you that we need this functionality -
> but I fear 
> the "simple solution" may be worse than the current workaround using
> SERVICEPERFDATA.
> 
> William
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 16 Jun 2010 22:20:36 +0200
> From: Flyinvap <flyinvap at orange.fr>
> Subject: Re: [Nagiosplug-devel] State retention functionality
> To: Nagios Plugin Development Mailing List
> <nagiosplug-devel at lists.sourceforge.net>
> Message-ID: <4C193214.1020608 at orange.fr>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Le 16/06/2010 20:53, William Preston a ?crit :
>> The current solution of storing state data in the perfdata field and
> passing it as
>> an option may not be pretty, but at least it works in such situations.
> 
> I agree but you can always use that way ;-)
> 
>> * Will you be supplying bindings for perl, shell, python etc.?
> 
> Very important.
> 
>> * Unique identifier: I would offer the user a key option (e.g.
> --statekey '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last
> resort because it may change with on-demand macros.
> 
> Yes.
> 
>> * Performance -> file I/O is a problem in large setups
> 
> Nagios use too many I/O, with this system would not improve performance.
> We can always put thoses files in a ramdisk.
> 
>> Don't misunderstand me - I agree with you that we need this
> functionality - but I fear
>> the "simple solution" may be worse than the current workaround using
> SERVICEPERFDATA.
> 
> I agree. I use SERVICEPERFDATA because I do not have many plugins using
> it. In the futur I would try memcached for that, it's not too hard to
> install and maintain.