应用日志记录规范
2013年03月04日


一、日志分类

1、按等级分类

1)TRACE级、DEBUG级:理论上“不属于错误”,只是打印一些状态、提示信息,以便开发过程中观察,开发完成、正式上线后,要把它们都屏蔽掉。

2)INFO级: 理论上”不属于错误”,只是一些提示性的信息,但是即使在开发完成、正式上线的系统中,也有保留的价值。

3)WARN级:属于轻微的“警告”,程序中出现了一些异常情况,但是影响不大,还可以正常使用。

4)ERROR级:属于“普通的错误”,在程序可以控制的范围内,不会造成连锁影响或巨大影响。

5)FATAL级:属于“致命错误”,可导致整个系统或者一系列功能无法使用,甚至导致系统瘫痪、关闭。

2、按用途分类

a)仅用于开发时调试

b)用于系统正式运行时记录系统状态,以便日后跟踪和检查问题


通常来说,TRACE级、DEBUG级的信息,都是用于调试,在控制台等地方打印即可。所以严格的说,它不属于日志记录的范畴。那么真正的日志,主要是INFO、WARN、ERROR、FATAL级别的信息。


二、日志处理常见问题

1、多次重复记录

    比如在DAO层记录了异常堆栈信息,然后抛出异常,在web层catch了异常之后,又记录了一次异常堆栈信息。

2、滥用日志、记录不够精简、大量无用信息。

    大量的内容都记录到日志中,使得要从日志中查找关键信息如同大海捞针。更有甚者,频繁大量打印日志,使得日志文件超过100G、500G直到磁盘容量爆满,服务器挂掉。

3、缺乏关键标识,很难定位某条信息的位置

    比如,前端web页面报错,告诉开发人员去查找问题,开发人员很难去查找当时的操作日志或者异常信息。仅仅根据时间来定位往往是不够的。


三、日志处理最佳实践

1、在日志信息上添加便于检阅、查找的额外标识

    这种用于检阅和查找的标识,包括:日期和时间,程序Java类的名称、方法甚至行号,错误类型或者错误代码。

    例如,把错误信息附加一个错误代码,登录失败的错误代码是 USE002,则可以根据这个标识,去日志数据中去进行统计,再根据错误的日期和时间,就可以定位具体的日志跟踪信息,从而找出登录失败的原因。对于未知异常,可以定义一个唯一的异常代码,比如 S8deD8,用户在页面上操作失败时,可以得到这个错误代码,他把这个错误代码截图给开发人员,开发人员就可以根据这个错误代码在日志中直接去检索到错误信息(这个错误代码是唯一的,所以定位起来非常方便)。


2、不滥用日志,关注日志记录的正确性和必要性

    分清楚什么时候应该记录日志,什么时候不需要记录日志。什么是TRACE、DEBUG信息,什么是INFO、ERROR信息。对于异常处理,不要多次重复的记录同一个异常的堆栈信息。


3、关注日志记录对于系统性能、安全性的影响

    日志记录是否太过于频繁,日志记录到文件IO或者数据库都是很费CPU和内存资源的事,是否会对系统的性能产生影响。日志是否会被恶意攻击频繁打印日志,直到日志文件塞满主机磁盘。