eric.kuhnke at gmail.com
Sat May 21 00:09:22 UTC 2016
It is fairly easy to extend the snmpd on a Linux host to retrieve data from
non-SNMP sources... For example:
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
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 at 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
> 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.
> -- Nathan
More information about the NANOG