解决bug的一些方法

1，先找到一台机器上正确的日志目录。之前在解决一个扩展报警器拉取消息延时的时候，早上没环境，先去看扩展报警器模块的代码，有环境后马上先去/var/log/zstack目录全局搜索 grep -R 'xxx'，结果获取到的信息非常少，

几乎没有，换了几个搜索关键字去查询，也没得到结果，后面询问XX才知道扩展报警器的日志在/usr/local/zstack/apache-tomcat/logs/management-server.log。cube 安装日志就在/var/log/hyperconverged/，

/var/log/xms/ ，/var/log/zstack/，/tmp/zstack_installation.log等不同路径下，还有一些文件虽然不是日志，但也有类似日志的功能，比如一些自动生成的配置文件。

2，日志可能分布在不同的机器上。web上的请求会生成消息下发到两个管理节点上，由两个管理节点中的任意一个管理节点去执行请求，那们我们需要的日志就很可能分布在这两个管理节点上，因为这两个管理节点会做负载均衡。

后面查看日志，发现一台机器大约半个小时有连续的日志输出，之后间隔半小时才继续有日志输出，因为扩展报警器是定时拉取消息任务，所以两台机器上的两个日志都要看。

3，和正常的结果比较差异。我在日志输出里看到了一个http 请求url，并看到了这个请求的返回结果，但我复制该url并使用apipost等工具发起请求时，返回结果却为空，反复比对请求后结果还是这样。这时候就开始怀疑这个请求在多少秒

内是有数据返回的，多少秒后查询就没有数据了，这可能是一种保护特性。这时候得去问xsky对接方的这个接口了，可能得几个小时后才会有答复。但不久我们发现xsky的ui管理界面的报警器是有数据的，不会出现过了半分钟，一分钟就没数据的情况，而我们就是从那里拉取数据的，点击F12选中网络选项卡，发现它url的请求是alert-infos，而我们的请求是alerts，修改一下我们的url请求，马上就出现了数据。第二天询问xsky对接方，原来5.2版本后扩展报警器的url就变了，

alerts请求查询的是临时表，数据30秒后就被清空，而alert-infos永久有数据。查询xsky的api文档，发现这两个请求只改变一个参数名称，略微修改代码就可以正常运行了。ps：在修改代码的时候，最好不要重复写相同的if-else代码逻辑2遍或2遍以上，相同的逻辑就放到父类去，if-else的代码容易产生硬编码，不好，应该想到一种没有if-else的代码覆盖掉if-else的分支逻辑。