Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNMP plugin mapping #1729

Closed
mattbakerau opened this issue Sep 8, 2016 · 4 comments · Fixed by #1784
Closed

SNMP plugin mapping #1729

mattbakerau opened this issue Sep 8, 2016 · 4 comments · Fixed by #1784
Labels
feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin

Comments

@mattbakerau
Copy link

mattbakerau commented Sep 8, 2016

I have started using the new Telegraf SNMP plugin, and so far working really well but I have hit an issue that I am trying to either work around or see if could get a fix for?

I am using the mib cbgpPeer2Table to get BGP session information from a Cisco router. Most of the stats are collected fine, but the number of prefixes for each peer is kept in a seleparate table with a suffix on the mapping.

For example if I snmpwalk cbgpPeer2RemoteIdentifier I see:

SNMPv2-SMI::enterprises.9.9.187.1.2.5.1.12.1.4.192.168.0.1 = IpAddress: 119.168.0.1
SNMPv2-SMI::enterprises.9.9.187.1.2.5.1.12.1.4.192.168.0.2 = IpAddress: 119.168.0.2
SNMPv2-SMI::enterprises.9.9.187.1.2.5.1.12.1.4.192.168.0.4 = IpAddress: 119.168.0.4

If I then fetch cbgpPeer2State I get:

SNMPv2-SMI::enterprises.9.9.187.1.2.5.1.3.1.4.192.168.0.1 = INTEGER: 6
SNMPv2-SMI::enterprises.9.9.187.1.2.5.1.3.1.4.192.168.0.2 = INTEGER: 6
SNMPv2-SMI::enterprises.9.9.187.1.2.5.1.3.1.4.192.168.0.4 = INTEGER: 6

To collect this I use the following telegraf config works and it works as expected:

[[inputs.snmp.table]]
 name = "BGP"
 inherit_tags = [ "hostname" ]
   [[inputs.snmp.table.field]]
     name = "remoteAS"
     oid = ".1.3.6.1.4.1.9.9.187.1.2.5.1.11"
     is_tag = true

   [[inputs.snmp.table.field]]
     name = "remoteID"
     oid = ".1.3.6.1.4.1.9.9.187.1.2.5.1.12"
     is_tag = true

   [[inputs.snmp.table.field]]
     name = "state"
     oid = ".1.3.6.1.4.1.9.9.187.1.2.5.1.3"

My problem occurs when I try to include data from cbgpPeer2AcceptedPrefixes. The results from an snmpwalk looks like:

SNMPv2-SMI::enterprises.9.9.187.1.2.8.1.1.1.4.192.168.0.1.1.1 = Counter32: 0
SNMPv2-SMI::enterprises.9.9.187.1.2.8.1.1.1.4.192.168.0.2.1.1 = Counter32: 15464
SNMPv2-SMI::enterprises.9.9.187.1.2.8.1.1.1.4.192.168.0.4.1.1 = Counter32: 11

As you can see there is a suffix of ".1.1" on these results, so telegraf is just ignoring the entries as they don't match any tag.

Is there some way to work around this, maybe applying either a "map" or somehow specify a suffix?

@sparrc
Copy link
Contributor

sparrc commented Sep 8, 2016

@phemmer thoughts? do you know if this is possible?

@phemmer
Copy link
Contributor

phemmer commented Sep 8, 2016

ack! Yeah, as the plugin stands, there is no way to do this. The simplest solution I can think of would be to add a oid_index_suffix parameter to inputs.snmp.table.field. In this case the value would be oid_index_suffix = "1.1"
This shouldn't be too hard to implement.

@mattbakerau
Copy link
Author

That's great news. oid_index_suffix sounds like a workable solution to me

@JerradGit
Copy link

+1 on this feature as well, I am running into a similar issue

.1.3.6.1.4.1.27611.1.4.5.110.32.1.2.1.0 = STRING: "aaaaa"
.1.3.6.1.4.1.27611.1.4.5.110.32.1.2.2.0 = STRING: "bbbbb"
.1.3.6.1.4.1.27611.1.4.5.110.32.1.2.3.0 = STRING: "ccccc"
.1.3.6.1.4.1.27611.1.4.5.110.32.1.4.1.0 = Counter32: 1
.1.3.6.1.4.1.27611.1.4.5.110.32.1.4.2.0 = Counter32: 25
.1.3.6.1.4.1.27611.1.4.5.110.32.1.4.3.0 = Counter32: 0

For whatever reason the SNMP implementation with this vendor placed the index second last in the OID

@sparrc sparrc added the feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin label Sep 15, 2016
@sparrc sparrc added this to the Future Milestone milestone Sep 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants