Hi All,
First cut of a working patch with all the features I want is now available.
Patch plus screenshots & instructions etc here: https://github.com/colin-stubbs/observium-oxidized
Feedback desired if possible.
Note the TODO list at the bottom, some changes to the patch will occur soon, DO NOT patch anything you're not comfortable reversing a patch to or blowing away entirely.
-Colin
On Fri, 8 Mar 2019 at 16:48, Markus Klock via observium < observium@observium.org> wrote:
Hey, Great work! Proper Oxidized support would be awesome in Observium, I really would like to switch out all my existing rancid-installations. Keep up the good work! /Markus
Den fre 8 mars 2019 kl 07:21 skrev Colin Stubbs via observium < observium@observium.org>:
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/%5BNODE]
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
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium