在系统开发中，我们把日志分为两大类，业务类和系统类。
一 业务类日志
业务类是指和业务相关的日志，一般常用的有用户登录，用来记录用户的登录历史，关心的字段一般有用户ID、登录时间、IP等；操作流程信息，这是一类十分重要的日志信息，对于量化交易系统来讲，整个交易过程应该就是最重要的业务流程，包括每日出票、开盘、信号、仓位计算、止盈止损等等各个细节都应该有比较详细的日志记录，确保所有节点都有数据可以回溯。不但能够为发现问题提供线索，也可以为日后策略的优化提供数据基础。
二 系统类日记
系统类日志，就是和系统运行相关的日志，一般包括调试日志、错误日志、性能日志和运行日志。调试日志是一般是在系统开发和试运行阶段的日志记录，这类日志一般会记录的十分详细，比如方法的调用关系、各种参数、主要变量等；它们一般会占用大量的硬盘空间，而一旦系统正式上线后，这类调试信息都会被关掉，因为系统稳定运行以后，这些观察窗口也失去了意义。但是为了调试方便，需要有比较方便的开关可以随时开启调试日志。
错误日志，有时候也称为异常日志，记录的是系统运行过程中发生的意外情况。即使在测试时再鲁棒的系统，也难免会在运行过程中碰到意外情况而发生异常，这个时候，我们就要详细记录发生异常的现场情况，有点像警察破案要求的对案发现场的保护和还原，这将是修复问题的重要线索，一般需要记录的包括调用堆栈、错误信息内容、相关参数。提到错误日志，有一点大家要分清楚，在业务的处理过程中，也会产生一些错误信息，比如登录时的用户名密码错误、用户提交的委托单超过了当日的价格范围，我们一般把这类信息正常的业务逻辑，因为从开发的角度来看，我们并不需要对它们作为任何特殊处理，只需要完整的报给用户，让用户决定下一步的操作即可。
性能日志，顾名思义是用来记录系统性能的日志。一般情况下在系统运行初期，都不存在性能问题，可是随着时间的推移，系统规模会不断扩大，那么性能瓶颈就会慢慢凸显，这个时候性能日志就派上用场了。通过分析性能日志中的信息，可以准确定位耗时、耗资源的代码，实现精确打击。最后一个是一般运行日志，这类日志一般是为了监控系统的健康状况而记录的，记录的位置是多数是系统的关键模块。
三 实例讲解
我们现在看到的就是一条登录日志，内容比较容易理解，首先是精确到毫秒的时间字段，2017年12月22号的下午六点22分33秒，575毫秒。在接着是线程信息，基本上不太有用，也可以不做记录。再接着是用户ID，一般是数字，后面是nick，也就是昵称，有了ID，为什么我们还要记录昵称，因为对于人来讲，名字看起来比数字类型的ID更直观，后续如果分析问题时，会更加有帮助。再接着是IP地址，一般是做来源统计时使用。接着是referer，也就是来源网址。这几个字段基本涵盖了和用户登录业务相关的重要信息。
现在我们看下从回测过程中摘出来的几条日志，看看到底都记录了什么信息。首先我们第一条日志账户复权处理的日志，如果大家还有印象，在前面我们提到过回测过程中，模拟的资金账户每天会对持仓股做复权处理，那么这条日志就是在这个时候产生的。从这条日志可以知道，资金账户50119下所有持仓股在2013-03-07上这一条都没有发生除权除息的操作，对应到代码上就是复权因子没有发生变化。接下来看到是买入的两条日志，我们先看第一条。首先是日志生成的时间，然后回测的ID，接着是股票代码，然后是买入时间，买入价格，买入原因，这里的买入原因是发生了30分钟级别的kd信号。然后计算得出的可买入数量，这里12是手数，也就是1200股。最后是给出当日是否为涨停，显然这里是没有涨停。根据前面我们系统模块的划分，这条信息应该是产自交易决策模块。再来看第二条，我们就不再逐一对字段进行说明了，因为这条日志十分明了，也就是说可用资金不足以买入一手002294这只股票，所以由于可用资金不足，无法买入。
未完待续... ...
好了，本次的话题要分多期呈现，今天的内容就讲到这里，希望对你所有帮助！