Add tag decoration

[grzkv]

We need the ability to decorate some of the incoming records with tags. This can be useful for adding API keys or contextual information.

This can be implemented either by regex or for all records. It makes sense to make it part of rewrite rules in the first case. In that case, it may look something like:

[[tag]]
for = "abc*"
tag = "tagname"
copy = true

[azhiltsov]

I will suggest to implement it the way Influx did. Their template implementation has enough flexibility to enrich incoming data with tags: https://docs.influxdata.com/influxdb/v1.7/supported_protocols/graphite/

[grzkv]

So, the main difference is tag matching in pattern and ability to add several tags at once. Right?

On Wed, 29 Jan 2020 at 16:11, Alexey Zhiltsov notifications@github.com wrote:

I will suggest to implement it the way Influx did. It has enough flexibility to enrich incoming data with tags: https://docs.influxdata.com/influxdb/v1.7/supported_protocols/graphite/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bookingcom/nanotube/issues/6?email_source=notifications&email_token=AAZPGNTM7QNHEU66WN7IB63RAGMBBA5CNFSM4KLIJCE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKHQWPY#issuecomment-579799871, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZPGNTHEDPFLBFGZUXVK53RAGMBBANCNFSM4KLIJCEQ .

[azhiltsov]

In key=value they inherit value from a position within graphite metric name which is more flexible. they actually perform a metric transformation and remove a graphite tree hierarchy, so metrics are flat on the output (we can preserve the original metric with copy=true) and don't have redundant information. They provide a way to ingest 'global tags' to each metric.

[grzkv]

Why would we need this kind of complexity? What is the use case?

The current tag decoration is intended to:

1. add context about where the metric comes from
2. decorate the metrics sent with API keys

[grzkv]

@azhiltsov ^^^