Store sum of events for different metrics

[hierynomus]

This is a rework of PR #1022 by @hashbrowncipher (and fixes @slovdahl's issue #712). This PR is based on the 4.0-development branch, which has evolved further than master.

The main differences are:

• Introduction of a new Summing interface, which is implemented by Meter, Timer and Histogram
• Reporting of the Summing.sum() is done as a long to avoid loss of precision on high values due to floating point properties
• All reporters report the sum() property of the relevant metrics

The main purpose of storing the sum is to facilitate monitoring systems that use raw ascending counters (e.g. Prometheus), and time-series databases such as InfluxDB (see also @mevdschee comment)

[vladimir-bukhtoyarov]

Long datatype is not enough long to store sum in common case. For example when using the Long for timer you are able to store only 192 year of accumulated latency then overflow will happen

[storozhukBM]

@vladimir-bukhtoyarov any suggestions for suitable sum storage type?

[mevdschee]

192 year of accumulated latency then overflow will happen

I'm not sure I see the issue. You need to run with many cores on a very popular task to have this duration exceed 192 years. And even if this happens, would it cause a problem? When using monotonous increasing counters you will miss just a single measurement.

[vladimir-bukhtoyarov]

When using monotonous increasing counters you will miss just a single measurement.

Keep in mind that you are unable to achive even monotonous increasing semantic on arithmetic overflow when using LongAdder. Because LongAdder splits it state to many chunks, and arithmetic overflow can happen in one chunk, simultneously on many chunks, in sum, and due to dynamic chunk count inside LongAdder the results is totally unpredictable when overflow happen.

[vladimir-bukhtoyarov]

@vladimir-bukhtoyarov any suggestions for suitable sum storage type?

I argue that this kind of functionality is not needed at core level. The problem can be easy solved by decorators. Anyone who firstly wants to have sum, secondly understands the risks related to overflow, can easily decorate any timer or histogram and implement sum reporting as separated gauge.

Of course it is possible to replace LongAdder by DoubleAdder to pospone the overflow, but accuracy of sum will be significantly decreased.

[storozhukBM]

I argue that this kind of functionality is not needed at core level.

OK, now it's clear.
Personally I'm totally agree with your thoughts. Core library is actually flexible enough and you can easily extend Histogram class within your project to add required functionality.

[mevdschee]

the results is totally unpredictable when overflow happen.

True, but can't we still say we miss one measurement on average per 192 year of duration data?