Closed stanlemon closed 6 years ago
Offline discussion has me leaning toward a second metrics implementation and keeping the deprecated one around in the interim. This won't resolve the deprecation notices though. 😿 I will probably mark StormRecorder
as @Deprecated
then too.
This is resolved with #119.
Storm 1.1 and lower offered a method on
TopologyContext
calledregisterMetrics()
(see https://github.com/apache/storm/blob/1.1.x-branch/storm-core/src/jvm/org/apache/storm/task/TopologyContext.java). In Storm 1.2 these methods were deprecated andregisterTimer()
,registerHistogram()
,registerMeter()
,registerCounter()
andregisterGauge()
were added (see https://github.com/apache/storm/blob/v1.2.2/storm-core/src/jvm/org/apache/storm/task/TopologyContext.java#L396-L418). Within this library we represent several metric types via theMetricsRecorder
interface, specificallycountBy()
,assignValue()
andrecordTimer()
along with a set of helpers for each. Our current metrics methods map to three of these, but we have gaps for meters (measures mean throughput and one-, five-, and fifteen-minute exponentially-weighted moving average throughputs) and histograms (calculates the distribution of a value).In the short term (0.10) we can swap
StormRecorder
(the implementation ofMetricsRecorder
that leveragesTopologyContext
to callregisterMetrics()
to use these new methods. This does then impose a hard requirement on Storm 1.2 because the new metrics methods did not exist before that release. Currently 0.10 requires 1.2, but it should function fine with older version - this would not be the case with a metrics change. Longer term do we need to consider exposing the other two metrics methods? As it stands today we don't have a use case currently, but we do pass theMetricsRecorder
instance downstream to many classes that can be overridden through third party extension.