Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: Add dynamic name prefix & suffix to reset metric name #13418

Closed
wants to merge 2 commits into from

Conversation

cavivie
Copy link

@cavivie cavivie commented Jun 9, 2023

This feature adds dynamic name prefix and suffix to Telegraf. This PR was modified to improve that the name (prefix/suffix) value cannot restore the name prefix suffix.

Here is an example config below:

[[inputs.disk]]
   name_prefix = "my_app_namespace_"

[[outputs.influxdb]]
  namepass = ["my_app_namespace_*"]
  name_prefix = ""
  urls = ["http://influxdb.example.com"]
  database = "db_other"

Keep the final output metric name is the name of the input, more routing metric exmaples:

Metrics are prefixed in the input, which is then used to select the output.
The metric name will be removed/overrode/appended in the outputs before writing.

[[inputs.exec]]
# ...
name_prefix = "exec1_"

[[inputs.exec]]
# ...
name_prefix = "exec2_"

[[inputs.exec]]
# ...
name_prefix = "exec3_"

[[inputs.exec]]
# ...
name_prefix = "exec4_"

# this will only get exec1
[[outputs.influxdb]]
# ...
namepass = "exec1_*"

# this will only get exec2
[[outputs.influxdb]]
# ...
namepass = "exec2_*"
# this will remove the previously set prefix
# so final metric name will be first input name
name_prefix = ""

# this will only get exec3
[[outputs.influxdb]]
# ...
namepass = "exec3_*"
# this will override the previously set prefix
# so final metric name will start with exec3v1_
name_prefix = "exec3v1_"

# this will only get exec4
[[outputs.influxdb]]
# ...
namepass = "exec4_*"
# this will appends to the front of the previously set prefix
# so final metric name will start with telegraf_exec4_
name_prefix = "+telegraf_"

Required for all PRs

resolves #

@telegraf-tiger
Copy link
Contributor

telegraf-tiger bot commented Jun 9, 2023

Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla

@cavivie
Copy link
Author

cavivie commented Jun 9, 2023

!signed-cla

@cavivie cavivie changed the title Plugin group feat: Add Dynamic Name Prefix & Suffix Jun 9, 2023
@cavivie cavivie changed the title feat: Add Dynamic Name Prefix & Suffix feat: Add dynamic name prefix & suffix to reset metric name Jun 9, 2023
@powersj
Copy link
Contributor

powersj commented Jun 12, 2023

@cavivie can you please file an issue and detail what problem you are trying to solve in more detail? Thanks

@powersj powersj added the waiting for response waiting for response from contributor label Jun 12, 2023
@cavivie
Copy link
Author

cavivie commented Jun 13, 2023

@powersj In order to meet the situation discussed below, we provide a similar solution as follows from @sparrc :

[[inputs.exec]]
# ...
name_prefix = "exec1_"

[inputs.exec]]
# ...
name_prefix = "exec2_"

# this influxdb will only get exec1
[[outputs.influxdb]]
# ...
namepass = "exec1_*"

# this will only get exec2
[[outputs.influxdb]]
# ...
namepass = "exec2_*"

Not only do we add and match prefixes, but we also want to remove this prefix from the output to maintain consistency with the input.

[[inputs.exec]]
# ...
name_prefix = "exec1_"

[inputs.exec]]
# ...
name_prefix = "exec2_"

# this influxdb will only get exec1
[[outputs.influxdb]]
# ...
namepass = "exec1_*"
name_prefix = "" # keep output metric name with input name

# this will only get exec2
[[outputs.influxdb]]
# ...
namepass = "exec2_*"
# name_prefix = "" # not set keep output metric name with prefix exec2_

See discussions below:

This goal allow us to complete functions similar to namespacing plugin at the metric level.

@telegraf-tiger telegraf-tiger bot removed the waiting for response waiting for response from contributor label Jun 13, 2023
@cavivie cavivie force-pushed the plugin-group branch 3 times, most recently from adca5b8 to af0ad3b Compare June 13, 2023 07:27
@cavivie cavivie changed the title feat: Add dynamic name prefix & suffix to reset metric name feat!: Add dynamic name prefix & suffix to reset metric name Jun 13, 2023
@telegraf-tiger
Copy link
Contributor

@powersj
Copy link
Contributor

powersj commented Jun 13, 2023

@cavivie,

I asked for you to file an issue and instead you provided me a list of 4 closed issues, all explaining how it is possible to do today. The one remaining open issue proposed creating a namespace for each plugin to control the flow. However, the closed issues have comments about how and why this is not as straightforward as it seems.

Without understanding why the current mechanism causes friction I am not inclined to add yet another way to do something.

@powersj powersj added the waiting for response waiting for response from contributor label Jun 13, 2023
@cavivie
Copy link
Author

cavivie commented Jun 14, 2023

@powersj Thank you! I agree and know the truth behind this. I just want to complete routing through namepass/prefix/suffix and remove prefix/suffix when outputting. I know there are already many solutions, but this is the initial solution I came up with, but it cannot be implemented because prefix/suffix only has append but no restore function, which makes me have to give up this processing method. But if other solutions are used, one is ugly, and the other is unclear about the existence of namespaces. I think other solutions can meet the requirements, but they are not elegant enough. Anyway, we can close this PR.

@telegraf-tiger telegraf-tiger bot removed the waiting for response waiting for response from contributor label Jun 14, 2023
@powersj
Copy link
Contributor

powersj commented Jun 14, 2023

I think other solutions can meet the requirements, but they are not elegant enough.

I don't disagree that they are not elegant ;) however, in order to maintain backwards compatibility a re-write isn't an option currently. Adding new options as I mentioned above, might be ok but we would really want to understand why we are doing that and ensure it makes sense before adding the additional maintenance burden.

@powersj powersj closed this Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants