Init winning ticket value redeemed stat on boot

[stronk-dev]

What does this pull request do? Explain your changes. (required)

So before #2888 got merged, the winning ticket metric wasn't working properly. At least, when graphing the metric using livepeer_winning_tickets_recv you could see that it was counting them tickets, but when querying the increase over time (ie using sum by (datacenter)(increase(livepeer_winning_tickets_recv[7d]))) it would be short one or more tickets.

On every restart of the node the prometheus counters and gauges get reset. So using increase is the way to correctly display an increasing counter of tickets across restarts of the node

I am currently seeing the same behaviour with livepeer_value_redeemed

where on the first winning ticket, it counts it as an increase of 0, but then the next ticket gets counted correctly

Here is my theory: when the node boots, not all parameters have their values initialised to 0. It seemd that increase does not count an increase from null -> 1, but it does count an increase from 0 -> 1

This PR initialised the value_redeemed stat to 0 on boot, which should fix the issue i am seeing

How did you test each of these updates (required)
Not yet tested, deploying now...

[codecov]

Codecov Report

Merging #2916 (fb42082) into master (5b69cd6) will decrease coverage by 0.01340%.
Report is 2 commits behind head on master.
The diff coverage is 100.00000%.

Additional details and impacted files

@@                 Coverage Diff                 @@
##              master       #2916         +/-   ##
===================================================
- Coverage   56.54162%   56.52822%   -0.01340%     
===================================================
  Files             89          89                 
  Lines          19460       19454          -6     
===================================================
- Hits           11003       10997          -6     
  Misses          7849        7849                 
  Partials         608         608                 

Files	Coverage Δ
common/readfromfile.go	85.00000% <100.00000%> (-3.88889%)	⬇️
monitor/census.go	63.33596% <100.00000%> (+0.02887%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fdda451...fb42082. Read the comment docs.

Files	Coverage Δ
common/readfromfile.go	85.00000% <100.00000%> (-3.88889%)	⬇️
monitor/census.go	63.33596% <100.00000%> (+0.02887%)	⬆️

[rickstaa]

This will fix #2917.

[FranckUltima]

Thank you! So happy to see this point finally resolved! I don’t know how long I spent on Grafana trying to find the query that would give me the exact number of winning tickets, even after a server restart, without ever succeeding.

[stronk-dev]

Thank you! So happy to see this point finally resolved! I don’t know how long I spent on Grafana trying to find the query that would give me the exact number of winning tickets, even after a server restart, without ever succeeding.

Lol I know how you feel, when @papabear99 PR was merged it fixed the livepeer_winning_tickets_recv as an unintended side effect, so just applying the same logic to livepeer_value_redeemed now. we can finally accurately track work performed vs payouts redeemed

[thomshutt]

Looks good, thanks @stronk-dev!