It is fairly easy to extend the snmpd on a Linux host to retrieve data from non-SNMP sources... For example: http://www.adventuresinoss.com/2009/09/30/the-many-uses-of-net-snmp/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... Anything you can retrieve with a shell script can be turned into a 1-minute-interval cron job that outputs a text file with a number in it, then the SNMP 'extend' parameter in the snmpd.conf can be used to 'cat' the file. For example something from a solar charge controller that only speaks RS485 over an RS485-to-RS232 (or USB) bridge. Or data retrieved via curl and sed. I use this to graph WSDOT traffic driving times patterns and flows and feed them into a charting system. For smaller setups you can have all the shell scripts for data acquisition on the same host that runs the snmpd. On Fri, May 20, 2016 at 4:43 PM, Nathan Anderson <nathana@fsr.com> wrote:
'lo all,
Is anybody out there aware of a piece of software that can take data from an arbitrary source and then present it, using a MIB or set of OIDs of your choosing, as an SNMP-interrogatable device?
We have some CPE that supports SNMP, but considers it to be a mutually-exclusive "remote management" protocol such that if you use another supported method for deployment and provisioning (e.g., TR-069), you cannot have both that AND SNMP enabled simultaneously. It's one or the other.
We currently monitor and graph some device stats for these CPE with Cacti, but we want to be able to provision using a TR-069 ACS. The ACS can collect some of the same data we are graphing right now, but cannot present it in a fashion that is nearly as useful as the way Cacti/RRDtool does (not to mention the staff is already used to navigating Cacti). We know what SQL database table the stats are being stored in by the ACS, though, so my thought was that there must be some way that we can have a host respond to SNMP gets and then have it turn around and collect the value to be returned from a database. Basically, an ODBC -> SNMP proxy. We'd then point Cacti at that IP instead of the individual CPEs. But I can't seem to find anything like this.
Thanks,
-- Nathan