All,

I've added the first stage of a patch for better Oxidized support via the existing JIRA ticket from 2016, https://jira.observium.org/browse/OBS-1986

What I'm building is what I've described in the JIRA comment, which basically means that we shift to using the Oxidized API properly rather than files on an immediately accessible filesystem.

Not too hard to write and the rest of it'll be done shortly.

But I am very interested in feedback about Oxidized.

Particularly as the project is in need of maintainers to really keep it going - https://github.com/ytti/oxidized#help-needed

Are you using it? 

How well's it going?

Do you agree with what I'm proposing to add to Observium and see value in it? (See below)

OR; have you found something better and have since moved away from Oxidized to another OSS or a COTS product?

NOTE: Rants about Ruby/Oxidized or SVN/git being bad exist in the same leaky mentally challenged boat as rants about RANCID/Perl being bad. Don't bother.

At the moment the main thing that's missing from the existing reuse of the RANCID  code in an Oxidized environment; is the ability to see diffs when it's a git repo rather than Subversion.

A secondary issue with the existing RANCID support is that the Observium web interface needs access to SVN/configs via the file system. So you either need run Oxidized on the same box; or export the file system to it using NFS/etc.

There's a lot of reasons why you might be wanting to run Oxidized elsewhere and don't want to expose a file system from it back to your Observium implementation.

-- From JIRA --

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.

-Colin

_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium