[Nagiosplug-devel] State retention functionality

[Ton Voon]

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