Add Tags Processor

[KarstenSchnitter]

Metrics created by different input plugins can have tags attached to provide
additional information. Those tags may either be configured in the global_tags
section in the telegraf.conf file or may be provided by the respective plugin.
Telegraf provides a filtering mechanism with the taginclude property to only
include certain tags. However, this mechanism will also drop all tags, that are
not explicitly listed. This applies to the plugin specific tags as well as the
global tags.

In order to always provide global tags, this processor adds all configured tags
after the tag filtering was applied. Therefore all those tags will always be
present. This is useful in the case, were only some tags provided by an input
plugin are needed, but it is not exactly known, which other tags may be attached
by the input plugin. Using this processor provides the ability to use
taginclude for the wanted tags from the input plugin while still retaining
global tags. It eases the configuration as the global tags do not need to be
repeated in every taginclude.

This implementation will add the configured tags to all metrics, no filtering is
supported. When adding the tags, values of tags with the same key will be
overwritten by the processor.

Required for all PRs:

• Signed CLA.
• Associated README.md updated.
• Has appropriate unit tests.

[danielnelson]

I'm considering #3362 as an alternative way to do this, what do you think of it?

[KarstenSchnitter]

The problem I tried to solve was not of conflicting tags but incomplete information when creating a configuration by merging parts from different sources. I have the situation, where I provide a basic configuration including the output plugin. The user then can configure plugins (input, processors, aggregators) specific to the use case. There is a policy what tags need to be present in each metric to ensure correct attribution to the emitting system. Therefore I would need a mechanism to ensure precedence of globally configured tags over tags configured in the plugin configuration. As far as I understand, #3362 still allows the plugin to suppress global tags by the tags subtable.

[danielnelson]

That makes sense, perhaps we should aim to make this work on more than just tags, the modifications that are available on all inputs and aggregators are:

• name_override
• name_prefix
• name_suffix
• tags

It could look very similar to an input plugin, tricky part is coming up with a good name:

# Apply standard modifications to matched metrics
[[processors.standard]]
    name_override = "baz"
    [processors.standard.tags]
      foo = "bar"

[KarstenSchnitter]

Including name_override, name_prefix and name_suffix seems very reasonable. Naming indeed is hard. To me standard suggests slightly, that the plugin is always needed. Maybe policy is more suitable:

# Apply modifications to ensure policy for matched metrics
[[processors.policy]]
    name_override = "baz"
    [processors.policy.tags]
      foo = "bar"

I will start on implementing name_override, name_prefix and name_suffix.

[KarstenSchnitter]

I have implemented name_override, name_prefix and name_suffix. All that is missing is the name of the plugin. We discussed the names standard or policy. @danielnelson, do you have some suggestion on that?

[danielnelson]

After some discussion here, I think we should go with override, the idea being that these values could modify existing tags. Later on we might also add a add_default processor that would work the other way, it wouldn't have the name related options, but it will make more sense if/when we add field support.

[KarstenSchnitter]

Thanks for the input. I will change the name and alter the README.md accordingly.

[danielnelson]

Merged for 1.6, thanks!