These are chat archives for alibaba/jstorm

23rd
Dec 2016
Fengdada
@Fengdada
Dec 23 2016 07:46
请教任务动态调的动态伸缩
@unsleepy22
Fengdada
@Fengdada
Dec 23 2016 07:52
应用场景:nimbus和supervisor部署在Docker中,我们会配置supervisor的弹缩策略。但是当supervisor弹缩后,需要动态修改TOPO的并行度,才能充分利用新增的资源。也就是说,只能获取topo的metrics,根据metrics的信息调整进程/线程并行度,这样理解对吗?@unsleepy22
如果理解正确,如何来获取topo的metrics?翻了下论坛,有提到ServiceHandler.getTopologyMetrics()方法来获取,也有提到实现一个MetricUploader来获取。应该用哪种?@unsleepy22
Fengdada
@Fengdada
Dec 23 2016 07:58
TopologyMetric这个类,没看到具体的metrics定义,反序列队列负荷、执行队列负荷等都在哪?如何判断需要增加还是减小并行度?@unsleepy22
yunfan123
@yunfan123
Dec 23 2016 08:02
这个TopologyMetric类里面有workerMetric、componentMetric、XXXX
刚好我现在也想搞个这个东西。
我现在用的是实现MetricUploader,和ServiceHandler.getTopologyMetrics()没什么本质差别。我的想法是,以每天使用资源使用的max为准,定时去rebalance。
你们现在是用的jstorm-on-yarn吗? @Fengdada
Fengdada
@Fengdada
Dec 23 2016 08:09
就用jstorm-core,没发现特别的问题 @yunfan123
yunfan123
@yunfan123
Dec 23 2016 08:36
我的理解实现MetricUploader会更好一些,只拿当前的数据rebalance意义没那么大。我的计划是实现的MetricUploader将数据导出来,然后根据一天的数据用外部脚本balance。
还有就是好像 supervisor发现本地worker dead、queue full这些都没有event,看代码好像只能去 zk 上面拿数据。
Fengdada
@Fengdada
Dec 23 2016 08:54
worker dead和rebalance属于不同的范畴,zk维护集群的状态(比如说心跳啊,任务分配啊),worker dead 后由supervisor重新创建,因此没有event?rebalance主要是修改并行度的问题,需要根据当前负荷来判断并行度是否需要修改。如何判断的策略我没想清楚。
请求大大指点