[
https://issues.apache.org/jira/browse/STORM-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277726#comment-15277726
]
ASF GitHub Bot commented on STORM-433:
--------------------------------------
Github user abhishekagarwal87 commented on the pull request:
https://github.com/apache/storm/pull/1406#issuecomment-218076239
Two parts of this PR -
*Metric collection* - From what I have seen, storm users are very much
interested in queue length statistics. Current queue metrics do not have
histogram or average of queue length etc. There must be a way to add them
without touching the critical path.
*Metric reporting* - Reporting additional metrics to UI adds zookeeper
overhead but additional payload is not significant. Other alternative is to let
users rely on external components such as graphite by using appropriate
MetricConsumer.
> Give users visibility to the depth of queues at each bolt
> ---------------------------------------------------------
>
> Key: STORM-433
> URL: https://issues.apache.org/jira/browse/STORM-433
> Project: Apache Storm
> Issue Type: Wish
> Components: storm-core
> Reporter: Dane Hammer
> Assignee: Kyle Nusbaum
> Priority: Minor
>
> I envision being able to browse the Storm UI and see where queues of tuples
> are backing up.
> Today if I see latencies increasing at a bolt, it may not be due to anything
> specific to that bolt, but that it is backed up behind an overwhelmed bolt
> (which has too low of parallelism or too high of latency).
> I would expect this could use sampling like the metrics reported to the UI
> today, and just retrieve data from netty about the state of the queues. I
> wouldn't imagine supporting zeromq on the first pass.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
