XML, JSON, Webservice or something new ?

[Max]

Hi thomas,

COB sounds promising, your point is well taken about parsing largish
Nagios retention.dat / objects.cache files over and over just to get
one piece of data for a web UI.

My thought was to have a JSON proxy service (not a CGI) as a
persistent daemon with caching for reads to not have a full scan hit
every time.

A persistent  proxy would of course work well with any backend - ndo,
flat file, COB, etc.


On 8/18/09, 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