Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/2714
We have 4 separate metrics APIs right now
2 for daemons
https://github.com/apache/storm/blob/master/storm-server/src/main/java/org/apache/storm/metric/api/IClusterMetricsConsumer.java
https://github.com/apache/storm/blob/master/storm-server/src/main/java/org/apache/storm/metric/StormMetricsRegistry.java
and similarly 2 for the workers.
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/metric/api/IMetricsConsumer.java
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/metrics2/StormMetricRegistry.java
IClusterMetricsConsumer and IMetricsConsumer are way too open so we
deprecated them, or should do so. They allowed you to send anything
(literately an Object) but they had a lot of context about the metrics, a.k.a.
dimensions, which process it came from, what component, etc. The new APIs fix
the Object issue, because they are based off of the dropwizard/yammer/codahale
API, but it does not support dimensions.
The Flink APIs appears to more or less fix the dimensions issue, but it is
a fork of codahale/yammer.
https://github.com/apache/flink/blob/16ec3d7ea12c520c5c86f0721553355cc938c2ae/flink-metrics/flink-metrics-core/pom.xml
They have no external dependencies.
So are you proposing that we fork just like flink does? do you want us to
use the flink-metrics-core instead as a backend? Either of these choices will
require that we have at a minimum a new API for reporting metrics to other
systems, and possibly a 3rd API for registering metrics. This is not a small
amount of work, and it is possibly going to be painful to our users, who may
have spent some time trying to move to the new APIs. I am not opposed to it,
as it will solve some problems and ugliness that we currently have, I just want
to be sure that we understand the ramifications of a move like this.
On the plus side it would make it so we could have a single API for all
metrics.
---
