我们Rest API backend程序的，或多或少都会涉及在生产环境的异常排查。拿着一大堆的日志文件来找root cause，无异于大海捞针。
本文提供一种简单易行的方法来辅助，能大大提升排错效率。
问题
开发Rest call backend的同学们估计经常会碰到调用者说，“我在什么什么时候调用你哪个API，有调用异常。”我们就会跑到Web Server的访问日志，业务逻辑产生的日志里面去捞可能的异常，或线索。
从这么海量的日志文件里面捞线索不是一件容易的事。光靠人肉从可能上G的文件里找出某次API调用产生的日志，这有点火箭工程的感觉。如果有办法把每个API的调用路径给分析出来，无疑能大大提高排错的效率。
思路
我们为每个API调用生成一个唯一ID，从访问日志开始，每次的日志记录都会包含这么一个ID。最后在生成response的时候，把这个ID通过HTTP header返回给调用者。
如果调用者能提供出错的那次ID给我们，我们通过对日志进行查询（例如grep, zgrep)，就可以很方便的找到整个API的调用路径；即使不能提供ID，我们也可以通过调用的线索（例如参数，时间），通过访问日志找到值得怀疑的ID，进而找到调用路径。即使不是rest call而是RPC调用，也可以用类似思想去处理。
举个实际开发中的例子：
实现
以下是一个基于SpringMVC和log4j的实现。
原理介绍：在self4j的jar包里有个MDC类，既可以被我们的java代码访问，也可以被日志的代码访问，也就是可以配置在log4j2.xml中。我们可以用SpingMVC的filter机制在入口处生成一个sequence id，以key/value形式放入MDC中。然后在log4j2.xml中以”{}”来访问这个id。这样就可以在所有打印日志的地方打印出sequence id.
“Talk is cheap, show me the code!”
下面马上奉上代码：
首先生成sequence id
访问日志的生成
可以有两种方式，一种是用web server已有的功能，另一种是用filter机制自己生成。因为我们想把一些敏感信息过滤掉，所以用了后一种方式。
敏感信息过滤的代码
注册两个filters
顺序是让sequence filter放在前面。
最后给出log4j2.xml的关键配置
代码就是这么多，是不是比较简单易行通用？
希望对同学们的开发有帮助，同时欢迎同行加入探讨。
本文作者：詹青（点融黑帮），毕业于微软和EA，现任点融Fincore team和Data team的架构师。对重复代码有那么一点过敏症。喜欢网球，唱歌和salsa，也喜欢结识业余爱好玩得溜的各位同学。
