Some monitoring guys /

Hi,

This is our first tutorial, and of course we are starting for the very start: how to install shinken :D

We want to have a running shinken installation on a simple linux box. We will take a debian 7, but I'll also give you the required packages names for redhat/centos6 64bits.

Your shinken daemons will need a user/group to run. It's name is quite obvious, it's just shinken.

root@debian# adduser shinken
root@debian# id shinken
uid=1000(shinken) gid=1000(shinken)

Now your user/group is ok, you need to install some dependencies for shinken installation : * python-pycurl : (great and powerfull) lib for http connexions between the shinken daemons * python-pip : installation tool for python lib or tools from pypi.

root@debian# apt-get install python-pycurl python-pip

As our dependencies are ok, we can now install our shinken daemons:

root@debian# pip install shinken

Let's have a look at the paths that are used by shinken:

• /etc/shinken: all your configuration will be there
• /usr/bin/shinken-*: the shinken daemons scripts
• /var/lib/shinken: where you will find the shinken modules or your check plugins
• /var/log/shinken: the logs (what did you expect? :) )

In order to start your new daemons, you just need to use the init.d script:

root@debian# /etc/init.d/shinken start

Your can look at your daemons by checking your shinken user, and even query a daemon:

root@debian# ps -fu shinken
root@debian# curl http://localhost:7770/
OK

We can look at the only host that is checkd by default: the localhost :) Like all hosts, it's configuration is in a file in /etc/shinken/hosts/:

root@debian# cat /etc/shinken/hosts/localhost.cfg

By default this host is a dummy one, with no real checks (generic-host is a default template that give default values for an host). We want some basic linux monitoring (disks, load, memory, I/O and stuff like that). That what monitoring packs are done for. Lof of them are available on the shinken.io exchange site. Let's look what is available for our linux host, by using the shinken command that allow to query the shinken.io site.

First we need to init it (to generate the ~/shinken.ini file with all the paths to the shinken directories:

root@debian# shinken --init

Then you can start to search for linux pack:

root@debian# 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

We got some options for monitor our linux. I'm a big fan of agentless monitoring, so I'm choosing the linux-ssh one that allow us to check a linux with just a ssh key on it. We just need to install it:

root@debian# shinken install linux-ssh

In the current 2.0 version, it will download the configuration pack, but not the plugins. You can download them and install them like this :

root@debian# cd /tmp; wget BLABLALBA
root@debian# unzip BLABLBLA
root@debian# cp -r BLABLA/*py /var/lib/shinken/libexec/
root@debian# chown -R shinken:shinken /var/lib/shinken/libexec/
root@debian# chmod a+x /var/lib/shinken/libexec/*py

Theses plugins are launching commands by ssh, and so they need to login to the distant server. The good way to manage this is to authentify with a ssh key. One important note here: the shinken daemon run under the shinken user, so it must the the key of this user.

root@debian# su - shinken
shinken@debian$ ssh-key-gen

And we must deploy this key on the monitored host too, with the shinken user (by default, you can change it on the hosts configurations):

shinken@debian$ ssh-copy-id -i ~/.ssh/id_rsa shinken@localhost

Now we can give a try to this plugin to see if all is OK:

shinken@debian$ /var/lib/shinken/libexec/check_load_by_ssh.py -H localhost -i ~/.ssh/id_rsa
BLABLA

$ 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!

written by jean gabès