global_tags hard to use

[Vladimir Yartsev]

Hi! 👋 Not an issue at all but rather a piece of positive feedback and an improvement proposal.
Integration went really smoothly for me and everything worked out of the box.

However, this statement from the docs about global_tags caused problems:

Note that if the global tag is to be sent with the metric, the metric needs to have it listed under the :tags option, just like any other tag.

In the example below, a had to add tags: [:env]to all my metrics explicitly:

TelemetryMetricsStatsd.start_link(
  metrics: [
    counter("http.request.count", tags: [:env])
    counter("myapp.foo.count", tags: [:env])
    counter("myapp.bar.count", tags: [:env])
    ... and many more repetitions of tags: [:env] ...
  ],
  global_tags: [env: "prod"]
)

I'd really benefit from a truly global/implicit env tag.
And if I wanted more fine-grained control - I'd just use the tag_values function instead.

Curious if there's a reason behind the current design, and if it's just me who asks for a more transparent "global" behavior. 😃

Cheers!

[Arek Gil]

Hey @vovayartsev 👋 That's a very good question!

The reason is that the order of the tags specified for each metric defines the order in which they appear when the metric update is formatted using the standard formatter. For example, for metric counter("http.request.count", tags: [:env, :route]) and event metadata %{env: "prod", route: "/app"}, the reporter will send http.request.count.prod./app:1:c.

If the :global_tags are specified, the reporter wouldn't know where to add them, and that's why it's required to list the tag key for each metric.

Sadly, I haven't come up with an idea how to solve this problem. I really wish we didn't need to require to list the global tag for each metric.