2016.06.24
昨天3台服务器中的1台，supervisor起不来，一直报FileNotFoundException，找不到“storm/data/supervisor/localstate/1466652445675”这个文件。
后来把storm/data/supervisor目录删除掉就好了。
这个估计是不正常关机造成的状态不一致造成的。具体原因不清楚。解决办法受这个帖子启发：
http://stackoverflow.com/questions/22318783/storm-supervisors-crashing-on-reboot
昨天还有一件事，
140、14服务器以前部署过统计集群，这次集群并没有包含201、14，但是14上的守护并没有删除，从log看14上的mongo一直尝试连接140，140确实在处理214的请求，但最终好象是因为opTime不同，并没有成功。此尝试一直在进行，干扰是肯定的。估计是replset名相同造成的。
从14上的log看，14上收到的hearbeat信息中id值不匹配。
昨天给email库的各个collection添加了索引。
增加索引是在库的初始化脚本中进行的，复制集初始化完成后即进行。虽然库、表都没有，表结构也没有，但不影响创建索引，这就是freeschema的魅力吧。
昨天实体机集群非正常关机，今天开机后，竟然奇迹般自动恢复了。
storm：
134 worker日志：
worker起的比较早，9：33以前一直在连接140的6700端口，应该是supervisor还没有起来。为什么连140的呢？
9:34, 报kafka连不上， node broker/id/0 doesn't exist.
一直报从kafka获取topic数据失败，fetch failed.
9：40分正常了，没有error了。
supervisor日志：
9：31报zookeeper连不上的错误，socket, connection refused, zookeeper timeout
9:33:08之后错误消失。
kafka日志：
9:33:07之前报zookeeper连不上错误。
9:39:46~9:39:49一直报NotLeaderForPartition， leader not local的错误, 告警。应该是重启之后做了balance。之后消失。
mongodb日志：
9:31~9:34replset之间的连接建立。到9:40,storm相关的连接建立。这与5分钟tick相关吗？
flume日志：
9：31报zookeeper连不上错误，6秒之后就不报了，这个这么快？
zookeeper日志：
9：33之后建立好集群。flume为什么那么快就连上了？
验证ui上kill topo，bolt的clear是否可以调用成功。答案yes
验证通过脚本停止topo，bolt的clear是否可以调用成功。答案yes
有待验证， rebalance时，bolt的clear是否可以调用成功
在初始化mongodb的时候，在一台服务器上，先初始化完rs，然后给某个库的某个collection添加索引（写在一个脚本里面）。
这个添加索引的操作，使用命令行时，必须在primary上进行。
按道理，进行rs初始化的服务器不一定是primary，所以，创建索引有可能会失败。但实际情况是，即使该服务器不是primary，创建索引也成功了。
应该是创建索引的命令，在rs选举primary之前完成的，貌似这时候可以做各种初始化工作而不要管服务器是否为primary。
2016.7.1
今天启动集群，发现一个机子的zookeeper起不来。
手动起一下，报“starting zookeeper ... already running as process 3797”。 ps -ef 里面又找不到该process 3797。ps -ef | grep zookeeper, 也找不到。
有点莫名其妙，zookeeper bug？ 解决办法： kill -9 3797， 再启动就OK了。
2016.7.29
前天有个同事说一台storm服务器的oracle起不来了。说是内存不足。
看了下，16G内存还有9G free。
然后启动停止集群，deploy程序跑到这台服务器的时候，也报内存不足。
top查看了一下，nimbus、kafka、worker进程的cpu使用率都在100%以上。这时候集群啥事也没干。
停止topology，cpu使用率都下来了。看来kafka的cpu高利用率也跟topology有关系。
通过top -H -p 进程id 查看进程中哪个线程cpu占用率高
再用jstack查看调用栈
jstack -F pid > tmp1.log
grep -A 50 线程id tmp1.log
最终发现都是跟topology与kafka的通讯有关。
gg了一下：
http://www.cnblogs.com/lingfengblogs/p/5242288.html
http://stackoverflow.com/questions/20469734/cpu-usage-and-serialization-at-each-worker
http://www.cnblogs.com/jianyuan/p/4891450.html
问题出在storm的一个配置项上：
topology.sleep.spout.wait.strategy.time.ms
spout每次发送完消息，会更新emitted_count, 如果没有更新，则休眠“topology.sleep.spout.wait.strategy.time.ms”后，再次调用spout发送。
“topology.sleep.spout.wait.strategy.time.ms”缺省值是1毫秒。由于是空闲状态，所以并没有消息发送，所以每隔1ms，kafkaspout都会重新
连接kafka，获取消息。我们的topology里有141个spout，所以1毫秒内会有141个socket连接。大概是这么个意思。
把“topology.sleep.spout.wait.strategy.time.ms”调到1000毫米，cpu使用率绝大部分时间都降到5%以下了。
上述问题估计也造成内存碎片化很厉害，导致分不出1较大块完整的内存来，造成其它程序启动失败。
同时还修改了kafka的“heatbeat.interval.ms”, 新值10000，缺省值1000。但从测试的效果看，该值影响不大。
2017.4.19
预处理启动时，检测zookeeper总说zookeeper有可能他没起来，但进程在啊。
后来发现是防火墙没关
通过新安装的预处理平台调试storm程序，但是debug的时候一启动就报：
java.lang.RuntimeException: java.nio.channels.UnresolvedAddressException
......
搜了下，这篇文章解决问题：
http://www.cnblogs.com/zhwbqd/p/4045263.html
问题在于: storm kafkaSpout 通过ZK去获取kafka的地址, 但是zk中保存的kafka是以域名的方式保存的, 调试机没有配置这几台服务器的host。
2017.6.1
今天同事说有台机器的redis起不来了，打开日志看了一下，说
Wrong signature trying to load DB from file
Fatal error loading the DB: Invalid argument. Exiting
查了一下，应该是redis非正常关闭造成 rdb文件损坏引起的。 删掉rdb文件再启动就好了。
这个原因是现在的redis停止脚本用的kill -9杀进程，应该用
redis-cli -p 63xx shutdown