Generating nagios configs from LDAP, nmap, and traceroute

Voon, Ton Ton.Voon at egg.com
Wed Dec 17 12:37:50 CET 2003


Very interesting. I've taken a different tack, mainly because LDAP has not
been implemented in our organisation.

We have a central database (with a web front-end) which talks about the
servers in a generic service way. So we define an environment to consist of
a collection of services (such as webserver, middleware, database, etc) that
are provided on a host. This db also holds information pertinent to the
service (eg, webserver holds the port number, the database holds the sid
information, etc).

Then there is a separate perl script which takes this configuration and then
builds the *.cfg files based on what services are required. Any box with a
service has basic checks (DISK, CPU, MEMORY) included. A webserver will have
a check_http check, a db will have a check_oracle with the defined SID, etc.

I'm currently trying to get a cronjob to update Nagios config every night
based on this info.

I guess there is no reason this information can't be held in LDAP instead of
a central db. I think the power is really in your db configuration and the
gen scripts, but these will be so organisation-specific, that I think there
is little value in passing it round.

Ton

> -----Original Message-----
> From: Luke A. Kanies [mailto:luke at madstop.com] 
> Sent: Tuesday, December 16, 2003 9:38 PM
> To: nagios-users at lists.sourceforge.net
> Subject: [Nagios-users] Generating nagios configs from LDAP, 
> nmap, and traceroute
> 
> 
> Hi all,
> 
> I've just started on a project to generate my nagios 
> configurations, and
> I'd like to know if others have worked on similar projects, 
> and I'd also
> like to know if others would find this work useful, and if so, how.
> 
> One of my barriers to using nagios has always been my unwillingness to
> maintain yet another host list.  I already maintain a list of 
> all of my
> hosts in LDAP, and my nagios configs need to automatically update
> themselves based on that list.  Also, I can't have my nagios 
> configuration
> be the definition of what "should" be running on the system, 
> because then
> when I update the host I have to update Nagios, which I hate.
> 
> So, I'm trying to come up with a design for maintaining my 
> entire Nagios
> data configuration automatically.  My LDAP host list is basically
> self-maintaining (I have a client/server style script that 
> does most the
> work), I already have all of my contacts in LDAP, the network is
> authoritative on what machines each of my machines depends on, and the
> hosts themselves are (usually) authoritative on what services 
> they should
> be providing.
> 
> What I want is something to collect all of that and turn it 
> into a valid
> nagios config.  However, there are still some pieces missing.  For
> instance, the LDAP directory is not currently capable of holding the
> templates for the various object types, and there are some 
> nagios-specific
> details I'll probably want to associate with hosts and contacts.
> 
> So, I think the first step is to create a nagios schema for 
> LDAP.  This is
> the main thing I want to check:  Would I be redoing someone 
> else's work
> here?  It's definitely a no-no to have schema variety.  If no 
> one else has
> ever done this before, then I'll go ahead and create one for 
> OpenLDAP (it
> should be easily usable for most other LDAP servers) and contribute it
> back to the Nagios developers.
> 
> Second is getting the data out of the directory.  I've 
> actually already
> created a set of ruby classes which do this quite well.  I've 
> also created
> a parser in ruby which can parse existing files and glean all 
> the data in
> them; it's a small stretch from where I am to parsing those files and
> putting all of their data into LDAP.  Because I don't 
> currently have any
> nagios configs, I'm less interested in moving data into LDAP, 
> but I'd be
> glad to work with people who would like to transition from 
> storing data in
> flat files to storing it in LDAP.
> 
> Next is figuring out which services a given host should be 
> running.  I am
> currently focusing on external services (i.e., ports), but will later
> visit using nrpe et al to monitor other stuff.  I know that there is
> already an nmap2nagios script, and I would probably plan on utilyzing
> lessons from this script, but because I need the results to 
> interoperate
> with the rest of my data structures I'll probably write 
> something similar
> in ruby.  This tool will specifically support only scanning 
> specific for
> specific ports, as in most cases I don't want to monitor every port.
> 
> Lastly is deducing the dependencies for each host.  
> Apparently not many
> people (none?) have built automated topology tools using 
> traceroute, as I
> could not find any online (well, I could find some that 
> resulted in maps,
> but none that were generically for building topologies).  It should be
> pretty simple to do, so I plan on adding a 'dependencies' method or
> something to my ruby objects that transparently uses 
> traceroute to figure
> out the dependencies.  I may later abstract that into an 
> overall topology
> tool, but unless I have a client specifically request that, I 
> am unlikely
> to do so any time soon.  (I'm an independent consultant and 
> am doing all
> this for a client.)  It also would not be a bad idea to have 
> an option for
> automatically monitoring these extra hosts.
> 
> So, now that you basically know my plans, my main question is:  Has
> someone done something like this before?  I'm slightly 
> incredulous that
> everyone using nagios is hand-editing every config file and manually
> adding every service and every dependency.
> 
> I'm hoping to release all of the code I write, but it will take some
> effort on my part, as my current client has one of those 
> we-get-everything
> contracts.  At the very least I plan on writing an article on my
> experiences and then probably redoing the work in my free time.
> 
> Anyone have any of this experience?
> 
> Thanks,
> Luke Kanies
> Reductive Consulting
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS 
> when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
> 


This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.  
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list