一、日志分类

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和内存资源的事，是否会对系统的性能产生影响。日志是否会被恶意攻击频繁打印日志，直到日志文件塞满主机磁盘。