Enhance available threshold values for Rate
, Gauge
and Trend
metrics
#1312
Labels
cloud
enhancement
evaluation needed
proposal needs to be validated or tested before fully implementing it in k6
A k6
Rate
metric, either custom or predefined (e.g.checks
), consists of just 2 counters,Trues
andTotal
, and therate
we expose to be used in threshold definitions is just the first counter divided by the second. This is all well and good, however, there are valid use cases for also being able to access (and define thresholds based on) the underlying counters as well. Even the derived value ofTotal-Trues
(i.e.falses
orfailures
or whatever we decide to call it) might be useful in a lot of use cases...For example, say that you want to track failed HTTP requests (#1311), it might make sense to want to be notified if either the HTTP failure rate exceeds 1%, or if we have more than 500 failed requests. You don't really know the precise number of requests your script is going to make, but either of these conditions may seem worth investigating, so you'd want your CI to fail it they happen or something like that. Of course, you can even now, but it's going to needlessly require an additional custom
Counter
, which is both poor UX, and more inefficient to compute...Implementation-wise, this should be very easy to add to k6, even with the current somewhat ad-hoc threshold implementation (#961). We just need to synchronize with the cloud execution, so it's supported there as well. It will also likely be even more useful when we have sliding windows for thresholds (#1136)...
The text was updated successfully, but these errors were encountered: