Recently I wrote about the changes in NSClient++ 0.5.0 and its REST API capabilities. Icinga 2 bundles the NSClient++ installer and additional check commands in the “nscp-local” namespace for your convenience for a while already now.
The documentation highlights a short example for querying performance counters with the Icinga 2 client as command endpoint and local NSClient++ check plugin calls.
While testing the 0.5.0 integration I’ve also taken the steps of adding service checks for every available check command we have added so far to the Icinga 2 template library. I thought sharing this with you will hopefully generate feedback for documentation updates – how you are currently using NSClient++ in combination with the Icinga 2 client? (more…)
When releasing Icinga 2 in its final version, we got quite a lot of feedback on why there is no agent, and how to monitor remote clients. Back in the beginning of 2014 we already had an idea on how to implement it, but you’d better design, re-design and even re-design such an important feature last. Especially when there are existing solutions out there that users can adopt.
Remote Clients – the “Agent”
That is merely the reason why everything took longer than expected. Furthermore, an “agent” is understood quite differently by different users. One thinks of a full-featured Icinga 2 instance with local configuration, local check scheduler and host/service discovery on the master. Others just want to a secure way of executing checks remotely, and drop the old-fashioned insecure NRPE protocol. And yet, users don’t care about their operating system – an agent must run on Linux, Unix – and Windows. Luckily Icinga 2 was designed to work on Windows from conception. Before you continue reading – all the mentioned roles and distributions work and have been implemented in this release 2.2.0 already.
Installation & CLI idea
But there is more – how to safely install that agent? While installing an Icinga 2 (HA) Cluster is relatively easy, it still requires knowledge on SSL certificates and other manual configuration steps. So we noticed that many users struggled with it. And such a thing just for an agent? No, there must be something more simple. In the design and concept phase of the agent bits in Icinga 2, we came up with our very own cli implementation. It supports you by adding setup wizards for master and client nodes, doing all the SSL setup magic. Furthermore, the Icinga 2 cluster protocol was extended to support CSR-Auto-Signing. Simply said – your client nodes can be installed with a single generated ticket number, no need for local SSL certificates.
Going further, remote satellite nodes with their local config will report their objects to the central master. There are cli commands to assist you in adding the nodes, black/whitelisting hosts and services and also generating local configuration on the master. There is plenty of newly written documentation for that, so be sure to check it out. Oh, and if you don’t require that, and just want to execute remote commands – that’s all in there as well.
CLI with Auto-Completion
That cli framework also supports context based bash auto-completion. We’ve also integrated existing scripts like “feature enable” or “object list” into the cli, and removed the old shell and python scripts. The “python-icinga2” package is gone for that very reason too. Generating your CA and SSL certificates is also supported out of the box. Similar to the agent setup on Linux, the native Windows installer uses the icinga2 cli commands too.
More dynamic configuration with apply for
While this is already one of the most epic things we’ve ever implemented – cli & agent – we did not stop there. Users have been asking, why custom attributes (the vars. identifier) could only hold strings, numbers and boolean values but not arrays or dictionaries. The latter could be used like groups for better apply rules expressions.
So, we added that support, and decided to dump the values as json into the existing backends, adding a new column “is_json” to allow existing interfaces to show that correctly, as seen in Icinga Web 2 already. But we did not stop here – why not extend the existing apply rules to loop over arrays/dictionaries? That way you can save yourself a lot of typing and generate new service apply rules based on host custom attributes. Sounds complicated, but once you’ve tried it, you’ll never want to go back. That gets even more interesting when you generate the host from your CMDB, Puppet, <insert #devops tool here>. It certainly provides an even more dynamic approach. Take a look at the configuration screenshots for the new “apply <objecttype> <optionalprefix> for (key => value in dict)” syntax 🙂
More config magic – apply with variables
In a different situation – back with the agent, and its dependencies, we’ve learnt, that setting local variables in apply rules should be able to read host or service attributes in that scope. For instance, you would want to generate host and service dependencies for your vmware or cloud farm, and set the parent_host_name attribute directly in the child hosts inherited template. No need for duplicate dependency rules – control them using apply and a locally-scoped variable set. You’ll find a more telling example on the doumentation as well, and also that this feature isn’t dependency-exclusive – it can be used for all apply rules.
And while that could become tremendously complicated, the “object list” cli command allows you to filter by name or type wildcard strings. Plus, we’ve worked a lot on possible configuration errors, making them as telling as possible, even for complicated nested apply rules.
More Features: Graphite, GELF
Apart from the core feature set, we noticed at Icinga Camp San Francisco that many already use the GraphiteWriter in production – which is freaking awesome! While chatting with Grant from SpaceX, we’ve also made sure that everyone out there can configure the host and service prefix template, thus adding more statistics and making it more usable afterall. You’ll also recognize the GelfWriter feature, which was contributed by the graylog2 developers and we found it so nice to include it in 2.2. There’s a talk on this years OSMC on that topic, more details once OSMC is over.
Get Icinga 2
Last but not least – thanks everyone for their ongoing feedback. The documentation and also the example configuration has been overhauled in many places. Be it better explanations of apply rules and their expressions in general, or detailed examples on how to use the new apply for rules. We’ve even shipped in an example configuration. The old strategy with single objects just does not work that well now with ever more dynamic apply rules, and only confuses you, the user 😉
The cluster vagrant boxes ship new demo configurations for cluster and remote check execution bits, if you want to give it a try.
Package builds are running, and hopefully everyone gets 2.2.0 asap. While downloading, please be sure to read the Changelog and all the changes introduced with this release. They require your attention! 🙂
As always, thanks for using Icinga 2 and watch out for Icinga Web 2 🙂 Feedback, bugs or feature requests are always welcome!
PS: This video was taken during Icinga 2 development. Get the Windows Agent from packages.icinga.org and try it yourself!
