Lasting few days for the 2013 Nagios World Conference, where -let's hope- Nagios Core 4 will be presented in detail, we can know the masterlines this new release will follow by both reviewing the Andreas Ericsson's presentation at last year Nagios Conference and diving in the Nagios 4 beta anorexical documentation (now available at its beta 5 release).
In a nutshell
Nagios 4 main features can be summarized as:
- New check execution philosophy for radical performance improvement.
- Query handler support for allowing fetching on-demand data from the own core process.
There are other minor features like -yeaaaah, finally- the possibility of inhibiting service notifications while the parent host is down (this post is one of the most visited in my blog, so the solution is being really welcome) or the removed embedded-perl support (though at this point I have some doubts, read on and you'll understand), but basically the big enhacement is the performance boosting and the great new feature is the query handler support.
Check execution philosophy: The Worker
Up to Nagios Core 3, every time a check had to be run, Nagios Core process forked in a similar child process for running the script (plugin in Nagios jaergon) bound to the check and, once done, returning the result to the parent process and dying. This way was all but efficient due to the resources needed for forking big processes (as Nagios core was) multiple times.
The idea with workers is radically different: Nagios core process is not going to run any check, in fact it will request it to much smaller (and thus much more efficient) processes called workers whose only mission will be running checks and returning results. If you already know Consol Labs mod-gearman, the concept is the same.
Without entering in detail about how the core will meet workers and how it will distribute the load (that's not the matter of an overview article), the possibilities that workers bring are exciting: enhanced distributed systems, freedom for creating complex load balancing scenarios,... a reading to the mod-gearman documentation gives a real idea of the potential of the worker approach.
Query handlers
Up to Nagios Core 3, the usual ways of getting data from the core process were:
- By parsing the status and log files or, what is the same, by using the cgis included in the core package
- By exporting data via a broker module like ndomod
In both cases the info didn't come on a on-demand way, ie, there was no way of getting fresh data when we wanted, we had to wait for the process to publish it.
Query handlers allow getting data from (ie, interacting with) the core process on a on-demand way. As the name reveals, they are pieces of code designed for handling certain queries that can be fetched to the core by using the nagios libapi (though I suspect that a Perl module interface will be available soon).
For those (as I) loving brokers this new approach doesn't eliminate this actor, in fact the query handlers complement them. One example might be a Nagios core web interface (like Centreon, Icinga or Nagios XI) that supports multiple concurrent users quering data like the status of a given service. Obviously seems stupid to address every query to the core process when it could export that info to a database (via, for instance, the ndomod+ndo2db pair) just when it changes becoming free of attending multiple queries from multiple users.
Summarizing
By reading the sources I mention in the head of this article, these seem to be the main features of the new Nagios Core release. I have to admit that I don't belong to the core development scene so, until Nagios Enterprises officially published the new core features (up to now this is the only official info) we won't have a full view of how happier we'll be with this new release.
| Tweet |
|
