1. 21 Sep, 2021 1 commit
  2. 15 Sep, 2021 2 commits
  3. 12 Jul, 2021 2 commits
  4. 06 May, 2021 2 commits
  5. 01 Apr, 2021 1 commit
    • Cole White's avatar
      Bugfix: clone labels when interpolating metric name (#235) · 033cfc9e
      Cole White authored
      When the log metrics output is first in line,
      `metrics.utils.formatLabels` will mutate the labels array.
      This mutation will leak to the other metrics clients and manifest
      as an Invalid number of arguments in prom-client.
      
      Bump to 2.8.2
      
      Bug: T278141
      033cfc9e
  6. 10 Dec, 2020 3 commits
  7. 17 Nov, 2020 8 commits
  8. 15 Jun, 2020 1 commit
  9. 08 Apr, 2020 2 commits
    • Ppchelko's avatar
      421d2f1b
    • Alexandros Kosiaris's avatar
      Add support for having named logging levels · d3fc15b9
      Alexandros Kosiaris authored
      Why:
      service-runner, when logging to stdout delegates to bunyan stdout
      logging process that ends up creating log entries with level specified
      as an integer, even though the code everywhere might be using named
      levels. This hasn't been a problem up to now because we sparringly
      relied on that, but with the move to service-runner apps on kubernetes
      and the logging pipeline this is starting to cause issues, namely
      https://phabricator.wikimedia.org/T239459. It would be nice if
      service-runner allowed to log to stdout named loglevels
      
      What:
      Add a simple, albeit probably inefficient function due to all the JSON
      encoding/decoding that wraps process.stdout and changes the level
      attribute from an integer to a string. Provide it as an additional
      stream.
      
      The output looks like this:
      
      {"name":"myapp","hostname":"buster","pid":5835,"level":"INFO","msg":"This is logging","time":"2020-04-08T09:03:09.294Z","v":0}
      
      instead of:
      
      {"name":"myapp","hostname":"buster","pid":5835,"level":30,"msg":"This is logging","time":"2020-04-08T09:03:09.294Z","v":0}
      
      Bump service-runner version to reflect the change
      
      Bug: T239459
      d3fc15b9
  10. 12 Feb, 2020 2 commits
  11. 11 Feb, 2020 3 commits
  12. 02 Jan, 2020 1 commit
  13. 01 Aug, 2019 1 commit
  14. 24 Jun, 2019 1 commit
  15. 12 Jun, 2019 1 commit
  16. 10 Jun, 2019 1 commit
  17. 07 Jun, 2019 1 commit
    • Alexandros Kosiaris's avatar
      Replace invalid IPs in README.md · 368e391a
      Alexandros Kosiaris authored
      Even if just a documentation example, using invalid IPs is not legitimate
      especially given there are RFCs with example IPs for this: Switch to
      192.0.2.0/24 (aka TEST-NET-1) per  RFC 5737
      368e391a
  18. 28 May, 2019 1 commit
  19. 24 May, 2019 3 commits
  20. 23 May, 2019 1 commit
  21. 20 May, 2019 1 commit
  22. 17 May, 2019 1 commit