• Type: Enhancement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 0.8.0
    • Component/s: Core
    • Labels:


      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.

        Gliffy Diagrams




              • Assignee:
                john.sanda John Sanda
                john.sanda John Sanda
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: