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