Reset collected metrics after exporting about go-metrics HOT 5 CLOSED

Hey there! Counters are monotonically increasing, unless reset. Timers use a histogram with a decay function under the hood, so you can think of it as a moving window - the output will be biased towards the most recent samples, with older samples dropping out of the picture entirely over time. You can see the NewTimer constructor to see the defaults and follow the thread from there to see what else is possible.

Hope this helps!

from go-metrics.

Sorry, I didn't answer your question directly. You can see that the other variable the Timer depends on is a meter - that actually uses an exponentially weighted moving average ("EWMA") to achieve the same end. Your use case will work just fine, as the values provided by the Timer will reflect the most recent datapoints. You can plug in a different implementations of Histogram and Meter, and there are a few options and tuning knobs available for both.

We've been using the defaults in production at Opsmatic and they work just fine. Similar techniques used to calculate things like load in Linux and various timing metrics in services such as Apache.

from go-metrics.

Thanks for your answer @mihasya - things are more clear now, I will try to experiment with timers, the thing I already noticed - if new time interval did not introduce new timer events - exported timer values remain the same:

package main

import (
    "github.com/rcrowley/go-metrics"
    "log"
    "os"
    "time"
)

const fanout = 10
const limit = 10

func main() {

    r := metrics.NewRegistry()

    t := metrics.NewTimer()
    r.Register("hooah", t)
    for i := 0; i < fanout; i++ {
        go func() {
            j := 0
            for {
                if j < limit {
                    t.Time(func() { time.Sleep(300e6) })
                } else {
                    break
                    //t.Time(func() { time.Sleep(1e6) })
                    //time.Sleep(299e6)
                }
                j++
            }
        }()
        go func() {
            k := 0
            for {
                if k < limit {
                    t.Time(func() { time.Sleep(400e6) })
                } else {
                    break
                    //t.Time(func() { time.Sleep(2e6) })
                    //time.Sleep(398e6)
                }
                k++
            }
        }()
    }

    metrics.Log(r, 1e9, log.New(os.Stderr, "metrics: ", log.Lmicroseconds))
}

Also timer max value not updated at all when new timer events are much faster (uncomment 4 lines in example above and remove break statements).

from go-metrics.

@FZambia these metrics are aggregates, so it makes sense that they don't move with every single data point. Think about what "max" is supposed to mean - it's the highest value seen, right? Of course, in webops "absolute" values "since last restart" are not very useful, which is why capped samples are employed. Follow the code from here to here and here - you will see that the Sample being used uses a "reservoir" of 1028 data points. I simply don't think you're pushing in enough data points to cause the previous "max" value to be pushed out of the "reservoir."

If you look at the comment above NewTimer, you'll see the defaults were pulled from Unix load averages - those are updated quite frequently.

Hope this helps. I'm closing this issue as I start the trek to "inbox 0" on this repo. Cheers.

from go-metrics.

Thanks a lot, this information will definitely help. I did not mean that this behaviour is somewhat buggy - just wanted to understand how to adapt it to my needs, now I see that I have not noticed lots of internal stuff.

from go-metrics.