One of the challenges with implementing counters is handling resets which would happen with a server restart for example. Let's consider some sample data to see how we will deal with this.

Time | Reported Count | Total Count | Rate (each T delta is 1 for simplicity) |
---|---|---|---|

T _{0} |
10 | 10 | N/A |

T _{1} |
20 | 20 | 10 |

T _{2} |
30 | 30 | 10 |

T _{3} |
5 | 35 | 5 |

T _{4} |
15 | 45 | 10 |

T _{5} |
25 | 55 | 10 |

The reported count is the value that gets persisted at each T _{n}. There is a reset at T _{3}. We know this because the total count is less than the value at T _{2}. The count reported at T _{4} is 15, which is the total since the reset. The total count (since T _{0}) at T _{4} is actually 45. We calculate the total count after the reset at time T _{n} by adding the value to the last total count known before the reset, which in this case is 30.

We need to keep track of the last reset value so that we can still calculate rates efficiently in the event of resets. One possibility is to store it in metrics_idx either as a new column or as a tag. This could work since `GenerateRate`, the rate calculation job, queries metrics_idx for counter metrics.