Closed vovayartsev closed 2 years ago
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.
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:In the example below, a had to add
tags: [:env]
to all my metrics explicitly:I'd really benefit from a truly global/implicit
env
tag. And if I wanted more fine-grained control - I'd just use thetag_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!