inputs.gnmi tag_only should support arbitrary subscriptionKey

[bewing]

Feature Request

tag_only subscriptions should be allowed to specify the name of the tag used as the subscription key

Proposal:

Current behavior:

The subscription key is hardcoded to the device name + the name tag of the current update:

telegraf/plugins/inputs/gnmi/gnmi.go

Lines 311 to 312 in ecf7e94

	// Update tag lookups and discard rest of update
	subscriptionKey := tags["source"] + "/" + tags["name"]

Desired behavior:

The subscription key should be specifiable on a per-tag subcription basis, possible as a separate config struct

Use case:

While the initial use cases of tag_only worked well with the prior behavior (oc-interfaces ended up with the interface name as the name tag), more complex, multiple-keyed models such as network-instances run into issues.

As an example, reading BGP session state at

/network-instances/network-instance[name=*]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=*]/state/session-state

and attempting to add

/network-instances/network-instance[name=*]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=*]/state/description

as a tag -- we should be using the neighbor_address tag as our key, not the top-level name of the network-instance.

[bewing]

Tag-only subscriptions are basically subscriptions for gNMI updates that we do not emit as measurements, but instead store in memory. Ideally each tag-only subscription would be for a specific leaf, but trying to enforce that would probably require YANG validation, which is a can of worms I'd prefer not to open. A tag only subscription request should have the same structure as a regular subscription request, but also include rules for what other Updates it should be applied to.

If we introduce the concept of a client struct into each worker thread, we can use that to pass in the device address to dial, and their own struct for storing tags. This eliminates the need for a mutex on a single map for all threads.

Each Update is basically a gNMI Path (with keys) and a gNMI value -- we should store Updates that we receive that exact match the full path of a recorded tag subscription in that format. For Updates that we receive that we will emit as measurements, we should enumerate the application rules for all subscriptions, and for each one that applies, apply the leaf name as the tag name, and the leaf value in string format as the tag value.