That sounds pretty good, it would suit my needs just fine and it's generic
enough that I can see plenty of other uses for it. I'll start hacking something
up and see if I run into any issues, otherwise I'll post a rough plan soon.
Duncan
________________________________________
From: Craig Miskell [cr...@stroppykitten.com]
Sent: 05 September 2011 00:16
To: OpenNMS Code Development and Bugs
Subject: Re: [opennms-devel] Getting node lists with status out of REST
Hi,
Well, how about something like:
/rest/availability?filter=<whatever>
That way it's not cluttering up the information returned by the Node
rest service, and minimises the number of queries. It's a concrete set
of data that should be exposed for reading. Actually, given that
availability can be for a number of different entities, perhaps it
should be:
/rest/availability/<entity>?filter=<something>&period=<period>
where <entity> is "node", "service", or anything else for which OpenNMS
can calculate an availability ("applications" maybe one day?)
It can return an array of "availability" records, each specifying which
entity it refers to, and the availability over the given period.
Efficiency will be down to the server-side doing sensible queries.
Filter is optional (implying "all").
How does that sound?
Craig
On 02/09/11 04:28, Duncan Mackintosh wrote:
> (Sorry for the slow reply, bank holiday weekend made me forget about it)
>
> Proper availability on the nodes would be nice. At the moment one can deduce
> it per-node anyway, as outages and number-of-services are visible, but it
> seems a sensible metric to expose directly.
>
> In my specific case even your proposed availability wouldn't help, because I
> need data for possibly a few hundred nodes on the map at once - so if it's
> not in the dataset returned by opennms/rest/node/?<filter> then I'd have to
> fetch it one node at a time, which I suspect would kill browsers for big maps.
>
> Having a list with little information and details available per node covers
> many use cases, but it makes it hard to write things like this map where I
> need a specific set of information about a large number of nodes at once. One
> option might be to expand the criteria usable in /rest/node/x/<details> and
> have it return a list of nodes followed by the requested information? So then
> I could write opennms/rest/node/?nodeparentid=null&limit=0/availability and
> get a list of <node><availability/></node><node>... The server-side code
> would get a bit messy trying to decipher the URLs though. As you say, it
> could be that REST just isn't fit for that type of data set anyway.
>
> Duncan
>
> ________________________________________
> From: Craig Miskell [cr...@stroppykitten.com]
> Sent: 25 August 2011 20:59
> To: OpenNMS Code Development and Bugs
> Subject: Re: [opennms-devel] Getting node lists with status out of REST
>
> On 26/08/11 2:04 AM, Duncan Mackintosh wrote:
>> Cheers Craig, that's about what I was assuming was the case to be honest.
>> The hardest thing I've found to try and get out of REST was 'node
> availability
>> over last X days' - the db function that calculates this looks at
> sum(outages)/count(managed services),
>> the latter of which isn't something you can fetch in bulk over REST as
> it's in the form
>> rest/nodes/<node criteria>/ipinterfaces/. I *could* expose a list of
> all ip interfaces through
>> REST, though I'm not sure if that's creeping too far. Your thoughts?
>
> Well, I see that as an attribute of a node. BUT, given the likely
> calculation cost (not hideous, but definitely non-trivial) *and* that it
> is over a variable number of days, I'd see it as better exposed via
> another sub resource of node, e.g.:
> /nodes/{id}/availability?hours=X
> (with various options for specifying the time period. Any one of hours,
> minutes, seconds, days, weeks, months and years should give clients
> sufficient options :))
>
> It's only a GETtable resource, and I think it's quite justifiably a
> separate resource because "availability" is a major and well known
> metric. Exposing it this way would be rather cool IMHO as it's getting
> beyond just the basic data model, and into exposing the deeper
> information stored/created by OpenNMS.
>
> There is possibly a case for creating a /node/{id}/metrics/<foo>
> hierarchy (where "availability" is the first of the possible <foo>) but
> I suspect it's too early for that (we need to see what other metrics, if
> any, need to be exposed before doing that, lest we end up with a
> lonesome single metric in a tree by itself :)).
>
> Craig
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Please read the OpenNMS Mailing List FAQ:
> http://www.opennms.org/index.php/Mailing_List_FAQ
>
> opennms-devel mailing list
>
> To *unsubscribe* or change your subscription options, see the bottom of this
> page:
> https://lists.sourceforge.net/lists/listinfo/opennms-devel
> Cambridge Broadband Networks Limited Registered in England and Wales under
> company number: 03879840 Registered office: Selwyn House, Cambridge Business
> Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Please read the OpenNMS Mailing List FAQ:
> http://www.opennms.org/index.php/Mailing_List_FAQ
>
> opennms-devel mailing list
>
> To *unsubscribe* or change your subscription options, see the bottom of this
> page:
> https://lists.sourceforge.net/lists/listinfo/opennms-devel
--
Craig Miskell
Systems Administrator, Catalyst IT
DDI: +64 4 8020427
==
You don't change the way people think by changing what they say.
You change the way people think with HEADLESS CHARRED BODIES
FLYING THROUGH THE AIR. BLOOD! FLAMES! HELLFIRE AND DAMNATION!
-- Alistair Young
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
Cambridge Broadband Networks Limited Registered in England and Wales under
company number: 03879840 Registered office: Selwyn House, Cambridge Business
Park, Cowley Road, Cambridge CB4 0WZ, UK. VAT number: GB 741 0186 64
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
