[
https://issues.apache.org/jira/browse/STORM-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200252#comment-14200252
]
ASF GitHub Bot commented on STORM-533:
--------------------------------------
Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/302#issuecomment-61989690
The metrics system is very generic, and not that complex. Essentially it
sets up a timer that will periodically call getValueAndReset on an instance of
IMetric. These values can be anything and are sent to an instance of
IMetricsConsumer that is residing in a bolt. It is up to the IMetricsConsumer
to decide what to do with Object the the IMetric created.
I agree that having an API closer to codahale would be good, but that is a
much bigger change. I would like to see that in a separate JIRA/pull request.
The big difference between the two approaches is that the storm metrics
associate the value with an individual bolt or spout instance. codahale and
most other metrics systems I have seen, associate the metrics with an arbitrary
name. We would need a way to bridge that gap in a clean/efficient way. I
would also like to see a lot of metrics added into the daemon processes.
Nimbus, Supervisor, and DRPC all need good monitoring.
> Add metrics collection for IConnection
> --------------------------------------
>
> Key: STORM-533
> URL: https://issues.apache.org/jira/browse/STORM-533
> Project: Apache Storm
> Issue Type: Improvement
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
>
> It would really be great to get some metrics from an IConnection that are
> then sent to the metrics consumer.
> We have seen issues in the past where a fire wall rule is mis-configured and
> one host is unable to talk to another host. If we had some metrics about how
> many reconnection attempts are being made by the client to a given host we
> could easily diagnose this.
> There are other metrics that would be nice to know too, like how many
> bytes/tuples are being sent between different hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
