我们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，也喜欢结识业余爱好玩得溜的各位同学。