Integration for Oxidized

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?

Format modifier sounds useful. Does the Observium API provide that?

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.

Why not just use the existing devices endpoint?

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.

I still don't think there's any further work to be done on this. It works for us without code modification, using the config that I posted a year ago. 

Is work still being done on this? I noticed it's marked as in progress but there hasn't been any updates in some time.