Jolokia haben sich mittlerweile zum
de-Facto-Standard beim Nagios-Monitoring von Java entwickelt. Das
belegen etliche Blog-Postings, die Downloadzahlen und zahlreiche
Kundenprojekte, die ConSol durchgeführt hat.
Aus der Erfahrung von über einem Dutzend individueller Workshops haben
wir einen Intensivkurs destilliert, der in Bezug auf die Nagios-Anbindung von JEE-Applikationsservern keine Fragen mehr offen lässt.
In dieser Schulung lernen Administratoren, das Maximum aus Jmx4Perl
herauszuholen. Neben theoretischen Grundlagen wird vor allem viel Wert
auf praktische Übungen gelegt.
Weiterer Details zum Inhalt und eine Online-Anmeldung finden sich
Fragen zu dem Kurs beantworten wir auch gerne hier in den Kommentaren
oder im Forum.
Version 1.36 of the Thruk monitoring gui has just been released. The changelog is quite huge this time. There is a new dashboard plugin called the ‘Panorama View’ Addon. There are a lot more reports included now. And finally there is a plugin manager included in the config tool which lets you easily manage your plugins and addons.
It has been a while since our last final release for Citrus. Now I am proud to announce the final 1.2 release. The package ships with a huge list of new features and improvements that I would like to highlight in a few lines for you.
When working a lot with git knowing which branch you are in is an important information. Putting the branch information in your bash prompt makes this information always visible and also shows immediatly if you are in a folder managed by git.
This is how it looks:
13:46:50 sven@tsui:~/projects/Thruk (master) %>
All you need is a simple function in your .bashrc
Monitoring Unix clients is very easy with the check_by_ssh plugin. The only prerequisite is public-key-based access and installation of some plugins on the remote side. Then, running a check is as easy as:
check_by_ssh --host 10.177.3.39 --logname nagios \ --command "lib/nagios/plugins/check_swap -w 15% -c 8%"
The drawback of this method is extra load on the nagios server. With every check, a ssh process is forked which has to do a complete handshake with the remote side. With newer ssh implementations it is possible to have a persistent connection which requires only one handshake at startup. All the following ssh connects use the already established connection, which saves a lot of cpu cycles.
Here are the instructions to combine check_by_ssh with such a persistent tunnel.
The well-known plugin check_by_ssh is a wrapper around the ssh client program. Unfortunately the path to ssh is defined at compile-time and remains hard-coded in the check_by_ssh binary. Usually this is /usr/bin/ssh. If you want to use features which are not implemented in your distribution’s ssh, but in an alternative ssh binary, you have to recompile check_by_ssh. Here is a patch which makes it easy to switch between multiple ssh binaries using a command line parameter.
Every now and then some of our 7x24 hosts / services need a daily or weekly maintmode for regular restarts. Normally you would have to create 2 new timeperiods because you don’t want both hosts in a cluster to be restarted at the same time. This is not just way to much work, it also adds unnecessary complexity because
nobody can see the maintmode unless you look into the config files.
Thats where recurring downtimes will become handy and latest Thruk Version includes this new feature.
One of my bigger OMD installations consists of 13 sites. The visualization layer uses the Thruk interface. This alternative web ui can read data from multiple livestatus backends and display the host and service objects in one unified view. For this purpose i have one extra site called gui which only starts an apache process. I then point my browser to http://…./gui/thruk
The addresses of the livestatus backends have to be written into a config file, thruk_local.cfg. Now what if my list of 13 sites would be constantly changing? What if new OMD sites would be created, others deleted on a daily basis? I would have to edit the config file every time. With the new init-hook-feature, OMD will do this automatically for me.
Keeping an eye on cpu usage of your servers is one of the basic things in system monitoring. For Nagios (and Shinken, of course) you’ll find plenty of plugins for this task. However, i was never happy with the way they work. Most of the plugins you can download work like this: read a counter - sleep - re-read the counter. This technique not only adds an extra delay to the execution time of the plugin, but it only shows the state of things within a small time frame. If you run such a plugin every 5 minutes and it sleeps 5 seconds between the two measurements, you don’t know what happens in the other 295 seconds. This is a very small sample rate.
You probably have noticed that development of the new Nagios-compatible monitoring system Shinken progresses very fast. Every few hours there is another commit at GitHub, where Shinken’s code repository is hosted. Now if you want to try all these new features immediately, there’s a very easy method which requires a simple update-command instead of a fresh install.