[Nagiosplug-devel] State retention functionality
perldork at webwizarddesign.com
Thu Jun 17 13:39:16 CEST 2010
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.
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
>> 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
>> * Unique identifier: I would offer the user a key option (e.g. --statekey
> 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
> 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
> 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:
> 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
More information about the Devel