What’s New in NSClient++ 0.5.0#

The main goals of the 0.5.0 is t make NSClient++ easier to use and more future proof.

PLEASE NOTE

NRPE has been changed in 0.4.3, for details please see the 0.4.3 changelog.

New and improved WebUI#

While I really loved the new WebUI in 0.4.3 it is much a proof of concept. I have in 0.5.0 reworked this to be much more feature complete and usable but more importantly (for me) better architected. The WebUI is now I think ready for prime time and will probably make configuring NSClient++ much simpler. A side effect of the new WebUI is the REST support which NSClient++ now has meaning you can now check/configure/* NSClient++ using a REST API.

Metrics#

While metrics might seem like a dumbed down check command (as it lacks the checks) it is actually the foundation of there next generation of NSClient++. But for end-users the main goal right now is that Graphite and CollectD becomes much simpler. In the future it will also allow for checking compound metrics and other advanced things which is difficult to do today.

Improved clients#

The client for instance check_nrpe was a bit buggy in 0.4.4 and 0.4.3. They have been rewritten from scratch and work much more smoothly now. They also work in many instance where before they did not for instance graphite now works.

Floating point support#

Another small but important change is allowing floating point support in filters the only real benefit of this currently is that you can specify 2.3G as well as check_pdh where you can now check floating point counters. But as this required a major overhaul of the filter framework it has been long in the making and another important milestone.

Filtering on count#

count has been a pain for many people as it accidentally broke in 0.4.3. The problem was that the filter evaluates count on every item this means count < 5 will always be true as the first time count is always 1. This has been fixed and in many cases it will just work. There is however a case when you need to change your filter and that is when you check BOTH count and a value. For instance the following will not work: “count < 5 and load > 20%”. The problem is that count is not available when we check load. Thus “the first core” ends up again in an impossible state count is unknown and once count is known the various cpu values are no longer available. To work around this you can split them up into multiple filters like so: “filter=count<5” “filter=load>20%”.

Breaking changes#

Bugfixes enhancements#

The full list of changes (sorted by context) can be found here:

Additions#

Check commands#

filters and checks (global)#

check_drivesize:#

check_pdh:#

check_eventlog:#

check_log_files:#

check_files:#

check_tasksched:#

check_uptime:#

check_service:#

check_process:#

check_wmi:#

check_always_ok:#

check_multi:#

check_nscp:#

check_ping:#

scheduler:#

Scripts#

External Scripts:#

PythonScript:#

bundled scripts:#

Protocols#

NRPE:#

NSCA:#

NRDP:#

check_nt:#

graphite:#

collectd:#

Core#

Various/Core:#

Metrics:#

WebUI:#

MSI installer:#

Linux:#

API:#