article header image

I will be speaking at the Open Source System Management Conference  in Bolzano this year which is held at Sheraton on April 10.

My presentation will be about: "Why we do monitoring Wrong!" which is something I am rather passionate about and I will hopefully inspire some of you to drastically change how you do monitoring! I don't want to spoil anything but the future will eventually catch up with us...

article header image

A tutorial for writing a quick and simple Lua script which will turn check_cpu into a multi functional check which return top CPU consumers. In last weeks edition I introduced the various parts we need to make this a reality. And that idea I have with NSClient++ is to create a Lego box with small multi purpose functions which the users can combine in many different ways. Here I will show you how we can do that.

article header image

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++.

article header image

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.

article header image

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.