Hi,

Here is the 2.0 release. The road was long since the 1.4 version, but we got lot of great new things to make your minitoring easier :)

Modules and packs are now in their own repos

In the 1.4 version, lot of modules and packs (there where more than 99 of them!) where provided with the shinken installation. It was a big mess where nobody really known what was provided. We switch to a more "explicit" way, and we moved all modules and packs into their own repositories. You can find all the default provided one on the project github organization.

Now the shinken installation will only provide the core framework with the daemons and all the monitoring capabilities. But if you need some modules, you will have to explicitly install them but at least you will know what is runing and why :)

All modules and packs are available as packages on the new exchange website, shinken.io. The goal of this new website is to be the place of modules and configuration packs publications. You can publish your own modules or packs into this website, it's designed for this :)

You don't need to have a repository in the github organization for this, all you need is to have a public repository, like on github.

One other thing that is possible now with the not in the same repository thing, is that now each modules/pack can have its own release cycle! For example I'll release a new retention-mongodb module the next week :)

Easy shinken installation (and update)

Now in order to install shinken you don't need to run an install script. All you need to do is to launch:

$ pip install shinken

We deprecated the old install script, but it's still available in the /contrib part of the shinken repo if you want to maintain it. We won't provide any more the addons installations by this way, as it's more the packagers works and it was taking us too much time that we prefer to use on making the framework even more awesome :)

The new shinken cli command

To make easy the modules/packs installation, we are adding the new "shinken" cli command. It is strongly linked with shinken.io for the packages installation part of course.

In order to use it, you will have to call the --init parameter so it will create the ~/shinken.ini file with all the paths to the shinken directories:

$ shinken --init

Then you can start to search and install packages:

$ shinken search linux
glances (david-guenault) [pack,system,linux,glances] : Standard check through checkglances.py and glances server
linux-snmp (naparuba) [pack,linux,snmp] : Linux checks based on SNMP
linux-ssh (dessaiimrane) [pack,linux,ssh] : Linux checks based on SSH without any script on distant server
pack-glances (david-guenault) [pack,system,linux,glances] : Standard check through checkglances.py and glances server

Then you can install it, for example the linux-ssh pack that will use the new agentless ssh checks for linux :

$ shinken install linux-ssh

You can also use the command to have a local access to the shinken documentation :

$ shinken doc-serve

will open an http server on the 8080 port with the documentation :)

Switch to HTTP(S) for the daemons communications

One of the main change on this release is we switch from pyro based communication to a more classic HTTP(S) one. Now, a simle curl command will enable you to check and query daemons :

$ curl http://localhost:7770/
OK

will check the arbiter daemon.

You can get the full HTTP api with:

$ curl http://localhost:7770/api

Now it's very easy to setup the SSL encryption between daemons. If you do so, beware of installating the cherrypy3 lib because the default wsgiref module from Python do not manage the http keep alive feature, and so it will ask far more CPU :)

The bp_rules boosting

Thanks to Christophe Simon that work on this code part for the 2.0 release, the bp_rules are now more powerful and flexible.

In the previous release, you have to explicitly call hosts or services by their names. Now you can ask them by :

• regexp
• host or service groups
• host tag
• service "labels" (new service parameter)

Here are some examples how to use the new capabilities :

Sample of bprules
Explicit naming
test_host_01,srv1 & test_host_02,srv1
by hostgroup
g:hostgroup_01,srv1
Regexp
r:test_host_0[12],srv1
by service group
*,g:servicegroup_01
by regexp for the hosts, and label for the services
r:test_host_0[12],l:label_02
by hostgroup for the hosts, and regexp for the services
g:hostgroup_01,r:srv[1]
by label for the hosts, regexp for the service
l:label_01,r:srv[1]
by tag for the host
t:linux,l:label_02

The roadmap

This release was a very long one. It was an important milestone to have, and now the project will be more agile and we will be able to release new versions quicker. The main focus on the next versions will be:

• backport some enterprise version views into the community WebUI
• arbiters relays (local arbiters that will manage a realm)
• snapshots (launch ps commands only if huge load problems are occuring)
• more api calls for the daemons :)

I don't plan to wait another ~year for a new release. I think I'll stick to a 2months release with less change for each. As we don't rely on the module release cycle anymore (can be long for some modules) we can really focus on small short iterations for the framework (like enhance the http api).

Ready for testing your new version? Go!

EDIT: I released a bug fix version, the 2.0.1 this morning. This fix a bug on the https certificate hostnames checks, if you don't use your own certificates or https, you don't need to update your version :)

jean gabès