An often requested feature is to include the top-5 consumers of high CPU load in the result from check_cpu (or checkCpu). I have often discarded this as a non-core feature since it is not something I think should be part of NSClient++ instead I think it should be a script. Since no-one has created such a script I figured it would make a nice blog post so here I describe in a step by step guide how to create such a script for NSClient++.

This is a YouTube video from my presentation at OSMC this year. The good folks over at Netways kindly allowed me to post the video here on my blog.

As always I really enjoyed the conference as much as the social aspect of it. It truly is one of the best conferences in the field. This was my sixth year which as I noted earlier started out a bit weird. I will not cover the limousine story here again instead this is purely about the conference.

The conference started off with the usual introduction by bernd who did it in English this year which I think was nice but quite frankly the usual “food is in the food area” and “conference is in the conference are” I can pretty much understand even in German. As I only speak English I will, as usual, only cover the English track here.

Well, this is an odd post. I find it difficult to start to be honest. How do I write about my adventures without it sounding strange or bizarre? But perhaps it needs to sounds bizarre for that was how it felt to me. I know this is all a gag but it is interesting how well my mind failed to understand that at the time.

A lot of people coming to NSClient++ has a background in NRPE since it is a common transport mechanism for check results on Linux.

And while NSClient++ is fully NRPE compatible it allows for more control and has more features which can make it seem difficult to get started with. This is a guide for getting started with NSClient++ from a NRPE perspective.

Just thought I'd drop a short note mentioning my presentation for NWCNA 2013 has been accepted and I will be presenting there.

The talk is (surprise surprise) about the new features of NSClient++ with a heavy focus on the up-coming 0.4.2 version which will take real-time monitoring to a whole new level.

The biggest reason for Nagios success is the ability to extend it with custom scripts which makes it one of the most powerful monitoring systems. Now Nagios is not the only place where you can extend your monitoring! NSClient++ provides many ways to extend it with scripts and since I have gotten many questions about how to use scripts with NSClient++ lately I have decided to write this tutorial to help sort out the concepts.

Monitoring the event log can quickly become straining for both the computer as well as the administrator as the event log grows and grows. To make this simpler for both the administrator and the computer NSClient++ 0.4.0 introduced real-time event log monitoring. This means we no longer scan the event log instead we simply scan events as they come in. The benefit, in addition to lowering the resources required, is that we can also get notified instantly when an error occurs instead of every 5 minutes or however often we check the log. Another addition is a simple client o generate event log message to help administrators debug event log filters. This is a quick introduction to event log monitoring and real-time event log monitoring showing how to set up real-time event log monitoring both for active and passive use via NSCA and NRPE.

This is a series detailing how you can leverage WMI to monitor you Computers from a monitoring tool such as Nagios or Icinga. Since I decided to clean up the command line syntax of the WMI plugin for NSClient++ for the up-coming 0.4.0 version a few days ago I will start by showing how you can use what has become an almost full featured WMI client.

One of the new features of the up-coming NSClient++ 0.4.0 will be Python scripting support. The main reason for me to include Python script (apart from the coolness factor) is to write unit tests. Writing unit test for a monitoring agent with a C++ unit test kit is pretty difficult but more importantly not very productive. The main feature of an agent is to interact with the system and thus you need to know about the system to be able to test it (or mock the system which is tedious at best).