Nagios config -- not xml?

[donavan nelson]

Hi Ethan,

Excellent product, thank you very much for your efforts.  Can I send
money/hardware/beer/pizza anywhere for you?

Now, based on this email, would it be safe to assume on my part that the
template based config files will be staying the same at least past V2 of nagios?

Thanks,

.dn

--
Donavan Nelson
4wx Networks
www.4wx.net

---------- Original Message -----------
From: "Ethan Galstad" <nagios at nagios.org>
To: nagios-users <nagios-users at lists.sourceforge.net>
Sent: Mon, 27 Jan 2003 23:09:44 -0600
Subject: RE: [Nagios-users] Nagios config -- not xml?

> Been catching up on a few days worth of email, so I'll put my two 
> cents in.
> 
> A few people had suggested XML config files before I started writing 
> the template-style format code, but I didn't care for it.  XML is 
> too chatty for my liking when I'm editing config files by hand.  
> Plus, an XML parser would add to the overhead of the daemon and 
> CGIs.  I don't know how much overhead exactly, but it would probably 
> be more than the overhead of the current template-based routines.
> 
> I would tend to steer people towards Ian Stokes' idead to generate 
> template-style config files from an XML source, rather than making 
> Nagios process the XML natively.  The same thing holds for native DB 
> support of config data.  Its better to write a few scripts to 
> generate template-style config files from a DB source, rather than 
> have Nagios check the DB natively.  Some people want to use a DB as 
> a backend, some want XML files, others might want something 
> different.  The easiest thing to do is make everyone convert to a 
> common denominator - the template-style config files.
> 
> On 27 Jan 2003 at 21:16, Kertzman, Sam wrote:
> 
> > > Very interesting that this XML debate has come up.  I spent several days
> > > last week re-writing some of my core Nagios config files in XML then using
> > > XSLT to transform them into the current Nagios format.
> > > 
> > > What does XML buy you?
> > 
> > A ton of added complexity.  Every time the CGI's run, they read the cgi.cfg
> > file.  If you use a standard-library xml parser, the amount of code run
> > and/or size of executable will be much larger.  If you use a simplified
> > single-purpose xml parser (which I have written and used in the past) then
> > you loose the advantage of standard library code.
> > 
> > 
> > > 1. Ability to write a schema to check that you have your syntax correct.
> > > (OK, pre-flight check _probably_ does most of this already, but I'm sure
> > an
> > > XML schema with a schema validating parser would be MUCH easier)
> > 
> > Actually the pre-flight check is the only check that matters.  If the
> > application you are configuring cannot read the config files, then any other
> > check is secondary.  If the data fits the schema, but the pre-flight check
> > fails, then it still fails.
> > 
> > 
> > > 2. Single, standard, format, rather than current split format (i.e. some
> > > files are flat VARIABLE_NAME VALUE format, and some are pseudo object
> > > definitions with "define NAME {...}".
> > 
> > Of course the things that are using a simple format are simple things to
> > configure, using xml will only add characters to the simple things, which
> > because they are simple don't need complex data representation.
> > 
> > 
> > > 3. Much simpler layout to avoid massive cross-referencing which _does_ do
> > > your head in (this was the reason I started re-writing my configs in XML).
> > 
> > The cross-referencing will not go away.  It is an artifact of the problem
> > you are describing, not the config file you are using.  If you are
> > processing the config files by machine, you have to deal the actual
> > complexity (of the problem, not the file format) in the code anyway.
> > 
> > 
> > > 4. Collapse 5 different config files into 1 (OK, maybe 2 if  you want to
> > keep
> > > CGI or Resource separate).  Currently there is:
> > > 
> > > 	i) Main nagios.cfg file
> > > 	ii) resource.cfg file
> > > 	iii) hosts.cfg file (object definitions -- probably pointing to
> > > cfg_file and cfg_dir meaning lots of others files are used as well)
> > > 	iv) cgi.cfg
> > > 	v) extended config file.
> > 
> > The cgi.cfg and ext*info.cfg files are read by the cgis and should be
> > separate so they don't have to parse through a giant config file when they
> > run.  This is a scaling issue.  Also, permission issues for the files should
> > be considered.  Perhaps I want all the config for a group of servers in a
> > single file, and only certain admins have access to the configs for certain
> > servers.  Perhaps only the nagios administrator can change the nagios.cfg
> > file  The split-up config files confer a number of benefits.
> > 
> > 
> > > 5. Make use of network definitions for other monitoring or maintenance
> > > applications.
> > 
> > That would imply a standard tags and values all the platforms.  Does this
> > standard format exist, and does anyone use it if it does?
> > 
> > 
> > > Below, you can see an example of my new "hosts" file which describes nodes
> > > in the network I am monitoring.  XML provides a tree  structure, but can
> > be
> > > "enhanced" to graphs by using cross references.   Trees are a perfect
> > > starting point for allowing the XML itself to represent the 
> > > basic network topology.  Furthermore, if I want a new service, I just add
> > <service
> > > type="SERVICE-NAME" /> to the particular node and, voila, that node now
> > has
> > > that service defined for it.  All the details about the IP address or node
> > > name are "in context" from the XML, and the "generic" service template is
> > > used.  If I want a custom service definition for that node, instead of
> > > having <service type="..."/> I would have
> > > 
> > > <service name="CUSTOM-SERVICE">
> > > 	<!-- Service definition details go in here -->
> > > </service>
> > > 
> > > Anyway, it seems like there are interested parties in making this happen
> > --
> > > I certainly do not feel that the current configuration system is scalable
> > to
> > > extremely large systems (hundreds nodes) quickly and easily.
> > 
> > That problem is solved with a management front-end, not with a file format
> > change.
> > 
> > 
> > > Here is a taste of my XML:
> > > 
> > >     <node name="nagios" group="true">
> > >         <contactgroup>admins</contactgroup>
> > >         <node name="particle-physics-oxford" group="true">
> > >             <node name="clusters">
> > >                 <node name="edg-testbed" group="true">
> > >                     <node   name="tbce01" type="linux">
> > >                         <alias>Computing Element 01</alias>
> > >                         <address>163.1.243.105</address>
> > >                         <service type="ping" />
> > >                         <node   name="tbwn01" type="linux">
> > >                             <alias>Worker Node 01</alias>
> > >                             <address>163.1.243.155</address>
> > >                             <service type="ping" />
> > >                         </node>
> > >                     </node>
> > >                     <node   name="tbse01" type="linux">
> > >                         <alias>Storage Element 01</alias>
> > >                         <address>163.1.244.55</address>
> > >                         <service type="ping" />
> > >                     </node>
> > 
> > In what way is this easier or clearer that the existing format?  Perhaps for
> > different people with different backgrounds things are different, but this
> > format is every bit as hard to read as the existing format, and xml is a lot
> > more syntactically heavy.
> > 
> > Please don't add extra, unneeded complexity to the file formats.  Currently
> > they are simple.  Simple is good.  XML is not simple.  XML is complex and
> > through it's complexity brings some benefits, however, the existing formats
> > deliver what you need, and are simple and easy to debug by hand, which XML
> > is not.
> > 
> > kertzman
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > 
> 
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
------- End of Original Message -------



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com