Integration for Oxidized

Dmitri Kiriljuk added a comment - 2020/10/01 08:06 AM Any progress here?

Colin Stubbs added a comment - 2019/03/12 08:08 AM - edited By the look of the code... combined with my rudimentary understanding of Ruby... it looks like it can handle a path down into the structure that's parsed from JSON ( e.g. .blah.whatever.devices ) , but when it iterates it uses Ruby's .each iterator, which expects an array and can't deal with a hash. So this as a response wouldn't work, (attributes filtered for sanity)   { "status" : "ok" , "count" : 5 , "devices" : { "1" : { "device_id" : "3" , "poller_id" : "0" , "hostname" : "bigip1.lab.tld" , "os" : "f5" , "type" : "loadbalancer" }, "2" : { "device_id" : "2" , "poller_id" : "0" , "hostname" : "cpgaia1.lab.tld" , "os" : "gaia" , "type" : "firewall" }, "3" : { "device_id" : "3" , "poller_id" : "0" , "hostname" : "pavm1.lab.tld" , "os" : "panos" , "type" : "firewall" }, "4" : { "device_id" : "4" , "poller_id" : "0" , "hostname" : "iosv1.lab.tld" , "os" : "ios" , "type" : "network" }, "5" : { "device_id" : "5" , "poller_id" : "0" , "hostname" : "asav1.lab.tld" , "os" : "asa" , "type" : "firewall" } } } But this would,   { "status" : "ok" , "count" : 5 , "devices" : [ { "device_id" : "3" , "poller_id" : "0" , "hostname" : "bigip1.lab.tld" , "os" : "f5" , "type" : "loadbalancer" }, { "device_id" : "2" , "poller_id" : "0" , "hostname" : "cpgaia1.lab.tld" , "os" : "gaia" , "type" : "firewall" }, { "device_id" : "3" , "poller_id" : "0" , "hostname" : "pavm1.lab.tld" , "os" : "panos" , "type" : "firewall" }, { "device_id" : "4" , "poller_id" : "0" , "hostname" : "iosv1.lab.tld" , "os" : "ios" , "type" : "network" }, { "device_id" : "5" , "poller_id" : "0" , "hostname" : "asav1.lab.tld" , "os" : "asa" , "type" : "firewall" } ] }   Filtering of device attributes not needed. Oxidized could be told to start looking and mapping attributes using ".devices" using it's "hosts_location" config option. So really just a switch to change the devices object to an array would suffice. What I don't understand is why the Observium API returns an object of objects there, given that the device ID is used as the object name at present, which is an unnecessary duplication of information. Any receiving code can and should be able to sort the objects based on a value within each object. It seems like an odd design decision IMHO. Also, that's another weird thing about the Observium API at present, pretty well every possible numeric value is returned as a string, not as a JSON number. The only values that don't seem to be are poller and discovery history timings. This is what I mean when I say informal... as without an OpenAPI spec to work with and validate the API against, a functionally incomplete implementation, and with all these little bits of odd implementation, the API looks pretty informal to me.  

Adam Armstrong added a comment - 2019/03/12 07:32 AM Not at present, but the code is very simple and we could easily add extra output formats. Do you know what format it needs to be in?

Colin Stubbs added a comment - 2019/03/11 03:11 AM Format modifier sounds useful. Does the Observium API provide that?

Adam Armstrong added a comment - 2019/03/10 11:47 PM The existing API is the formal API. The correct way to implement this would be using a format modifier on the /devices/ endpoint to return the data in the correct format.

Colin Stubbs added a comment - 2019/03/10 10:12 PM I looked at that. But it doesn't look as though the Observium devices endpoint response format will work with Oxidized's current mapping code, even though it has the ability to specify a starting position (e.g. .devices) the code looks to be limited to iterating through a list rather than a hash/series of objects. Given Observium doesn't really have a formal API at this point, if the project ever gets around to creating one, having a dedicated and very simple endpoint like this gives you the freedom to modify that main devices endpoint response in future without breaking this one.

Adam Armstrong added a comment - 2019/03/08 07:40 AM Why not just use the existing devices endpoint?

Denis Klimek added a comment - 2019/03/08 06:51 AM Great! When it will be public I will show it to our software developers to check versus our custom solution that we developed to use Oxidized in Observium.  

Colin Stubbs added a comment - 2019/03/08 12:14 AM - edited Additional patches to have Observium use Oxidized API and trigger config collection for this are in progress

Colin Stubbs added a comment - 2019/03/08 12:11 AM - edited Newly attached patch adds /api/v0/oxidized endpoint. This allows Oxidized to obtain a device list to attempt to poll via the Observium API. Described here:  https://github.com/ytti/oxidized/blob/master/docs/Sources.md#source-http Example config snippet for Oxidized to Observium is,   source: default : http debug: true http: url: https: //observium.your.domain/api/v0/oxidized map: name: hostname model: os group: type headers: Authorization: 'Basic YWRtaW46YWRtaW4='