[Nagiosplug-devel] State retention functionality

[Max]

We have been using memcached on our pollers for state retention and
delta calculation with very good success - on one of our more active
pollers several thousand of the active service checks it runs every 5
minutes use memcached for state.

So while you might not like memcached it works quite well and scales
well - never have we had to tune or tweak it to keep up with our
systems as they have grown.

It is zero maintenance as well.

Max

On 6/17/10, Holger Weiß <holger at cis.fu-berlin.de> wrote:
> * 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
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________________
> Nagios Plugin Development Mailing List
> Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>