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

Prefix (and suffix?) should probably enforce separator presence #215

Open
sambostock opened this issue Oct 20, 2021 · 3 comments
Open

Prefix (and suffix?) should probably enforce separator presence #215

sambostock opened this issue Oct 20, 2021 · 3 comments

Comments

@sambostock
Copy link
Contributor

TL;DR

We should enforce that metric prefixes end in a period, or insert it automatically.

Reasoning

Consider the following metric:

request.time

It is common to want to add a prefix to the metric to identify the application emitting it.

In many other StatsD libraries, specifying a non-empty prefix (e.g. my_app) results in the following:

my_app.request.time

A period (.) is automatically added to delimit the metric name from the prefix, unless it is empty.

However, this library produces the following:

-my_app.request.time
+my_apprequest.time

To get this behaviour with hot-shots, one must specify the separator as part of the prefix: my_app.. This is error prone, especially as it does not appear to be documented.

I am not aware of scenarios in which one would want a prefix to be joined to the metric name without a separator, though perhaps they exist.

If there are no such use cases, I think it would be sensible to either

  • require the last character of a non-empty prefix to be a period, or
  • automatically add a period in between the prefix and metric name if one is not already present.

This may also apply to metric suffixes, although of course the first character would be considered instead of the last.

@tlhunter
Copy link

hot-shots should absolutely insert the period when missing. I get bit by this with every new project ;)

@bdeitte
Copy link
Collaborator

bdeitte commented Jun 20, 2022

I'm totally good with a PR for this if anybody wants to create one. This will require a major version update, just in case it would break someone, but that does seem like something that just trips everyone up and is never needed.

@bdeitte
Copy link
Collaborator

bdeitte commented Jun 20, 2022

And apologies (as I keep saying as I get through old issues here) on the delay on this.

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

No branches or pull requests

3 participants