Details
-
New Feature
-
Resolution: Unresolved
-
Minor
-
None
-
Professional Edition
Description
It would be nice if there was (even simple) integration to Oxidized, like there is for RANCID.
Oxidized is a more modern implementation of RANCID (GIT vs CVS/Ruby vs Perl/TCL/Expect), and generally has a more mordern API available for integration.
Attachments
Activity
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.
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?
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.
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.
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.
Additional patches to have Observium use Oxidized API and trigger config collection for this are in progress 
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=' |
The ideal integration here would actually utilise the Oxidized API so the Oxidized system can exist anywhere; rather than on a file system immediately accessible to the Observium webUI.
e.g. config from https://oxidized-not-obserivum-server.org.tld/node/fetch/[NODE]
Observium would also expose a list of hosts (may already be in API?); that Oxidized would use as a list of devices to monitor,
https://github.com/ytti/oxidized/blob/master/docs/Sources.md#source-http
Syslog (SNMP trap to syslog where necessary) alerting matches for config change events would trigger Oxidized based collection of new config; which in turn would trigger Oxidized based alerts in close to real time for changes.
Any progress here?