0.4.1 is finally released it has been a long ride and it is fashionably late as always. but hopefully the delay (which has been very intentional) will help reduce the number of critical bugs encountered by people upgrading. Speaking of upgrading I will post a tutorial about how best to approach that later this week. But first off lets briefly discuss how NSClient++ has evolved sine 0.3.9.
While this post focuses on what's new in 0.4.1 I will begin by giving a quick recap of what's new in 0.4.0 since the previous stable was 0.3.9. The main change in 0.4.0 was the rewritten "core" as well as many of the home brew utility classes was scrapped in favor of boost. And while all this is mainly internal changes a lot of things now work the way it should and a lot of edge cases will no just work since it is standard library function and not custom written code. While I did this I also reworked the settings subsystem to be hierarchical as well as self-documenting. All in all 0.4.0 was the biggest change ever in the history of NSClient++. A lot of new protocols was added as well making the list: NRPE, NSCA, NSClient (check_nt), SysLog, SMTP, Graphite. The extensibility was extended by adding support for internal python scripts as well as .net support. An interesting side effect of the new core is platform independence meaning you can now use NSClient++ on Linux (and while not all modules are supported more are added in each new version) I also start to incorporate real-time checks starting with event log monitoring. Last but not least over 10.000 unit test was added to help improve code quality and reduce the number of regression issues. Just a final reminder the configuration file format has changed but the old (nsc.ini) is still supported and more importantly you can easily migrate to the new (nsclient.ini) format. Please note that while you can use both and migrate between them they are not compatible as both keys and section names have changed their names.
In the check department we have a lot of new features. in general the shift towards real-time monitoring is continuing as well as the focus to modernize and provide platform independence for checks. The first brand new platform independent module is ChecklogFile which provides similar features as CheckEventLog for checking text (log) files. This module has a new improved syntax over CheckEventLog which will be added to CheckEventLog (and many other modules as well) if deemed a good interface.
To seamlessly integrate real-time monitoring in "active" (aka NRPE) style setups we have provided another new module called SimpleCache which can be used to store real-time results for checking via for instance NRPE.
The combination with the cache and the two log file checks provides a way to efficiently process massive file with millions of lines without impacting system performance.
In addition to this we also introduce the SimpleFileWriter module which can direct the results to a file similar to what NSCA server does on Linux. This means in theory NSClient++ could now replace NSCA server component.
In addition to this there is there usual myriad of bug fixes and enhancements.
The most notable enchantment is the performance counters which are now working (again) on various localized windows.
Also don't forget to look into the various command line helpers such as nscp sys --help" and "nscp eventlog --help and nscp wmi --help for helping you diagnose and configure checks as well as even provide unit testing for your monitoring environment.
On the protocol side the main focus has been on security as well as fixing various bugs in the new protocol stack introduced in 0.4.0. This means we now have FULL ssl support including certificate based authentication. I would almost dare say that finally the tag line from the logo "secure monitoring daemon" is finally true! In addition to this we have introduced check_mk support (both client and server) as well we NRDP and Graphite. Other notable fixes and enchantments include full ipv6 support as well as retry handling to better cater for network issues as well as proper timeout handling.
one of the most notable feature here is the settings subsystem which has gotten a lot of fixes making it a lot easier to work with in addition to ini file we now support registry as well as remote http. But a lot of bug fixes has gone into the various components as well and hopefully most of the bugs introduced in 0.4.0 has been fixed. For me the most noticeable ting was the performance data parsing which had lots of issues in 0.4.0.
This has been a big focus are and the new command line syntax improvements makes this the first time I can say that it is a joy to work with the command line I have almost entirely started to use the command line for configuration changes for instance. We have also introduced a myriad of ways to work with your settings file including validating, generating and even removing all default values (good to clean out your config file). hopefully this will help resolve your configuration issues.
The most important thing to understand about the new configuration syntax is the use of the double dash (--) which can be a bit confusing to the casual observer but in essence it is pretty straight forward everything after the double dashes are sent to the module anything before "will be intercepted if understood by NSClient++". Best way to illustrate this is comparing nscp nrpe --help with nscp nrpe -- --help where the first will give you information about how to configure logging and loading settings file and what not where as the latter gives you the NRPE options such as host port command and arguments.
Building NSClient++ is now a breeze on both Linux and Windows due to some nifty helper scripts (I am looking at you fetchdeps.py) and there is a fully fledged (not really) sample plugin if you want to try out writing custom plugins. I have also fixed almost all -Wall warning on gcc so should look nice when you compile now. I also have for internal use setup on-commit builds in Ubuntu, Debian and centos so seems we are well underway to have a stable Linux environment. I am still looking for insight into how better turn NSClient++ into a nice option on the Linux side as well.