[Nagiosplug-devel] State retention functionality

[Holger Weiß]

* William Preston <nagiosplug-devel at spidalinx.co.uk> [2010-06-16 20:53]:
> 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.

If accessing the state data will ever become the bottleneck for such
setups (which I doubt), we can easily implement additional storage
backends in the future.

> * Will you be supplying bindings for perl, shell, python etc.?

Nothing prevents us from doing so in the future, I guess.  But please
note that we currently won't expose this stuff as an external API
anyway.

> * Unique identifier: I would offer the user a key option (e.g. --statekey '$HOSTNAME$/$SERVICEDESC$')

Good idea.

> 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.

So you would seriously force each and every user of our Plugins package
to setup and maintain a full-blown, distributed client-server solution
just in order to provide two or three plugins with a means of storing a
few bytes of data?  Jeez!

We should try to make sure that the API won't get in the way of
scalability, but we should keep the initial storage backend as simple as
possible.

Holger