首先，要明确为什么要保留日志，有了清晰的价值目标，就是有了统一的行动纲领。
如同记账本，记录每天开销，以备日后查阅统计。
记录系统日志，可以帮助我们记录应用每时每刻的运行情况，方便系统在产生故障时快速定位问题；
以及更进一步，把零散的日志收集起来，数据量大了，就能发现日志数据的规律和价值。
- 日志分级
- 日志分类
- 日志落盘
还是拿记账举例：
大额支出，如买房买车；小额支出，如买菜买彩票。支出额度不同，意义不同。日志也一样，「debug」、「warn」和「error」等不同的分级信息也具有不同的意义。
日常生活类支出，读书学习类支出，通过分门别类，可以统计钱都花在哪方面了。同理，我们也要分门别类统计应用程序的行为，记录不同模块的日志，以便从不同维度分析日志。
我们可以用纸质笔记本记录账单，也可以通过电子设备记录每一笔支出，方便统计分析。系统日志更要如此，可以直接输出到终端，可以写入到文本文件，或者持久化到数据库中。
如下图，这是一个分级比较全面的设计，覆盖了几乎所有场景，具体到知乎业务我们可以有所舍弃或保留。
日志级别越低，输出的信息量越大；日志级别越高，输出的信息量越小。
在不同的环境使用不同等级的日志，比如在生产环境避免使用「debug」级别的日志，以防泄露敏感信息。
通常我们打印「info」级别日志，记得常规用户行为，如登录/查看更新资料/其他业务访问的 log 等。
- 「info」级别以下的使用
在开发过程中可以使用「debug」级别去打印程序内部信息，比如打印一些中间变量的值，打印中间处理状态等等。
对于「trace」级别的日志，这个比较低级别，通常用来本地跟踪代码的执行的详细信息。在服务端，服务器上运行的程序通常不会开启，因为日志量会很大。
对于「all」级别很少使用，可以根据情况自己定义，很多时候用到「trace」级别就很够信息量了。
- 对于「info」以上的高日志级别
「error」级别：顾名思义就是，程序错误，这个可以用来打印错误数据，错误请求的事件信息，我们经常会在 catch 代码块中以「error」级别来记录此类异常。
分类比级别更为灵活，为日志了提供了第二个区分的维度。
例如，你可以为不同模块设置不同的分类，比如在 app1 中记录为「fromApp1」，这样就可以区分日志来源于哪个模块。
「日志分级」相当于在纵深层面对日志进行划分，「日志分类」相当于在横向维度对日志进行划分。
好了，现在日志有了级别和类别，解决了日志在入口处定级和分类问题。
下面就要考虑日志的出口问题（即日志输出到哪里）。
一图胜千言：
根据业务需要，可以考虑不同的落盘方式。常规做法一般会输出到文本文件中，或者持久化到数据库中方便分析。
在落盘的过程中，除了考虑输出到哪里的问题，还需要考虑如何输出的问题，如：
- 日志格式化功能
- 基本格式化功能
- 用户自定义格式化功能
- 日志过滤功能
- 输出哪些级别的日志
- 输出哪些类别的日志
- 日志切分功能
- 按时间切分
- 按体积切分
等等…
总之，一个完整的日志方案包括方方面面，以上只是参照主流日志库做出的分析概括。
从一个合乎逻辑的框架下出发，到具体实现过程中根据业务需要去量身定做，产出**实践。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/201547.html