Open Hipska opened 4 years ago
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!
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?
Easier to implement would be the community string could come from a tag.
@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?
@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
@srebhan is proposing to have a list/table of client parameters in the plugin config instead of putting the info in tags..
@powersj @srebhan, can you please give a descision here, so the PR can be on time for 1.29?
@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
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.
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
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.
@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?
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: https://github.com/influxdata/telegraf/issues/8010#issuecomment-1824008130
Feature Request
Opening a feature request kicks off a discussion. As discussed in https://github.com/influxdata/telegraf/pull/7763#issuecomment-676801651
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 wellDesired 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.