SNMP: Add capability to combine multiple metrics as fields in the same measurements

[titilambert]

This is the issue (proposal) based on: https://groups.google.com/forum/#!topic/influxdb/v1PQmUE0usM

[juliusloman]

I'd propose following design:

• put new attribute "measurement" which will contain name of the influxdb's measurement this get/bulk/table request data will go to
• introduce new array of measurements into input.snmp . each measurement can then have single_record attribute set to yes or no. If set to true, data in same collection interval will be joined (of course you loose some time precision). If set false, no joins will be performed, just written to same measurement.

Config example:

 [[inputs.snmp.table]]
    measurement = "myMeasurement1"

 [[inputs.snmp.get]]
    measurement = "myMeasurement2"

 [[inputs.snmp.get]]
    measurement = "myMeasurement2"

 [[input.snmp.bulk]
    measurement = "myMeasurement3"

 [[input.snmp.measurements]]
     name = "myMeasurement1"
     single_record = true

Some line protocol examples: Table request with measurement="interfaces" and single_record=false:

> interfaces,host=192.168.1.29,instance=eth0,unit=octets ifHCInOctets=488264518i    1457443305004647980
> interfaces,host=192.168.1.29,instance=eth0,unit=octets ifHCOutOctets=121438595i 1457443305004977059

Table request with measurement="interfaces" and single_record=true:

> interfaces,host=192.168.1.29,instance=eth0,unit=octets ifHCInOctets=488264518i,ifHCOutOctets=121438595i 1457443305004647980

Is this feasible?

[titilambert]

@juliusloman I think so :) I like this idea :)

@sparrc Could you explain the difference, if it exists, between

interfaces,host=192.168.1.29,instance=eth0,unit=octets ifHCInOctets=488264518i    1457443305004647980
interfaces,host=192.168.1.29,instance=eth0,unit=octets ifHCOutOctets=121438595i 1457443305004977059

and

interfaces,host=192.168.1.29,instance=eth0,unit=octets ifHCInOctets=488264518i,ifHCOutOctets=121438595i 1457443305004647980

Is it necessary to be able to get both outputs ?

[sparrc]

nope, that is not necessary, those are exactly the same

edit: we should prefer the latter, because that creates less network and write traffic

[titilambert]

@sparrc Thanks for your comment ! So the next question is: Should we create a patch inside Telegraf plugin core, to group automatically measurements with same name ? (for each input plugin ?)

[sparrc]

I would prefer not to because this would create much larger and more complicated buffer structures (rather than just a channel, as it is now).

Most plugins should be able to write their metrics this way. SNMP is a bit of an outlier...

[Infiniverse]

Is there any progress on this issue? I'm just about to start collecting SNMP data on a production system, and am wondering the best way to do it. Will this bite me?

[rhinst]

I'm also very interested in this ability. In fact, it will determine whether or not we're able to use influxdb at all for our application.

[wilsncc]

I was a little disappointed when I noticed how Telegraf laid out SNMP data like this, I doesn't seem to make all that much sense.

As with @rhinst I cannot in good faith recommend we shift from RRD/MRTG to InfluxDB/Telegraf until this is resolved.

[Infiniverse]

It's open source so it should be a relatively easy fix for someone who knows 'GoLang' to do. Alas, I don't yet know GoLang so I've not been able to do it (easily) myself yet.

[sparrc]

unfortunately it's not too easy with the current SNMP plugin, hence #1389

[sparrc]

this is now available in 1.0 RC 1 with the new SNMP plugin, please see here to download the latest version: https://github.com/influxdata/telegraf#linux-deb-and-rpm-packages, and the changelog for details on the new SNMP plugin.