[Nagiosplug-devel] State retention functionality

[William Preston]

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