Hi all,

It's just a little update about distributed retention module : now if you want persistent retention (memcache was just in RAM), now you can use a redis server :)

This module was pushed with the commit http://shinken.git.sourceforge.net/git/gitweb.cgi?p=shinken/shinken;a=commitdiff;h=c25f871e1a3df4c3c485f58ab29008b239af2ccc
There is quite a huge part of the code that can be factorized with the other retention modules in fact.

Now you just need to have a redis server (apt-get install redis-server && /etc/init.d/redis-server start) and add the module :
define module{
       module_name      RedisRetention
       module_type      redis_retention
To the schedulers you want.

All of this is described on the wiki at http://www.shinken-monitoring.org/wiki/distributed_retention_modules

Good easy distributed retention :)


On Thu, Oct 21, 2010 at 3:44 PM, nap <naparuba@gmail.com> wrote:
Hi all,

I just commit new modules, this one for the schedulers : flat file
retention and a memcache one.

The idea with the retention modules are the capability to choose where
you save your retention data (states and scheduling), and from where
you load them.
For a simple installation (no HA, one scheduler (but maybe numerous
pollers, it's not a problem here)) you can choose the easy way : flat
file save. But this way of retention is a huge problem with
distributed schedulers (remember that the retention is for the
schedulers only, the pollers just don't care about it) : you should
rsync the file, install a NFS/OCFS/GFS filesystem, etc etc. Not easy.

So for theses installations, you can choose to bypass this flat file
retention save and use another one like the memcache based one.
Memcache is a server that is easily setup in a Linux box for example
and you can store in it key/value. Here it's the retention data that
are save in it. So if a scheduler spare take the configuration, it can
get all fresh states/scheduling for example.

Memcache is just an example, for people that want a persistent
solution (memcache is just in memory), you can hack the code and use
redis or another key/value database (couchdb? :) ).

The memcache module code at
is quite long because a good part of it is the standard retention load
from data, but it will be factorize in the scheduler code.

So now, do not fear to loose your retention information after a crash :)

I added dummy modules so you can start to hack new one easily, like
Nicolas did for the NSCA server :p
And remember that if you want a git access, just ask for it so
everyone can show your new cool module :)