I am the Chief of Capacity Planning so that is the business context for the question. I am not so much interested in the standard network monitoring aspects (though I will use that) as I am in how I can extend the architecture for my purposes.
We would like to understand if we can:
a) Use Nagios as the "engine" via custom plug-ins to drive the metrics collections
b) Have the custom plug-ins use XML to return the metrics without having to put them into the Nagios database which would make it easier for us to process into our database.
Another facet is that we would like to put plug-ins on the servers that allow us to auto-discover the servers attributes (# CPU's, amount of memory, IP address, etc.) to keep the info current in out CMDB both for new servers as they are installed and afterwards to catch changes.
Any thoughts you may on our current concepts for using Nagios in this manner would be appreciated.
Nagios is a very flexible product that can undoubtedly accomplish what you want to do. It is very capable of accommodating custom-written plugins of the sort you describe. For some more information, take a look at an article I wrote about Nagios a few months ago.
Regarding your two specific questions, here's what I would say:
You can use Nagios to drive custom plugins (there are also a large number of community-contributed plugins that might serve your purpose). Nagios is architected to allow plugins; the plugins are installed on the remote machine and executed via the central Nagios server. The plugins can pretty much do anything you choose, so you should be able to accomplish what you want.
Regarding returning the info via XML and having Nagios store it in a separate database, I am not sure if the native Nagios protocol and server can implement that. You would need to take a detailed look at the documentation to see what it is capable of. If it can't be done natively, you have a couple of choices:
1. Modify the Nagios source code to enable XML and use of another database. While this is an option, I wouldn't recommend it, as it's difficult to manage unusual source forks in open source projects.
2. Design your plugins to return XML data to another server that you write, which places the data into your desired storage mechanism. In this way you take advantage of Nagios and extend it through plugin extension (which it's designed for) rather than modifying the basic architecture.
This was first published in July 2005