[
https://issues.apache.org/jira/browse/STORM-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276050#comment-15276050
]
ASF GitHub Bot commented on STORM-433:
--------------------------------------
Github user HeartSaVioR commented on the pull request:
https://github.com/apache/storm/pull/1406#issuecomment-217794597
For addressing big picture of metrics improvement, yes we want to address
four major points.
But given that we already released major version of Storm 1.0.0, we would
want to keep backward compatibility for 1.x. That's why I'm addressing small
improvements first instead of working long-term huge improvements. It's also
planned to phase 2 on JStorm merger in 2.0.0.
But if we have many ideas which relies on that improvements, I think we can
discuss how to address and work on that right now. (evaluation of many ways
including porting metrics feature of JStorm)
Btw, since we're having alternative (Pacemaker) now, we may feel OK to add
small amount of payload to heartbeat message.
If it doesn't make sense, even we can separate heartbeat message and
metrics message, and set frequency of latter thing to 10s or even longer, I
guess we can reduce ZK write load greatly. (since it aggregates built-in
topology metrics and writes to ZK every 3 seconds by default.)
> 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)
