avaje / avaje-metrics Goto Github PK

Without the threshold set all entries are output:

21:15:10  exe:612ms  metric:web.CustomerResource.asBean
   d:0    p:100  ms:612       us:612194       m:web.CustomerResource.asBean
   d:1    p:99   ms:611       us:611976          m:service.MusicLayer.playItSon
   d:2    p:0    ms:0         us:91                 m:service.DummyEmailSender.send
   d:3    p:0    ms:0         us:81                    m:service.DummyEmailSender.yeahNah
   d:2    p:8    ms:51        us:51347              m:service.RadioHead.kidA
   d:3    p:0    ms:1         us:1133                  m:service.Muse.originOfSymmetry
   d:2    p:91   ms:560       us:560506             m:service.RadioHead.theBends
   d:3    p:89   ms:550       us:550383                m:service.RadioHead.pabloHoney
   d:4    p:81   ms:500       us:500221                   m:service.Muse.resistance
   d:5    p:0    ms:0         us:20                          m:service.Muse.notThatResistant
   d:5    p:81   ms:500       us:500153                      m:service.Muse.iDoTheRealWorkAroundHere
   d:5    p:0    ms:0         us:14                          m:service.Muse.notParticularlyResistant

And with a threshold set to 2 percent:

21:41:20  exe:612ms  metric:web.CustomerResource.asBean
   d:0    p:100  ms:612       us:612252       m:web.CustomerResource.asBean
   d:1    p:99   ms:612       us:612050          m:service.MusicLayer.playItSon
   d:2    p:8    ms:51        us:51322              m:service.RadioHead.kidA
   d:2    p:91   ms:560       us:560576             m:service.RadioHead.theBends
   d:3    p:89   ms:550       us:550429                m:service.RadioHead.pabloHoney
   d:4    p:81   ms:500       us:500295                   m:service.Muse.resistance
   d:5    p:81   ms:500       us:500173                      m:service.Muse.iDoTheRealWorkAroundHere

    // configure the MetricReportManager
    val config = MetricReportConfig()

    // output the aggregate metrics every 60 seconds
    config.setFreqInSeconds(60)

    // set request timing threshold to 2 percent (omit entries less than 2 percent)
    config.setRequestTimingThreshold(2)

    reporter = MetricReportManager(config)

Supports the ability to use long values (rather than double) for all built in gauges for better storage options.

Change to:

    writeHeader("collected", reportMetrics.getCollectionTime());
    writeHeader("reported", System.currentTimeMillis());

getTimedMetric() -> timed()
getCounterMetric() -> counter()
getValueMetric() -> value()
getTimedMetricGroup() -> timedGroup()
getMetricNameCache() -> nameCache()

On linux collect the VmRSS and VmHWM via:

grep Vm /proc/<pid>/status

• CounterMetric -> Counter
• TimedMetric -> Timer
• TimedMetricGroup -> TimerGroup
• TimedEvent -> Timer.Event
• ValueMetric -> Meter
• GaugeDoubleMetric -> GaugeDouble
• GaugeLongMetric -> GaugeLong

The issue being that the total memory used by a JVM process is more than the reported heap committed + nonheap committed. So it is good to measure and track the absolute total memory being used.

On linux we can use /proc/$PPID/status and get the VmHWM and VmRSS values.

This enhancement gets those values on linux when available (as gauges like the jvm memory metrics).

Need to have a look at that.

avaje-metrics as a project has been going now for 9 years. Fair to say it is unloved and unknown in the community so the question is should it continue to exist?

Dropwizard Metrics

The original reason avaje-metrics was created was because I didn't believe the benefit of Histogram exceeded its cost and difficulty in aggregating (how do you aggregate a 50th percentile?) WHEN we collect metrics often enough (like every minute) and alternatively can use bucket timer which is a lot less expensive that Histograms. All these things still hold true. I also note that there looks to be some hesitation in maintaining Dropwizard metrics it going forward.

Micrometer

Well the idea they are going for sounds good but micrometer isn't very micro at all - over 600kb and looking at the API and internals I'm not overly convinced by it.

What should avaje-metrics be going forward?

• Java 11 + module-info
• Small at ~80Kb
• Simple Counter, Gauge, Meter, Timer + Bucket timer
• No Histogram
• No EWMA (it's far to laggy if we are reporting every minute)

So that is what I've done and I've been brutal in the sense that I've "modernised" the API, types and modularized it better. Given the tiny number of existing users out there I've been brutal and significantly changed the API without concern for backward compatibility - apologies for that if people are looking to upgrade etc.

Having done the big refactor I'm very happy with the result. A heck of a lot of avaje-metrics was pretty good but I think this refactor gives it a lot more consistency with Dropwizard and Micrometer and I think it's a lot more future orientated. So yes, happy.

In the ValueCounter.getStatistics(reset) in the else block (so when reset==false) it says

return new DefaultValueStatistics(startTime.get(), count.sum(), total.sum(), max.maxThenReset());

Is that intentional (max value reset)?

Generally we want to apply a prefix to application metrics to clearly identify them relative to jvm metrics etc.

Generally we also want to rollup metrics based on prefixes. For example aggregate the metrics with "web.api." prefix to get a measure of total for all Rest/Grpc calls to a given service.

To support this we default to given metrics a prefix of "app." - the default metrics names will then be app.<short class name>.<method name>.

Seeing this on a specific server with a relatively old JDK. Need to investigate.