大数据实时处理利器 storm 的 ui 解剖

众所周知，storm 已经是业界主流的流时处理框架，Storm 被广泛应用于实时分析，在线机器学习，持续计算、分布式远程调用等领域。当前无论是内部还是外部论坛介绍原理的文档都比较多，但主要都是从运行机制和原理方面的介绍，在 UI 方面的介绍甚少，今天我试着向大家介绍一下 storm ui，一方面可以让大家了解一下 storm 的机制，另外也可以让大家更好的使用好 storm ui 协助大家自助解决使用过程中的问题。

一、数据上报及展示流程

[1500360303170_4455_1500360303036.png]

• 数据上报流程：worer/supervisor/nimbus 会定时上报统计信息到 zk
• 数据展现流程：ui 调用 nimbus 的服务从 zk 中取出数据进行分类聚合汇总，然后展示到前端

二、数据类型

通常我们要真正理解一个事物，通常都会从来龙去脉进行解剖；理解 storm ui 也是，想理解 storm 有什么数据，那么先去理解 storm 有哪些动作就事半功倍了，以下是 storm 中 worker/supervisor/nimbus 的基本操作及对应的数据类型，左边为操作，右边为数据。

[1500360333030_74_1500360332741.png]

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 会发生变化

nimbus

• node add：增加一个 nimbus 节点，那么会向 zk 注册一条 nimbus-summary 信息，包含：host port isleader uptime version
• node del：删除一个 nimbus 节点，那么会从 zk 中删除一条 nimbus-summary 信息
• leader change：leader 发生变更，那么对应的 nimbus-summary 中的 isleader 发生变化

三、页面展现结构

在上述的第二点中已经说明了基本操作及对应的数据类型，那么在页面中就可以很好的对应了，先从整体视图来看看我们 storm ui 有什么信息，此 storm ui 为我们数平自己开发维护的 jstorm，一方面用 tab 页把 topology summary/nimbus summary/supervisor summary/nimbus configuration 分类展示，另外加了很多快捷链接入口用于查看到关注的内容，以及把常用的 kill topology 操作移动到首页。

1、首页-初始化

[1500360610964_1305_1500360610985.png]

• cluster summary： 展示集群的整体信息，包含版本、在线时间、启动时间、管理的 supervisor 个数、总的节点数、已用节点数、空闲节点数、在运行的 executor/task 数
• topology summary： 展示所有正在运行的 topology 信息，包含名称、id、状态、在线时间、提交时间、占用的 worker 数、拥有的 executor 数、拥有的 task 数、快捷关闭按钮

2、首页-supervisor summary： 展示所有的 supervisor 节点，包含 id、主机名称、在线时间、启动时间、总的 worker 节点数、已经使用的 worker 节点数

[1500360649506_2038_1500360649360.png]

3、首页-nimbus summary： 展示所有的 nimbus 节点，包含主机名称、端口号、是否 leader、版本号、在线时间、启动时间

[1500360752990_252_1500360752981.png]

4、首页-nimbus configuration： 把配置信息以列表展现出来

[1500360775086_9548_1500360774866.png]

5、topology 详情页

[1500360843542_4083_1500360843436.png]

• topology summary：与首页对应的 topology summary 对应。
• topology actions：用于 topology 的一些操作：激活、注销、重分配、debug/stop debug、修改日志级别。

• topology stats：按时间窗口展现统计数据：十分钟表示近十分钟的统计，3 小时表示近 3 小时的统计等。
• spouts：spout 组件的统计数据，数据含义在第二点的数据类型已有说明。

• bolts：bolt 组件的统计数据，数据含义在第二点的数据类型已有说明。
• topology visualization：展示 topology 的拓扑结构图及数据传输情况。

• topology configuration：展示 topology 的配置信息。6、component 详情页
  

  [1500360889245_9551_1500360889249.png]
• component summary：展示 component 的 id、executor 个数、task 个数、debug 日志。

• component actions：提供 component 的 debug/stop debug 操作。
• spout/bolt stats：按时间窗口展示数据，数据含义在第二点的数据类型已有说明。

• input stats：输入流数据，包含上游 component、stream、执行时间、执行次数、bolt 正常流转的处理时间、ack 数、失败数。
• output stats：输出流数据，包含 stream、emit 个数、transfer 个数。

• executors：executor 数据，包含 id，在线时间、所在主机及端口、emit 个数、transfer 个数、执行时间、执行个数、成功流转直接、ack 个数、失败个数。
• profile and debugging：用于诊断 worker 的运行情况，执行 jstack/jmap 等操作对 jvm 进行检测输出到文件，供用户下载打开查看 jvm 的运行情况。

四、用户角度考虑的信息展示

了解完上面的介绍，相信都会有大概的一些印象，但仅有那些信息是否已经足够呢？我们不妨从使用者的角度来思考一下：

1、 每次提交 topology 都要去登陆到后台去提交，很麻烦，是否可以在 UI 中提供页面去提交呢？—增加提交 topology 页面

[1500361012881_2615_1500361012624.png]

[1500361108415_8627_1500361108374.png]

2、一个 topology 的 worker 分布在哪些节点？每个 worker 都有哪些 executor？每个 worker 的 jvm 内存情况、进程内存情况？—增加 worker 详情页面

[1500361238166_6385_1500361238125.png]

3、 一个 supervisor 有哪些启动了的 worker？ 每个 worker 有哪些 executor？

[1500361254824_4181_1500361254561.png]

五、常见的操作流程

我们在使用 storm 的过程中，会不定时的出现一些问题，熟练 storm ui 可以更好的协助自己分析解决问题。以下是常见的几个例子：

1、 上游发的次数与下游接收执行的次数不一致，怎么办？

首先理解 topology 的数据类型，可参照第二点的说明，然后进入 topology/component 详情页面进行对比。

2、好不容易写了一个 topology，提交之后，发现一直没有数据输出，可能是启动失败了，怎么办？

点击 nimbus summary 的 port 链接查看 nimbus 日志，查看任务是否分配成功；

点击 supervisor summary 的 host 链接 supervisor 日志，查看 supervisor 是否有启动相应的 worker ；

点击 topology summary 的 num workers 链接到 worker 页面，选择对应的 component 查看 worker.log，查看 worker 是否有正常启动。

3、下游说发送的数据与预期不一样，我想看看 topology 究竟传输的是什么数据，有没办法看？

想查看整个 topology 中各个 component 传输的 tuple 数据，那么在 topology 详情页面启动 debug，输入百分比参数，那么 topology 会按照比率把 tuple 信息输出到 events.log，然后在 component 详情页中点开 events.log 链接就可以看到传输的数据是什么。当然也可以选择指定的 component 进行 debug，那么就只对一个 component 进行日志输出。

4、 写的 topology 加了很多 debug 级别日志输出，但是发现 storm 的日志级别是 error 级别的，自己想看的日志无法输出啊，怎么办？好捉急啊！！

ui 中提供了修改日志级别的操作，只需要点两下修改一下日志级别为 debug，日志就源源不断输出到 worker.log 了，好欢喜。

5、 提交的 topology 在运行过程中，发现 worker 数不够用了，某个组件积压太多了，想加多几个 worker 怎么办？

在 topology 详情页面点击 rebalance 输入相应的参数就可以重新分配了。

6、 发现几个 worker 的 CPU 占用好高啊，该怎么办？

进入 component 详情页面进行 profile 操作，执行 jstack 获取 jvm 运行堆栈，打开 jstack 文件进行分析。