万万没有想到，打个日志还能打出一个BUG来

记一次线上日志BUG排查

1：事件回顾

1.1：问题

一个接口一直返回：

{"httpStts":200,"responseData":"{\"code\":500,\"msg\":\"服务器内部错误\",\"data\":null}"}；

1.2：排查问题

用grep "设备号" xx.log；很快定位到了抛出异常的方法：

1.3：排查问题思路 

点进方法一顿找，各种怀疑，都被一一排除后；自己写测试用例（概述一下这个方法，它调用了其他平台的接口，所以怀疑是这个设备，掉其他平台没有返回结果，代码里存在空指针的问题）；测试用例只是打印出调用其他平台返回的结果；结果一切正常；一个方法一个方法点进去，也没发现异常。

1.4：解决问题措施

重启服务器；没用（×）

怀疑本地和测试环境代码不一致；重新打包部署；没用（×）

1.5：诡异的地方

本地跑没事，线上就有问题；

抛出的异常也不是方法里try catch出的异常；是被拦截的异常

2：解决问题

在同事提醒下用less log，查找关键词，向上查找，找到了准确的报错行

代码：

居然是日志爆出的错误 ；这是我压根就没去怀疑的地方。。

写测试用例的时候也只是调用一下内部方法，没有走完全流程

打日志的时候手快打错了，本来要打参数的，打成了http的请求；如果request是http类型，使用JSON.toJSONString(rrequest)方法会抛出异常。因为http类型不是Java对象，不能被序列化为JSON字符串。

3：总结

grep，只能查出关键字所在行，没有上下文信息

less，可以看上下文

以后排查日志都用less命令，grep虽然也能找到问题，但是无法准确定位到，有些很低级的错误，写出来后本人很难靠看代码发现。

4：知识点回顾：

less xxx.log

shift+G直接跳到最后一行

?+要搜索的内容  ？是向上查询， /是向下查询

n向上翻找，N向下翻找