Nagios config -- not xml?

[Kertzman, Sam]

> 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