规范日志来提升系统可维护性

在系统中日志大体可以分为两类，一类是流水日志，另一类是错误日志，对于前一类由于在业务上会有需求，所以设计系统时一般都会考虑，但关于错误记录内容很多情况下都不会纳入设计范围，这样导致我们开发出来的系统可维护性很差，错误日志几乎没有参考价格，甚至误导维护人员。怎样才能输出良好的日志信息呢？我想可以从下面几点入手。

1.分清错误日志的级别

   大家都知道错误日志是分级别的,下面是一些常见的分级与定义。

Level Description Example emergEmergencies - system is unusable."Child cannot open lock file. Exiting"alertAction must be taken immediately."getpwuid: couldn't determine user name from uid"critCritical Conditions."socket: Failed to get a socket, exiting child"errorError conditions."Premature end of script headers"warnWarning conditions."child process 1234 did not exit, sending another SIGHUP"noticeNormal but significant condition."httpd: caught SIGBUS, attempting to dump core in ..."infoInformational."Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..."debugDebug-level messages

"Opening config file ..."

设计这些日志级别是为了方便的对日志进行过滤，如在系统正常运转状态下一般会将日志级别设置为warn，这样当有错误日志时，维护人员会要去关注并分析原因，在查找具体问题时，可能要将日志级别调到debug，希望通过更多的输出信息来定位问题。基本上从debug到emerg日志量应该是递减的。我见过有个系统的日志只输出在debug级别，这样导致在系统运行时只能关闭日志，由于日志量输出太大，无法根据日志迅速判断问题，另一方面频繁的写磁盘也带来性能问题。

2.规范错误日志输出内容

在错误发生时，我们需要考虑输出什么内容，其实这个有个很简单的原则，那就是根据查看日志者的需求，查看日志主要是维护与开发人员，emerg,alert,crit,error,warn这些级别的主要查看者是维护人员，信息的内容要简明扼要，方便运维人员迅速判断并采取措施；notice,info,debug这些级别的主要查看者是开发人员，要提供足够详细且与系统实现逻辑相关的信息，开发人员可以依据来定位代码及数据问题。如果你将堆栈信息输出在crit级别就很不合适，因为这个是给开发人员看的。如果发生了一个warn级别的错误，建议在warn,notice,info,debug级各输出一条相应的信息。