性能度量参见
http://www.jstorm.io/Maintenance_cn/JStormMetrics.html
JStorm将信息展现为如下
-
Emitted
当前1分钟发送的消息数,包括业务消息和acker消息。理论上是SendTps60(N+1)。N为下流的bolt种类数目。 -
Acked
当前1分钟被ack的消息数。注意这个和Emitted的区别: 在错误率不高的情况下,如果打开了acker机制, emitted的消息里面含有acker消息, 经常emitted 消息数量是acker消息数量的N+1倍。N为下流的bolt种类数目。 -
sendTps, recvTps:
发送/接收数据tps。指标包含了与storm本身组件,topology_master,acker之间的交互,只能用来查看运行状况,不适合统计用。 -
Failed
当前1分钟 被ack失败的消息数(可能是没有完全处理,也可能是超时)。 -
TupleLifeCycle
component/task/stream, 这个是一个tuple或者一个batch从上一级component中被emit出来,单位为微秒, 到当前component接收到这个tuple或者batch的时间,这段时间包括了上游序列化时间、网络发送和下游反序列化时间的总和 -
ExecutorTime
component/task/stream, 只在spout中存在,nextTuple所花费的时间,单位为微秒。 -
ProcessLatency
component/task/stream, 这个是bolt execute消耗的时间,单位为微秒, 具体来说,就是从processTuple时,tuple被放进pending map时会给一个时间, 到调用ack的时候从pending map中取出来,用当前时间减去放入的时间,即为ProcessLatency。
如果是spout,则为从消息最初从spout发出,一直到最后收到acker的ack消息的完整时间。 在spout中,由于ProcessLatency意味着一个tuple走完了所有的bolt最后被ack, 因此通常会比较大(一般会比TupleLifeCycle还要大)。
-
TupleLifeCycle
这个是一个tuple或者一个batch从上一级component中被emit出来,单位为微秒, 到当前component接收到这个tuple或者batch的时间,这段时间包括了上游序列化时间、网络发送和下游反序列化时间的总和和队列排队时间。对于spout来说,它的上级是acker。 -
BatchInterval
性能调优使用, 表示2次batch打满时,间隔微秒(恕我迟顿,完全不可理解)。虽然我知道JStorm支持batch处理,可是我这个不是这种topo啊。