1. 22 Jul, 2019 1 commit
  2. 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
  3. 04 Dec, 2018 2 commits
  4. 18 Oct, 2018 1 commit
  5. 02 Oct, 2018 1 commit
  6. 14 Sep, 2018 2 commits
  7. 27 Aug, 2018 1 commit
  8. 04 May, 2018 1 commit
  9. 28 Apr, 2018 1 commit
  10. 17 Apr, 2018 1 commit
  11. 06 Apr, 2018 2 commits
  12. 04 Apr, 2018 2 commits
  13. 14 Aug, 2017 1 commit
  14. 10 Aug, 2017 1 commit
  15. 06 Jun, 2017 1 commit
  16. 24 May, 2017 1 commit
    • Brian Brazil's avatar
      Reject pushes with timestamps. · c1dd033d
      Brian Brazil authored
      Fixes #109
      
      I once thought that some day we'd solve staleness, and there
      would be valid use cases for the pushgateway to expose timestamps.
      With the recent work on staleness this has turned out not to be the case.
      As every single person we have seen pushing timestamps to the pgw
      has been doing so incorrectly (usually misguidedly trying to make
      Prometheus do push), let's send a stronger signal that this is not the
      right way to do things.
      
      With this in place I think we'll have all the mitigation we're going to
      get in terms of discourage users from misusing timestamps, and it'll be
      tolerable to add timestamp support to client libraries for the very very
      few use cases that need this advanced feature (at current count:
      collectd, cloudwatch, graphite and inflxudb exporters).
      
      This should in principle have no impact as a) there is no documentation
      saying that this is a good idea or even an idea and b) there is no code
      support in our libraries for pushing timestamps.
      c1dd033d
  17. 11 Apr, 2017 1 commit
  18. 17 Jan, 2017 1 commit
    • Muhamed's avatar
      Update README.md · 51be83ca
      Muhamed authored
      Add an info about detail state if '-persistence.file' flag is not provided.
      51be83ca
  19. 05 Sep, 2016 1 commit
    • beorn7's avatar
      Improve README.md · d1039a2a
      beorn7 authored
      This addresses three issues:
      
      - Mention binary releases.
      - Make even clearer that the PGW is not an aggregator. Fixes #87.
      - Make clear that the PGW is not an event store. Fixes #89.
      d1039a2a
  20. 29 Jul, 2016 1 commit
    • beorn7's avatar
      Update README.md · 6b99e101
      beorn7 authored
      I found outdated parts in the instance-label section while working on
      client_golang.
      6b99e101
  21. 10 May, 2016 1 commit
  22. 04 Dec, 2015 2 commits
  23. 16 Oct, 2015 1 commit
  24. 11 Jul, 2015 1 commit
  25. 01 Jul, 2015 1 commit
  26. 10 Jun, 2015 1 commit
  27. 09 Jun, 2015 1 commit
  28. 08 Jun, 2015 1 commit
  29. 10 Feb, 2015 1 commit
  30. 19 Jun, 2014 1 commit
  31. 20 May, 2014 3 commits
  32. 13 May, 2014 1 commit