XML, JSON, Webservice or something new ?

Thomas Guyot-Sionnest dermoth at aei.ca
Tue Aug 18 20:12:23 CEST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sven-Göran Bergh wrote:
> I like this thread! It raised another thought...
> (Please ignore me, if I am totally of track :-)

Please try avoiding top-posting...

> If we think of it as two parts, a filebased DB backend
> and a webservice. Wouldn't it make sense to take a
> look at the DB schema used by Merlin & Ninja, or is it
> too heavy? Possibly the same schema could be used and
> potentially open for the use of Ninja (the officially
> "new" Nagios GUI) without involving Merlin. Don't get
> me wrong here. I really like Merlin, it rocks, but if
> you do not need all its funtionality a lightweight
> DB only alternative whould be nice.

What we're looking at here is efficient lightweight backends. ndodb has
some great flexibility, but this comes with a great price as well.
Personally I'm fine with the current system (as with thousand others
Nagios users) and therefore don't want to adventure myself in a NDO
setup as I would have little benefits for what I would do with it..

So think of ndodb as an option. What other options would there be?
Currently, the biggest slowing factors in the CGIs for large
installations are walking logs (which is another story) and parsing the
status CGI. This can be exacerbated with the use of AJAX as a simple
call say to show status details of a single host would require parsing
the whole status file(s). The suggestion in this thread is a replacement
for plain text files that allow any Nagios interface to use them more
efficiently.

> I realize that some information will be missing, but
> the potential of code re-use is there.
> 
> For the backend my vote is on SQLite. It supports more
> client apps any way.

If you want to use an SQL backend that should be part of NDO. I think
it's a really bad idea to try updating a SQLite database directly from
nagios. SQLite has heavy requirements on the system to guarantee
reliability (and usually when you see fast SQLite benchmarks it's either
 that SQLites default to *NOT* syncing data to disk which is unsafe, or
because the system fake it with isn't any better). Therefore SQLite
could block the core Nagios daemon preventing it from doing any useful work.

The current way Nagios works is to dump all status at once at regular
intervals so that it doesn't have to update status all the time. With
ndodb, on the other hands, it sends all events to a daemon which *queue*
them and flush them to the database as performance allow. This is more
efficient and if properly designed should prevent Nagios from blocking
if the database is busy. Also AFAIK Nagios still uses plain text files
for persistent data storage.

CDB is a good replacement for the current status files because it's a
simple key-value "database" (no notions of tables or SQL here) that is
meant to be written once then accessed read-only, just like nagios do
with all its status files. Here's how CDB is descrived by its author:


cdb is a fast, reliable, simple package for creating and reading
constant databases. Its database structure provides several features:

 * Fast lookups: A successful lookup in a large database normally takes
   just two disk accesses. An unsuccessful lookup takes only one.
 * Low overhead: A database uses 2048 bytes, plus 24 bytes per record,
   plus the space for keys and data.
 * No random limits: cdb can handle any database up to 4 gigabytes.
   There are no other restrictions; records don't even have to fit into
   memory. Databases are stored in a machine-independent format.
 * Fast atomic database replacement: cdbmake can rewrite an entire
   database two orders of magnitude faster than other hashing packages.
 * Fast database dumps: cdbdump prints the contents of a database in
   cdbmake-compatible format.

Besides command-line tools it has APIs for multiple languages including
C, PHP, Perl and Python

> I am not the man to judge pros & cons of JSON vs XML.
> But if we are talking web services, the client app
> does not need to be a web page. Is JSON suitable for
> other client apps as well? Just asking, I don't know.

My belief was that besides the CDB-based status data file, a web service
would be able to act as an interface to Nagios using JSON, XML and/or
any other data serialization package. Obviously a web frontend could
also support multiple backends which could include direct CDB support -
I'd love to see that in the official one (which I haven't really looked
at yet).

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqK7wYACgkQ6dZ+Kt5BchbkwgCfYdbSSHKzmatwAXyTCytdsxd0
HLoAniZQfQnzI9+GKgUFZx4GZs0gx2oJ
=diEc
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july




More information about the Developers mailing list