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

Standardize tag syntax #619

Open
mcandre opened this issue Mar 29, 2017 · 5 comments
Open

Standardize tag syntax #619

mcandre opened this issue Mar 29, 2017 · 5 comments
Labels
feature A new feature, or a feature request

Comments

@mcandre
Copy link

mcandre commented Mar 29, 2017

InfluxDB and Datadog both extended the statsd format to include tags, but each did so with their own special separator syntax (comma , vs. colon :).

Could the official statsd fork come back to live and promote a standard tagging syntax?

@wooparadog
Copy link

+1

Since graphite now supports tags(http://graphite.readthedocs.io/en/latest/tags.html), it is quite the time to do so.

@cobbr2
Copy link

cobbr2 commented Jul 25, 2019

Note SignalFX picked yet a different syntax including both brackets and commas. "Jane, stop this crazy thing!"

@BlueHatbRit
Copy link
Member

Hey thanks for bumping this, the project is sort of back to life now (mostly just me). I'd be keen to explore this, but one of the good things about statsd is that the bucket names are very flexible and can be used in a myriad of ways. If someone has an idea of a proposal with some reasons as to why we might choose to push a standard, I'd be up for discussing it.

A PR of a markdown document into /docs would be a good way to go, or submitting it to this issue.

@yifeikong
Copy link

Any updates on this?

@BlueHatbRit
Copy link
Member

@yifeikong as I mentioned in my previous comment, if someone wants to put together a proposal I'd be happy to review and add my thoughts. Until that happens, I don't see much progress being made here. Right now I don't have any specific feelings a direction we standardise with, and if we did choose to do so we'd be looking at a potentially breaking change which isn't ideal.

As mentioned previously, if someone has ideas they'd like to share then a PR with a draft document would be a great place to start.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new feature, or a feature request
Projects
None yet
Development

No branches or pull requests

5 participants