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

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

一、数据上报及展示流程

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

二、数据类型

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

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、首页-初始化

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

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

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

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

5、topology 详情页

  • 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 详情页
  • 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 页面

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

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

五、常见的操作流程

我们在使用 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 文件进行分析。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏全华班

springcloud学习手册-Ribbon(第一节)

导读 | 介绍什么是Ribbon,主要概念和内容 前几天学习了Eureka ,今天咱们再来学习springcloud 的第三部分内容Ribbon 那什么是 Ri...

3706
来自专栏L宝宝聊IT

LVS负载均衡群集

1446
来自专栏Java技术栈

浅析负载均衡的6种算法,Ngnix的5种算法。

常见的几种负载均衡算法 ? 1、轮询法 将请求按顺序轮流地分配到后端服务器上,它均衡地对待后端的每一台服务器,而不关心服务器实际的连接数和当前的系统负载。 2、...

28812
来自专栏Ken的杂谈

asp.net表单提交-从客户端检测到潜在威胁解决办法

无论是asp.net WebForm开发还是asp.net MVC开发,如果从客户端提交到服务器端中的数据包含html标记。

762
来自专栏运维

求两数的平均值

某文件中,有如下多行数据 ,需要统计含关键字:real 对应行的数值(第二列),并最后得出总平均值 请给出相关命令 或 实现思路? 样本数据如下: Real  ...

811
来自专栏blackheart的专栏

[解读REST] 4.基于网络应用的架构风格

衔接上文[解读REST] 3.基于网络应用的架构,上文介绍了一组自洽的术语来描述和解释软件架构;如何利用架构属性评估一个架构风格;以及对于基于网络的应用架构来说...

1785
来自专栏我是攻城师

ElasticSearch里面的偏好查询

2475
来自专栏莫韵的专栏

基于ELK的nginx-qps监控解决方案

nginx-log中所有我们需要的信息,都是有的 。

6669
来自专栏ATYUN订阅号

【深度学习】软件开发前需要了解的10种常见的架构模式

在主要的软件开发开始之前,我们必须选择一个合适的体系结构,它将为我们提供所需的功能和质量属性。因此,在将它们应用到我们的设计之前,我们应该了解不同的体系架构。 ...

2725
来自专栏racaljk

Boost Coroutine2 - stackful coroutine简介

协程可以很轻量的在子例程中进行切换,它由程序员进行子例程的调度(即切换)而不像线程那样需要内核参与,同时也省去了内核线程切换的开销,因为一个协程切换保留的就是函...

1283

扫码关注云+社区