storm问题排查记录01

storm问题排查记录01

1、问题发现

在一次数据核验时发现我方最终统计数据量比交易所方统计数据量有较大缺失，马上对比目前数据量，发现也存在缺失情况。该问题造成了较大财产损失，需要尽早排查问题并加以修复。

2、问题排查与解决

    1、锁定问题产生范围

        马上前往数据流途经的各个模块部署的服务器拉取日志并进行数据统计，与最初数据量做对比，最终锁定数据流在途经storm模块及前后消息中间件模块后，在下游出现了数据丢失。

        同时发现不同时间段都存在数据丢失情况，并且数据量在数据高峰期丢失情况尤其严重。

   2、锁定产生问题模块

        前后的消息中间件同时还承当其他项目数据的传递，而这些数据并没有发生数据的丢失情况，因此首先排查嫌疑最高的storm模块；

        storm提供了网页可视化界面的数据监控storm-ui，马上调出storm-ui，首先查看storm数据源spout与数据最后流向bolt并进行数据量，对比各个时间跨度的数据量，发现果然出现了丢失情况。

    3、锁定产生问题的storm组件

        问题范围进一步缩小，开始排查storm-ui中，数据流经过的各个组件的监控情况；
        根据数据流的流向，依次获取数个时间跨度内，每个途经组件的execute数据量及其上游组件的emit数据流进行对比，最终定位产生问题的组件bolt！！

    4、发现与解决问题

        对问题组件进行分析，发现该组件间断性的处于自动重启状态，同时组件实例数只剩下一个了。显然一个实例根本无法承载大数据量的打击，这也直接导致了单点故障问题的产生。
        保留事故现场后，尝试重新拓扑，再次查看storm-ui后发现实例仍然是一个，于是推断源码出现问题。排查源码后发现配置参数拼写出现错误导致该bolt实例数没有被读取上！修改过来后重新拓扑，实例数恢复正常。

思考

        导致原因是某开发人员在storm模块维护更新时不慎修改导致，同时分支合并提交时review人员也没有发现问题，这种问题的出现是不应该的。应该有所反思，对工作要有责任心，工作中要更加细心谨慎。

        这次事故也能看到，storm一个组件的数据流承载量是有限的，我们或许能根据这次事故分析出storm一个组件对相应数据流类型的大致承载量，从而合理的配置组件的实例数，合理分配服务器资源！