XML, JSON, Webservice or something new ?

yann.jouanin.list at intelunix.fr yann.jouanin.list at intelunix.fr
Tue Aug 18 10:27:57 CEST 2009


Using CDB or SQLite look a good thing for me.

I didn't improved Nagios2JSON a lot cause it's a C CGI and it take long

time to sanitize everything.. but if someone wants to help me in improving

Nagios2JSON, then Welcome!



As pointed out Thomas, I also wrote a patch to get status.dat directly

writen in JSON but I think the major problem is what ever you want you'll

parse the complete status.dat.

Having a File DB instead of status.dat would be a real way to help in

writing new XML or JSON interface in an easy way. I also did a python

status.dat parser and rewrite Nagios2JSON with it to test how easy it

becomes also with atomic query...



Yann













On Tue, 18 Aug 2009 04:11:09 -0400, Thomas Guyot-Sionnest <dermoth at aei.ca>

wrote:

> -----BEGIN PGP SIGNED MESSAGE-----

> Hash: SHA1

> 

> On 17/08/09 10:08 PM, Max wrote:

>> Hi Derrick,

>> 

>> On Mon, Aug 17, 2009 at 8:32 PM, local.coder<code at novageeks.org> wrote:

>>> I am back to writing some code for a new project involving Nagios. As

>>> part of this I need light weight data access to status.cgi data.

>>> Initially I was planning on modding ministatus.cgi which I know is not

>>> part of the contrib anymore but it is a good starting place. At the

same

>>> time I looked into the status of something more standardized. I would

>>> prefer to code to a standard that we can all get behind. The

Nagios2Json

>>> looks nice in that JSON is a basic format and gives me what I need,

>>> however the current project is not Version 3+ compliant. I also found

>>> the NXE addon for XML output but that has not been updated in some

time.

>> 

>> The only problem with the current nagios2json is that you cannot do

>> discrete queries of hosts/services etc, so not quite ready for AJAX

>> UIs.

> 

> I like the JSON patch as it implement cleanly a different way of writing

> status data to status files. However I had in mind doing something

> similar but with CDB. CDB is a small and very efficient read-only

> database format that has a C and PHP (among others) APIs. It store only

> key-values and it is designed to be written once and acceded read-only;

> just as status.dat works currently. OTOH, unlike status.dat it could be

> queried instead of parsed in full so it would be a perfect fit for

> systems that use an advanced web interface but want to avoid the burden

> of ndodb.

> 

>>> Before using one of these and making them work I would like to see a

>>> standardized model for the XML or JSON data structure. I have seen

>>> several items on the wishlist for a webservice interface and that would

>>> also work really well but again a standard API would need to be

created.

>>>

>>> What are others doing for small format host and service data and is

>>> anyone deeply interested in coming up with some standardized XML or

JSON

>>> data templates ?

>> 

>> I vote JSON :), works well with all sorts of web frameworks and for

>> high volumes of data much less verbose than XML, we are needing this

>> as well and I have been speaking with a teammate of mine on enhancing

>> Nagios2JSON as we will be exposing a RESTful interface within our

>> organization that lets people GET data out of Nagios with HTTP and

>> will let them change our Nagios configuration as well to perform CRUD

>> on our configs through web services.   Nagios2JSON is Nagios 3

>> compatible (just have to use the VCS rev), maybe we could work

>> together on it to enhance Yann's existing code?

> 

> I sure would vote JSON over XML, but with JSON you still have to parse

> the whole status file for every request. That just doesn't make any

> sense for things like showing the status of a single host, especially on

> large systems which have lots of services. This is even more true when

> AJAX comes in mind; to be usable scripts have to respond quickly. If for

> example you click to expand a host detail, it will be much faster if the

> backend can just fetch and parse that host's data instead of parsing a

> large file...

> 

> - --

> Thomas

> -----BEGIN PGP SIGNATURE-----

> Version: GnuPG v1.4.6 (GNU/Linux)

> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

> 

> iD8DBQFKimId6dZ+Kt5BchYRAtDVAJ9qauN7iumyo6EI1pVcmdeRTXpb3gCeOG0P

> w+ECcF+BgA1Y1MR2sGDYgQs=

> =0ECl

> -----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

> _______________________________________________

> Nagios-devel mailing list

> Nagios-devel at lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/nagios-devel

------------------------------------------------------------------------------
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