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

Statsd should expose "separator" configuration #876

Closed
kri5 opened this issue Mar 17, 2016 · 11 comments · Fixed by #928
Closed

Statsd should expose "separator" configuration #876

kri5 opened this issue Mar 17, 2016 · 11 comments · Fixed by #928

Comments

@kri5
Copy link

kri5 commented Mar 17, 2016

When using templates using statsd, it seems that it uses a graphite parser, which is good because it reuses existing code.

The main issue here is that e619493 introduces a change in the way it is working, as it uses a "." separator, instead of a "_" previously.

The best would be to provide a way of specifying a separator in the statsd configuration.

Looking at the tests i don't know how they are still passing.

I have no good idea on how to implement that.

@sparrc
Copy link
Contributor

sparrc commented Mar 17, 2016

Can you be more specific? What is not expected? Give some input/output examples

@kri5
Copy link
Author

kri5 commented Mar 17, 2016

@sparrc Considering the documentation of the module, it's expected to have something like that

templates = [
"cpu.* measurement.measurement.region",
"mem.* measurement.measurement.host"
]
which would result in the following transformation:

cpu.load.us-west:100|g
=> cpu_load,region=us-west 100

mem.cached.localhost:256|g
=> mem_cached,host=localhost 256

But it result in having dotted measurement like

mem.cached.localhost:256|g
=> mem.cached,host=localhost 256

@sparrc
Copy link
Contributor

sparrc commented Mar 17, 2016

@kri5 What version are you running and can you show me your config? that should not happen if the convert_names = true option is set

@kri5
Copy link
Author

kri5 commented Mar 17, 2016

@sparrc i do not use convert_names, as that is not what i want to do here

it seems caused because the graphite template parser is called with a '.' separator https://github.com/influxdata/telegraf/blob/master/plugins/inputs/statsd/statsd.go#L434

Before e619493 the parser was called with '_'

convert_names implies that my dashes '-' would transform to '__' and that's not the behaviour i expect.

@sparrc sparrc changed the title Statsd templates does not work the way it's expected to Statsd option to only convert . -> _ Mar 17, 2016
@sparrc
Copy link
Contributor

sparrc commented Mar 17, 2016

okay, that option was added because some users actually want to keep the dot-separated metrics. So I think this issue is basically about separating out two options in the config:

  1. convert . -> _
  2. convert - -> __

@kri5
Copy link
Author

kri5 commented Mar 17, 2016

@sparrc i was more thinking about adding a separator config that would be passed to the graphite parser, to be consistent with the statsd and graphite template documentation, instead of simply passing ".".

@sparrc
Copy link
Contributor

sparrc commented Mar 17, 2016

that's a good idea too, and actually should be fairly simple

@sparrc sparrc changed the title Statsd option to only convert . -> _ Statsd should expose "separator" configuration Mar 17, 2016
@jwerak
Copy link

jwerak commented Apr 13, 2016

@sparrc I have for example metric system.io.r_s -> my metric separator is .
What should be my config to keep it this way?

@jwerak
Copy link

jwerak commented Apr 13, 2016

ok, I can see the problem is in ouput plugin -

https://github.com/influxdata/telegraf/blob/master/plugins/outputs/datadog/datadog.go#L74 - this is really weird default behavior...

@sparrc
Copy link
Contributor

sparrc commented Apr 13, 2016

can you open a separate issue for that?

@jwerak
Copy link

jwerak commented Apr 14, 2016

done #1024

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 a pull request may close this issue.

3 participants