[
https://issues.apache.org/jira/browse/STORM-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278883#comment-15278883
]
ASF GitHub Bot commented on STORM-433:
--------------------------------------
Github user knusbaum commented on the pull request:
https://github.com/apache/storm/pull/1406#issuecomment-218289768
I think it's fine if this goes in. It doesn't add much to the metrics load,
and we already have a working solution for clusters whose zk instances get
overloaded. Ultimately, we do want to move all the metrics somewhere else, but
until then, we can continue doing them as we have been.
When we make the larger change, it won't me more difficult because of this
than it would have been.
> 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)
