有舍才有得

这里说的“效率”，不是说输出日志的速度有多快，而是说输出的日志可以帮助我们有效快速地找到问题。
“想法来于压力”。如何写出一个有效率的日志、对维护有实际价值的日志，这是在中油工行项目中尤其需要考虑的一个问题。一来是客户的苛刻，客户要求我们解决问题的速度要快，二来是涉及到银企直联，钱直接通过我们的系统付出去了。所有这些都要求系统有一个完备而有效的日志。
我们现在使用的日志方式并不是一种有效的日志，就是把所有程序运行的日志都输出到一个文件里。这个日志文件通常会很大，甚至上G，这种日志用于查错是一个漫长而痛苦的过程。等到我们把问题找出来的时候，客户可能已经把领导叫过去了。
这里要说的有效日志就是为了解决这个传统的问题。在说这个有效日志的时候，先引入一个概念就是“跟踪器”。如果一件东西里面被放入了跟踪器，那么不管这件东西跑到哪，我们都可以找到这件东西。这里说的日志方式用的就是这个想法，所谓“跟踪器原理”。这里说的“一件东西”就是我们程序运行的一个请求处理过程，从被触发到执行结束。在这个请求处理过程中定义一个“日志跟踪器”就可以很清楚地知道这个过程是怎么发生的，知道整件事情发生的经过。
那么如何定义一个日志跟踪器呢？其实一个日志跟踪器的输出就是一个日志文件。定义一个日志跟踪器当然要定义文件的输出位置以及文件名，然后这个日志跟踪器还有可以被调用的方法。具体到程序上来，这个日志跟踪器就是一个类，在获得这个类实例的时候，要有日志文件的输出路径和文件名（文件名一般是“发生时间+序号”），然后这个类实例当然还有一些方法供调用，类似info、error等方法。具体做的时候，这些info、error的方法可以被抽象成一个接口，然后具体的跟踪器类实现之。日志跟踪器具备了这些特征后就可以被使用了，就可以“注入”到程序的执行过程中。就是在这个过程被触发的时候定义相应的日志跟踪器并在整个执行过程中使用起来，在需要的地方输出日志信息，这些日志信息都会被写到一个对应的文件里。
不同的程序处理过程会有不同的日志跟踪器。因为不同的处理过程，日志的输出位置可能不同，日志文件的命名也可能不同，在对日志文件产生的数目上要求也可以不同。某些处理类型是一个处理过程就需要一个文件，有些可能没有这个必要，而是把所有这个处理类型的日志都记录在一个文件里。
下面举银企接口程序的一个具体实例来说一说。就拿付款指令发送过程来说明。付款指令发送时，银企接口程序会按银行要求组织指令信息发送到银行；发送完后，如果指令状态为中间状态，即不确定状态，程序会接着起一个自动线程查询指令处理状态。这个过程涉及到和银行的交互，也是一个比较敏感的环节。这个环节偶尔会由于某些原因出一些问题，不管是由于银行环境还是网络原因，还是我们程序本身的问题，总之我们需要对这个过程有一个完全的把握，知道这个过程的发生经过，知道问题是怎么发生的。因此我们有必要对这个过程定义一个日志跟踪器。
这个日志跟踪器的文件输出位置是bankservicelog/virement，文件名是“指令发送时间(精确到秒)+序号”，而且要求发送一笔指令就生成一个日志文件。这样在指令发送的开始定义这个日志跟踪器，即获取一个指令发送跟踪器的实例，通过在方法参数传入这个跟踪器实例，在指令发送的整个过程中使用这个跟踪器，包括后续状态查询的自动线程，在有需要的地方调用跟踪器的info或error方法。这样这笔指令的整个发送过程都会被记录在一个文件里，然后可以根据指令的发送时间很快地定位到这个日志文件。
其实退一步来看，这个想法是相当简单的。以前我们日志输出的方式都是统一调Log.info/error，而现在是一个过程一个log实例。前者当然会把所有的日志信息写到一个相同的文件里，而后者则可以一个过程一个文件。只是做了一个小小的改动，但是效果却是如此好！当然不是每类过程都需要输出文件的：）