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.
The developer team of OMD (Open Monitoring Distribution) released the version 0.54 today. This version contains bugfixes and lots of updated packages including Shinken 1.0.1, Thruk 1.26, PNP4Nagios 0.6.17, NagVis 1.6.5 and many more.
This post demonstrates how to include and deploy Pentaho Kettle as a regular Web application. There are some pitfalls you should be aware of.