分布式系统的DEBUG

最近一段时间，项目从python2转为python3，并伴随的大量的功能重构，于是乎陷入了测试、找BUG、改BUG的循环中。老实说，吐了吐了。

最新的一个BUG，是nmap扫描的问题。

发出3000个IP nmap扫描的任务，最后只收到了不到100个IP有端口。

测了一下，大部分ping不同。

能ping通的再测一下，--min-parallelism设置得太高，同时节点发出大量数据包，可能导致网络拥堵收不到返回包。

那么调用Nmap时 --min-parallelism调低一点，超时调高一点，跑到中间不继续往下跑了，print都没有了？

原来是celery超时了。

过程中，最麻烦的点

一 分布式任务中，复现时无法确定发出的流量是哪个节点接收到了

对于这种情况，要不停用其他节点留下一个节点；要不发出一批流量，挨个节点检测。

为了避免是某个节点的环境出了问题，我选择了挨个检测。

但这两种不管选什么，唉，都在半夜弄吧。毕竟白天扫描器要正常运行，晚上半夜流量少点，可以折腾。

二 日志缺乏或者混乱

之前python2版本的日志是比较完善的，但python3版本这一块功能做了一半，其中有的用Logging输出，有的用Print，有的重定向了输出(找了半天，我输出呢)，苦不堪言。

三 单个任务耗时长

对于nmap或者其他扫描任务，可能是在调用nmap或者扫描时出了错，不能简单地用其他数据替换，所以老老实实跑。

一批IP + nmap扫描，用时超过十分钟。

每次调试，改插件设下print、改任务、重启扫描器(嗯，因为重构，任务这块还有bug，所以还得重启扫描器)、十几分钟过去了，再挨个节点检查一下，一轮下来半小时就过去了。

整个过程不像正常debug一样，运行，看报错，运行，看报错；而是 改动、运行，过去半小时，检查结果。

加一句调试信息，等半小时。

四 该做什么

找BUG心得，尽量 用最小的成本去复现BUG

测试环境其实应该完善好，但因为测试环境的数据远不如线上环境来的正常，插件移植也比较麻烦，所以一直懒得弄。

这一点，应该学习一下其他项目，定期会将线上的 任务/漏洞等数据同步到线下。

迷，凌晨4点，从十点开始，其实也就调试了十几次。

难受啊兄der