[
https://issues.apache.org/jira/browse/STORM-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110829#comment-14110829
]
ASF GitHub Bot commented on STORM-433:
--------------------------------------
Github user knusbaum commented on a diff in the pull request:
https://github.com/apache/incubator-storm/pull/236#discussion_r16720699
--- Diff: storm-core/src/ui/public/templates/component-page-template.html
---
@@ -133,11 +133,11 @@
</script>
<script id="bolt-executor-template" type="text/html">
<h2>Executors</h2>
-<table class="zebra-striped" id="bolt-executor-table"><thead><tr><th
class="header headerSortDown"><span class="tip right" title="The unique
executor ID.">Id</span></th><th class="header"><span data-original-title="The
length of time an Executor (thread) has been alive." class="tip
right">Uptime</span></th><th class="header"><span class="tip above" title="The
hostname reported by the remote host. (Note that this hostname is not the
result of a reverse lookup at the Nimbus node.)">Host</span></th><th
class="header"><span class="tip above" title="The port number used by the
Worker to which an Executor is assigned. Click on the port number to open the
logviewer page for this Worker.">Port</span></th><th class="header"><span
class="tip above" title="The number of Tuples emitted.">Emitted</span></th><th
class="header"><span class="tip above" title="The number of Tuples emitted that
sent to one or more bolts.">Transferred</span></th><th class="header"><span
class="tip above" title="If this is around 1.0, the corresponding Bolt is
running as fast as it can, so you may want to increase the Bolt's parallelism.
This is (number executed * average execute latency) / measurement
time.">Capacity (last 10m)</span></th><th class="header"><span
data-original-title="The average time a Tuple spends in the execute method. The
execute method may complete without sending an Ack for the tuple." class="tip
above">Execute latency (ms)</span></th><th class="header"><span class="tip
above" title="The number of incoming Tuples processed.">Executed</span></th><th
class="header"><span data-original-title="The average time it takes to Ack a
Tuple after it is first received. Bolts that join, aggregate or batch may not
Ack a tuple until a number of other Tuples have been received." class="tip
above">Process latency (ms)</span></th><th class="header"><span
data-original-title="The number of Tuples acknowledged by this Bolt."
class="tip above">Acked</span></th><th class="header"><span
data-original-title="The number of tuples Failed by this Bolt." class="tip
left">Failed</span></th></tr></thead>
+<table class="zebra-striped" id="bolt-executor-table"><thead><tr><th
class="header headerSortDown"><span class="tip right" title="The unique
executor ID.">Id</span></th><th class="header"><span data-original-title="The
length of time an Executor (thread) has been alive." class="tip
right">Uptime</span></th><th class="header"><span class="tip above" title="The
hostname reported by the remote host. (Note that this hostname is not the
result of a reverse lookup at the Nimbus node.)">Host</span></th><th
class="header"><span class="tip above" title="The port number used by the
Worker to which an Executor is assigned. Click on the port number to open the
logviewer page for this Worker.">Port</span></th><th class="header"><span
class="tip above" title="The number of Tuples emitted.">Emitted</span></th><th
class="header"><span class="tip above" title="The number of Tuples emitted that
sent to one or more bolts.">Transferred</span></th><th class="header"><span
class="tip above" title="If this is around 1.0, the corresponding Bolt is
running as fast as it can, so you may want to increase the Bolt's parallelism.
This is (number executed * average execute latency) / measurement
time.">Capacity (last 10m)</span></th><th class="header"><span
data-original-title="The average time a Tuple spends in the execute method. The
execute method may complete without sending an Ack for the tuple." class="tip
above">Execute latency (ms)</span></th><th class="header"><span class="tip
above" title="The number of incoming Tuples processed.">Executed</span></th><th
class="header"><span data-original-title="The average time it takes to Ack a
Tuple after it is first received. Bolts that join, aggregate or batch may not
Ack a tuple until a number of other Tuples have been received." class="tip
above">Process latency (ms)</span></th><th class="header"><span class="tip
right" title="The length of the executor's queue.">Queue Length</span></th><th
class="header"><span data-original-title="The number of Tuples acknowledged by
this Bolt." class="tip above">Acked</span></th><th class="header"><span
data-original-title="The number of tuples Failed by this Bolt." class="tip
left">Failed</span></th></tr></thead>
--- End diff --
Yeah, I'd like to reformat these templates in a few places. There are quite
a few spots like this in the HTML. I can fix this and file a separate jira for
that.
> 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 (Incubating)
> Issue Type: Wish
> Reporter: Dane Hammer
> 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.2#6252)
