其实，在实际开发中，每个软件都有自己的日志系统，每种语言都有自己的日志框架/模块，随着互联网和大数据的蓬勃发展，分布式的日志系统，以及日志分析系统也应用的越来越广泛，越来越成熟。

从以下几方面深入日志设计

第一，谁在使用日志

有一个问题，可能很多开发人员并没有认真思考过，就是日志到底是给谁用的？用户，运维，开发人员，软件学习爱好者？当然，答案是全部。

第二，不同的角色，有不同的视角，在不同的阶段，有不同的需求，那么日志就应该提供不同的帮助。在做日志模块的内容设计时，也应该站在不同的角度去考虑，要思维清晰，哪些信息给用户看，哪些给运维人员看，哪些给程序员看。要讲究轻重主次，不是说详细就一定好。

第三，日志的等级

开发过一些系统，大体的感受是这样的：刚开始的时候，大家都相对比较讲究，日志的等级、内容、位置都会去思考、选择。但是随着时间不断的延伸，功能不断的扩展，日志逐渐变的混乱，最终沦落为乱麻一片！

日志通常有多个等级，等级并不单单指“详细程度”，还关系到适用场景，服务对象，目的功能等。

第四，日志使用的几种场景

1）开发过程中：

日志是一种友好、强大的记录软件运行时内部结构和状态的工具，是调试利器，当然每种语言都会提供专门的调试工具，比如c/c++gdb，java的jdb等等。但是涉及到业务逻辑，并发，交互等情况时，还是日志更轻巧、便捷！我一般是在对“陌生”代码（比如开源软件）学习时，才会用gdb等调试工具，强大但笨重，更适合梳理代码结构，而不是功能或业务结构!

2）测试过程中：

在进行功能测试时，通过debug或trace信息，就像看监控回放一样，让犯罪分子无处遁行！

3）软件学习时：

学习软件时，包括软件的架构设计、业务功能、代码逻辑，日志总能提供很多线索、很多帮助。记得很久以前，看某个开源系统的代码，部署完以后，直接打开trace跑一边，系统的整体结构及内容，一目了然，再结合设计文档，很快就没明白了！就那一刻，让我深刻的记住，好的日志系统，原来是这么的神奇啊!

4）正常运行：

一定不要开着debug跑系统，没有意义！前提是，ERROR信息要准确、规范，客户只关系生死问题，再多的信息对他们也没有意义！