Storm ui 说明
Auth：ashaff
一、数据上报及展示流程
- 数据上报流程：worer/supervisor/nimbus 会定时上报统计信息到 zk
- 数据展现流程：ui 调用 nimbus 的服务从 zk 中取出数据进行分类聚合汇总，然后展示到前端
二、数据类型
一、 worker
- spout：
- emit：向下游提交 tuple，对应的统计数据为 emit/transfer，emit=emit 执行数量，transfer=emit 执行数量 * 下游 bolt 个数
- ack： 成功流转之后的操作，对应的统计数据为 ack/complete-lantency，ack=成功流转次数 complete-lantency=成功流转平均时间
- fail：失败流转之后的操作 对应的统计数据为 fail，fail=失败流转次数
- bolt：
- execute：接收到上游数据之后的执行操作 对应的统计数据为 execute/execute-lantency，execute=执行次数 execute-latency=平均执行时间
- emit：与 spout.emit 相同
- ack：bolt 完成 execute 主动发起的 ack 操作，对应的数据为 ack，ack=执行次数
通常数据的统计会对系统的性能造成一定的影响，那么 storm 中为了平衡这种影响，采取了抽样的方式进行上报数据； storm 中把此值默认为 0.05，即每执行 20 次则执行一次数据累加(value = 20)，当然我们也可以修改抽样的配置值为 1，那么就是逐条上报了。
二、 supervisor
- node add：增加 supervisor 节点，对应的会向 zk 注册一条 supervisorinfo 信息，包含：host all-slots used-slots uptime version resource
- node del：删除 supervisor 节点，那么会从 zk 中删除一条 supervisorinfo 信息
- worker startup：启动了一个 worker，那么 supervisorinfo 的 used-slots( 1) resource 会发生变化
- worker shutwodn：关闭一个 worker，那么 supervisorinfo 的 used-slots(-1) resource 会发生变化
- node add：增加一个 nimbus 节点，那么会向 zk 注册一条 nimbus-summary 信息，包含：host port isleader uptime version
- node del：删除一个 nimbus 节点，那么会从 zk 中删除一条 nimbus-summary 信息
- leader change：leader 发生变更，那么对应的 nimbus-summary 中的 isleader 发生变化
三、 nimbus
四、 页面展现结构
二、 Storm ui 首页主要分为5块:
Cluster Summary
Nimbus Summary
Topology Summary
Supervisor Summary
Nimbus Configuration
如下图所示：
1 Cluster Summary
Version: storm 版本号
Nimbus uptime: nimbus 运行时间
Supervisor: storm集群中supervisor的数目
User slots:使用的slots数Free slots:剩余的slots数
Total slots:总的slots 数（对应配置文件的supervisor.slots.ports 属性配置的端口数,集群的总和）
Executors：线程数
Tasks:任务数
2 Topology summary
Name : topology 名称
Id: 系统生成的topology id
Status: 运行状态(ACTIVE, INACTIVE, KILLED, REBALANCING)
Uptime:运行时间
Num workers: 运行的 workers 数
Num Exectors: workers 运行的线程数
Num Tasks: Excetors 运行的任务数
3 Supervisor summary
Id: 系统生成的 supervisor Id
Host: supervisor(主机)的主机名
Uptime:运行时间
Slots: supervisor的端口数
User slots: 使用的端口数
4 Nimbus Configuration
是 nimbus 集群中的配置文件信息，不在详细解说（关键的可以在storm 安装章节查看）
三、 Topology 页面
Topology 页面主要分7块：
Topology summary
Topology actions
Topology stats
Spouts (All time)
Bolts (All time)
Topology Visualization
Topology Configuration
1. Topology summary
同首页中的 Topology summary
2. Topology actions
Topology 运行状态，可以手动更改状态
ACTIVE,
DEACTIVATE
KILLED
Rebalance
3. Topology stats
Window:时间窗口，显示10m、3h、1d和all time的运行状况
Emitted: emit tuple数,调用OutputCollector的emit方法的次数
Transferred: transferred tuple数, 实际tuple发送到下一个task的计数.
与Emitted的区别：如果一个task，emitted一个tuple到2个task中，则transferred tuple数是emitted tuple数的两倍
complete latency: spout emitting 一个tuple到spout ack这个tuple的平均时间
Acked:成功 tuple数
Failed:失败tuple数
如果一个bolt A使用all group的方式(每一个bolt都要接收到)向bolt B发射tuple, 此时bolt B启动了5个task, 那么trasferred显示的数量将是emitted的5倍.
如果一个bolt A内部执行了emit操作, 但是没有指定tuple的接受者, 那么transferred将为0.
有的bolt的execture方法中并没有emit tuple, 但是storm ui中依然有显示emitted, 主要是因为它调用了ack方法, 而该方法将emit ack tuple到系统默认的acker bolt，因此如果anchor方式emit一个tuple, emitted一般会包含向acker bolt发射tuple的数量，另外collector.emit(new Values(xxx))和collector.emit(tuple, new Values(xxx)) 这两种不同的emit方法也会影响后面bolt的emitted和transferred, 如果是前者, 则后续bolt的emited tuple 和transferred tuple这两个值都是0, 因为前一个emit方法是非安全的, 不再使用acker来进行校验.
4. Spouts (All time)
Id: spout id
Executors：线程数
Emitted: emit tuple数
Transferred : transferred tuple数,
complete latency: spout emitting 一个tuple到spout ack这个tuple的平均时间
Acked:成功 tuple数
Failed:失败tuple数
Error Host： 发生错误的机器
Error Port: 发生错误的端口号
last error: 最近的错误数
5. Bolts (All time)
Execute latency(ms) ： bolt 执行 execute 方法的平均时间
Executed: tuple 处理数
Process latency(ms):bolt收到一个tuple到bolt ack这个tuple的平均时间
注：其他字段都在上面讲过，就不在说明
6. Topology Visualization
拓扑图展示
7. Topology Configuration
配置说明，不在详解
注 spout，bolt 页面可以参考topology 页面中的 spout,bolt 中的字段说明
