Skip to content
GitLab
Switch branch/tag
  1. 23 Jul, 2019 4 commits
  3. 22 Jul, 2019 3 commits
  5. 20 Jul, 2019 1 commit
  7. 19 Jul, 2019 2 commits
    • beorn7's avatar
      Add the option to base64-encode label names in push URLs · daa80865
      beorn7 authored 
      

I did quite a lot of research about how to encode `/` in RESTful
request URLs. There doesn't seem to be a general consensus how to do
it (besides just not to do it). I found a few cases where systems
would accept base64 encoding (which has to be the "URL and Filename
safe" variant, otherwise you have `/` in there again, but at least the
existence of this varian it RFC 4648 tells us that it is kind of meant
for what we are doing here). But then the next problem arises: How to
mark what is base64 encoded and what is plain text? In most cases I
saw, the respective field is just marked as being always base64
encoded, which would be sad for our case as there are very few
situations where you actually need base64 encoding. One case used a
marker like `$base64:...`, which I found quite weird. However, I think
using some kind of marker is a good idea. I picked a leading `=` here
as that's a character that is rarely used as a first character of a
label value (and hopefully even less so for the label value in a
grouping key).

I put details in the documentation (see README.md in this commit).

As illustrated there, a nice byproduct is that the encoding of special
characters is a bit saner now (imagine Chinese letters in label
values, which might be pretty common in, well, China).

As base64 encoding is readily available in standard libraries and even
as command line tools (again see examples in the documentation), I
think this is a pretty doable and not overly invasive way of dealing
with the problem.

Client libraries should of course support this encoding transparently.

The competition is mostly going away from the RESTful style and use
URL parameters. If we completely switch to it, we would break
everything hard. If we offered it as an alternative, we would deviate
from our best practice of only offering one way of doing one thing. It
would be a quite invasive change either way.

We could also use a custom escaping scheme just for the case of `/`,
but there is no precedent for that. We would have a solution only used
for the Pushgateway, and everyone had to implement that escaping
scheme on their own. (base64 is a more complex encoding, but the
tooling is readily available everywhere.)
Signed-off-by: default avatarbeorn7 <beorn@grafana.com>
      daa80865
    • beorn7's avatar
      Minor improvements of README.md · a8657e1a
      beorn7 authored 
      
Signed-off-by: default avatarbeorn7 <beorn@grafana.com>
      a8657e1a
  9. 15 Jul, 2019 1 commit
  11. 12 Jul, 2019 1 commit
    • beorn7's avatar
      Also log error messages during gathering · fa351cc1
      beorn7 authored 
      

Quite a few of users have run into the problem that they see a scrape
error in the Prometheus UI but don't see the error. (It's not
displayed in the Prometheus UI, you have to go to the /metrics
endopint yourself to see it.) Logging it makes the problem much more obvious, because all those users looked at what the PGW is logging, which was nothing in that case.
Signed-off-by: default avatarbeorn7 <beorn@grafana.com>
      fa351cc1
  13. 02 Jul, 2019 2 commits
  15. 01 Jul, 2019 2 commits
  17. 29 Jun, 2019 1 commit
  19. 28 Jun, 2019 2 commits
  21. 26 Jun, 2019 3 commits
  23. 25 Jun, 2019 4 commits
  25. 24 Jun, 2019 1 commit
  27. 23 Jun, 2019 2 commits
  29. 17 Jun, 2019 2 commits
  31. 14 Jun, 2019 2 commits
  33. 11 Jun, 2019 1 commit
  35. 08 Jun, 2019 1 commit
  37. 07 Jun, 2019 1 commit
  39. 20 May, 2019 2 commits
  41. 15 May, 2019 2 commits