Better way to retrieve snmp setting for ifName plugin

[Hipska]

Feature Request

Opening a feature request kicks off a discussion.
As discussed in #7763 (comment)

Proposal:

Make it possible some way to retrieve the community string (and other snmp config) directly from the config set for the snmp input.

Current behavior:

Community string (and other snmp config) needs to be configured in ifName plugin as well

Desired behavior:

Let ifName plugin figure out from which plugin the metric comes and use the config from that plugin if possible.

Use case:

Usually each device (or group of devices) has its own specific community string and that would make a huge config even more huge.

[powersj]

Hi Hipska,

Looking through old issues to get status on them.

It sounds like this is trying to not require the community config value for the ifname processor by knowing that value from the input, is that correct?

What would be required to have the processor know this in advance?

Thanks!

[Hipska]

Correct, I think it could be possible if a metric could have a reference to the input plugin where it originated from somehow. What do you think?

[Hipska]

Easier to implement would be the community string could come from a tag.

[Hipska]

@powersj What if I added an option to inputs.snmp which adds the required client config parameters as tags? On its turn, the processors.ifname can read from the tags?

[powersj]

@Hipska,

If we have the knowledge of what needs to get done in the snmp input plugin, why not add this as a feature of the snmp plugin?

Thanks

[Hipska]

@srebhan is proposing to have a list/table of client parameters in the plugin config instead of putting the info in tags..

[Hipska]

@powersj @srebhan, can you please give a descision here, so the PR can be on time for 1.29?

[powersj]

@Hipska,

@srebhan and I have been talking about this today and we need to reset our understanding. We both understanding that there is friction between how to efficiently share configuration data between the SNMP plugin and when you do lookups.

What we both do not fully understand is why we could not do this in the SNMP plugin itself? Does this really need to be a new processor?

Thanks

[Hipska]

Yeah, sometimes you need another processor first to split the index if it is a combined one.

The ifname was originally created to work with the sflow input. It can also be useful with the snmp_trap plugin.

[powersj]

sometimes you need another processor first to split the index if it is a combined one

Can you give us a short example? Would go a long way to help us understand the situation better. Thanks

[Hipska]

See for example TIMETRA-SAP-MIB::sapBaseStatsEntry where the index is a combination of 3 fields. 2 of them are available to gather from the table, but svcId isn't and I need that one to get the TIMETRA-SERV-MIB::svcName with snmp_lookup, so this processor comes in between:

# Parse TIMETRA-SAP-MIB::sapBaseStatsEntry index
[[processors.starlark]]
  alias = "sapBaseStatsEntry_index"
  order = 1
  namepass = ["sap"]

  ## Source of the Starlark script.
  source = '''
def apply(metric):

	index = metric.tags.pop("index", "0.0.0").split(".")

	metric.tags["svcId"] = index[0]
	metric.tags["sapPortId"] = index[1]
	metric.tags["sapEncapValue"] = index[2]

	return metric
'''

  ## Only need to run when the tag exists
  [processors.starlark.tagpass]
    index = ["*"]

A sample index we receive is: 300121.1342177331.1121 and then we want the content of TIMETRA-SERV-MIB::svcName.300121 to get the name of the service as tag on the metric.

And as said before, you can't do lookups when the functionality is embedded into inputs.snmp and the info comes from inputs.snmp_trap or inputs.sflow or others..

There is already some table merging functionality included in the snmp input, but that only works for one:one relations, not one:many or many:many relations.

[srebhan]

@Hipska I see. But then how would sflow pass the required information you describe in your initial description (e.g. community string)? I think there is no sensible way around defining that data in the processor again. The only thing I see would be to share via file that all relevant plugins can include... What do you think?

[Hipska]

Yes, that would probably be a better solution.

I already expressed I'm open for that as wel, I just wanted a confirmation this is the way you both want to go: #8010 (comment)