Uploaded image for project: 'Hawkular Metrics'
  1. Hawkular Metrics
  2. HWKMETRICS-218

Handle counter resets

    XMLWordPrintable

    Details

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

      Description

      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

          Attachments

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: