weaveworks
append labels server side by incoming query param
This feature is useful for mobile clients.
This allows us to provide an endpoint via configuration containing specific labels we want to have appended on metrics sent from the client.
It also makes client code less bloated, as they don't have to provide client_version etc everywhere they use a Counter. It could also be other relevant metrics such as client participating in a experiment.
Fixed my commits to be signed. Forgot to update a few settings after migrating to yubikey5.
We have some more code that is work in progress, need a few more changes so we can easily just depend on this as a module and override and make our own main().
This is ready for being reviewed, this allowed us to reuse your code while replacing main() with our own http server setup using api signing etc.
Hi, thanks for the PR, and sorry it languished for a bit.
It's quite big (at least superficially) so may take a while longer to figure out what changed. I wonder why git doesn't spot the file is mostly the same in the first commit and show it as a rename.
@bboreham : git diff -M -C master serversidelabels --summary might be helpful? Probably because file is copied and main then modified to remove what is put inside aggate.go. This one should clear up the "huge" copy for you: git show bbd18c6b8336425b73f9eb9bc1768ab8729e154d -M -C
https://www.reddit.com/r/git/comments/1oi0tw/is_there_any_way_have_git_diff_show_that_a_file/ccsfh1d/
@bboreham : > Would it be simpler just to add query parameters ?foo=bar as labels?
Sadly this would include other query parameters we need to send to the service for doing API signing which we have added internally for our http router.
Hence they are sent as request parameter (which is configurable) which is read as an array according to the http spec for query arguments.
Not sure how I would add filtering on my side in additional if you wanted to create prometheus labels based from any query parameter and its value. (as I would then need to filter a few query parameters that shouldn't be prometheus labels).
I guess I could split up into two PRs, but however I do think that https://github.com/weaveworks/prom-aggregation-gateway/pull/31#pullrequestreview-354495847 needs to be fixed first before I rebase and split the PR.
I notice the Prometheus Pushgateway has a similar feature, but the labels form part of the http path - see https://github.com/prometheus/pushgateway#url . Would that work for you? It would be great to make the projects more compatible.