Extend LATENCY LATEST to add min / sum / cnt stats

[enjoy-binbin]

Currently LATENCY LATEST only has the following fields:

• Event name.
• Unix timestamp of the latest latency spike for the event.
• Latest event latency in millisecond.
• All-time maximum latency for this event.

This PR introduced these fields:

• min: the all-time minimum latency for this event (maybe not that useful)
• sum: the all-time sum latency for this event (i think it is useful for some events)
• cnt: the event count that trigger the latency, with the sum we can calc the avg

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.98%. Comparing base (cda9eee) to head (2df98be).
Report is 9 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1570      +/-   ##
============================================
+ Coverage     70.96%   70.98%   +0.02%     
============================================
  Files           120      120              
  Lines         65094    65103       +9     
============================================
+ Hits          46191    46211      +20     
+ Misses        18903    18892      -11     

Files with missing lines	Coverage Δ
src/latency.c	81.36% <100.00%> (+0.43%)	⬆️

... and 10 files with indirect coverage changes

[zuiderkwast]

OK, I think we can add this.

We are adding these in the end of an array reply. I remember we did something like that in CLUSTER SLOTS and we said it is a backward-compatible change, but still it broke some clients. For example, hiredis-cluster was checking the exact array length in the handling of CLUSTER SLOTS.

LATENCY LATEST is not as risky to change as CLUSTER SLOTS, but we should still be aware that some monitoring tools maybe can break. We should mention it in the release notes and we should add some note in the documentation that new fields can be added. A note like that makes it more clear that adding more fields in the reply is a backward compatible change. Now we don't have a note like that on https://valkey.io/commands/latency-latest/.

[zuiderkwast]

@valkey-io/core-team Please vote to extend the multi-bulk reply with three more numbers.

[madolson]

I vote to remove min. It's basically the lowest value above min, I think sum and cnt are more useful.

[zuiderkwast]

I guess you mean min is the lowest value above the configured latency-monitor-threshold.

[enjoy-binbin]

Will it be useful in scenarios where latency-monitor-threshold may be frequently adjusted? or the real latency is much larger than latency-monitor-threshold?

i am not sure about it actually, i am ok with removing it if you both think it is useless.

[zuiderkwast]

Only Madelyn thinks it's useless. I don't have an opinion about it. 😆

[madolson]

I'm pretty strongly opinionated about only adding fields we are sure are useful. If we aren't sure something is useful, I would prefer to defer adding it until someone brings it up or has a use case. I prefer to lean towards simplicity as much as possible. The fewer the fields exist, the less the end users have to think about.

Will it be useful in scenarios where latency-monitor-threshold may be frequently adjusted? or the real latency is much larger than latency-monitor-threshold?

I'm not sure what the min would tell you in that scenario.