[Nagiosplug-devel] State retention functionality
Ton Voon
tonvoon at gmail.com
Wed Jun 16 23:50:37 CEST 2010
On 16 Jun 2010, at 19:53, William Preston wrote:
> 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.
I've said previously (http://article.gmane.org/gmane.network.nagios.plugins.devel/6819
), the ideal is that Nagios is able to parse the performance data and
thus calculate the thresholds and calculations can be done there. Good
luck with that - I'm not planning on making a change of that magnitude
to Nagios...
> Some concerns I have are;
>
> * Will you be supplying bindings for perl, shell, python etc.?
No. I'm only planning on creating C library routines. You're welcome
to port to other libraries.
My design is partly based on Nagios::Plugin::Differences, written by
Jose Luis Martinez (http://article.gmane.org/gmane.network.nagios.plugins.devel/6787
), so there is a perl counterpart.
> * 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
Binary is just that - I've stated the limitations. In fact, while I've
considered it, I'm only going to implement string saves initially
Bear in mind, this is really a simple way of saving some arbitrary
information in a consistent location to calculate differences. Other
people have rolled their own mechanisms - I'm just trying to find a
way of creating an easily accessible, common routine.
> * 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.
If you've changed the parameters to the plugin, then, with argv
calculation, you'd lose one difference in value. I think that's
probably acceptable?
But --statekey is a good idea. I don't think I'll implement it, but
I'd welcome patches to override the statekey.
Ton
More information about the Devel
mailing list