The 2.0 RC version and the project
Hi,
The 2.0 release is currently in RC Phase. You can get a look at it by launching :
$ pip install shinken
You can get a full look at the changelog there. Aside some classical bug fixes, you will find some enhancements too :
- we switched the internal protocol between the daemons from Pyro to a more classic HTTP(S) communication,
- (huge) business rules enhancement (parsing level, output and tag/group linking) thanks to Christophe Simon,
- we switch all modules and packs from the shinken repo, to their owns,
- shinken command line interface (cli) to install packages (module and packs) from the shinken.io website and serve doc
Focus on the 2.0 changes
Switch to HTTP(S) for the daemons communications
One of the main change on this release is the drop the the 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.
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 :
define host{
host_name test_host_01
use linux
hostgroups hostgroup_01
labels label_01
...
}
define host{
host_name test_host_02
use linux
hostgroups hostgroup_01
labels label_01
...
}
define service{
hostgroup_name hostgroup_01
service_description srv1
servicegroups servicegroup_01
labels label_02
...
}
theses bp_rules wil give the same result :
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
You can get the documentation about the bp_rules there.
Framework focus
We also moved all modules and packs into their own repositories (there where more than 99 of them!). 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. We think it's a far better way than enable by default some and not others. It was really hard for new users to know what was enable and what was possible. Now it's will be far easier thanks to the modules and configuration packs new organizations.
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.
Creating such a pack or a module is really easy. You can get the doc there.
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! You won't have to wait for a livestatus module enhancement that the other modules features are ready to got it! :)
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 :)
The shinken enterprise edition
Like I already post on the devel mainling list, I launched the Shinken Solutions company that will be the editor of the Shinken Enterprise solution. It's a redhat package version with additional modules, like enhanced webui and a configuration system.
All monitoring capabilities and distributed features will still be added into the shinken framework like before, and there is no risk that will change in the future :)
The main goal of this version is to be "ready to run" with an already prepared configuration and things like this. The framework is done to be even more flexible, so you have the choice. Lot of enhancements on the webui will be backported to the community one in the 2.2 version, like the enhanced /problems page or the new /impacts one :)
You can get a look at the demo server if you want to have a look :)
For the configuration part, I moved the old skonf beta into its own repository. I don't plan to work on it, but if someone want to finish it you are welcome to take the lead on this :)
If you are wondering why we didn't publish this new version under an open source licence, it's just because being a pure open source editor with 100% open is just not possible on this quite technical part if the market. We can exchange more on the comments if you want, but before just ask your self why puppet, cfengine, mongodb, centreon and nginx are also launching enterprise edition after trying to be purely open source ;)
The roadmap
Like after each release, it's time to update our roadmap and see if we keep the future features. We are currently working on this, and you are welcomed on sharing your main priorities for the framework or its modules in the comments :)
WebUI and arbiters
I think one main part will be the enterprise views backport into the community edition, but I'm wondering if we can also work on a feature that I wish since long time ago to enhance the distributed capabilities: the arbiter relays :)
snapshots?
I am also working on another problematic that made us mad at least one time in our admin life: your boss came the morning and ask you why there was so much load at 3am. You can see the load as notification and in the perfdata, but you don't who which processes are faulty. You need a top or a ps launched during the problem.
In order to solve this, I'm thinking about something called snapshots. They are services that will launched deeper state dump (like ps -aux
or top
). But launching such commands too much is not a good idea, especially since their output can be quite long. So why not enable theses services to be launched if some other normal services like Load are not going well during the night? Can be great :)
Now it's time to test the 2.0 RC
Now you can see what changed since the 1.4 version, now you can give a try to this 2.0 RC version. We are still working on the documentation about all theses changes, but should be ok for the final 2.0 relase :)
Ready for testing? Go!
comments powered by Disqus