prom: Add option to specify metrics prefix #782
Conversation
It's useful to be able to prefix the metrics that are being reported so as to more easily differentiate them from other applications that are using the same metrics. This change adds the necessary bits (environment var, config file, command line) to support capturing the prefix and passing it through to the httpmetrics library.
|
@mostynb can you take a look at this? |
|
How disruptive would it be to just hard-code a "bazel_remote" prefix, and skip the configuration setting? And would that be sufficient, if we ignore the distruption for a moment? |
|
For folks that have dashboards and such depending on this it'd probably be fairly disruptive. If the prefix is empty it shows up as it does today which reduces disruption. |
|
OK, this sounds reasonable. I just have a couple of questions about the flag... Is there a recommended value? Would "bazel_remote_" work for anyone who might want to use this setting? If so we could use a boolean flag and if there's ever a bazel-remove v3 we could switch to this behaviour and remove the flag. |
|
That is a possible option - I was mostly trying to give maximum flexibility. Any particular reason for preferring that? |
|
I would like to limit the number of unnecessary configuration settings, because the number of settings is growing more than I would like. If we were to remove some configuration settings in a major version upgrade in the future, then the fewer broken configurations the better, since the migration path for users would be simpler. So if there is no plausible need to specify a custom prefix there, let's not add one. On the other hand, if you can think of a reason why we would need this configurability then that would change things a bit. |
|
Naw. That seems totally reasonable. My initial instinct was that may folks want to prefix this per instance, but after some thought I concluded that probably per application is fine. |
We need to prefix by application name, not instance name. This provides a flag that doesn't allow for undue customization.
|
Thanks- I squashed this and landed it on the master branch. |
It's useful to be able to prefix the metrics that are being reported so as to more easily differentiate them from other applications that are using the same metrics.
This change adds the necessary bits (environment var, config file, command line) to support capturing the prefix and passing it through to the httpmetrics library.