1. 23 Jul, 2019 4 commits
  2. 22 Jul, 2019 3 commits
  3. 20 Jul, 2019 1 commit
  4. 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
  5. 15 Jul, 2019 1 commit
  6. 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
  7. 02 Jul, 2019 2 commits
  8. 01 Jul, 2019 2 commits
  9. 29 Jun, 2019 1 commit
  10. 28 Jun, 2019 2 commits
  11. 26 Jun, 2019 3 commits
  12. 25 Jun, 2019 4 commits
  13. 24 Jun, 2019 1 commit
  14. 23 Jun, 2019 2 commits
  15. 17 Jun, 2019 2 commits
  16. 14 Jun, 2019 2 commits
  17. 11 Jun, 2019 1 commit
  18. 08 Jun, 2019 1 commit
  19. 07 Jun, 2019 1 commit
  20. 20 May, 2019 2 commits
  21. 15 May, 2019 2 commits