程序员如何做出优秀的日志

程序员的日常离不开日志，日志就好比私人秘书，负责运行周期一切trace工作。优秀的日志实践能极大帮助地程序员快速定位问题，减少在线错误报警。本文将从日志书写时各方面来做阐述，依据日志推荐的日志等级，做相应优秀日志实践的推荐。

一、重新认识日志

1、日志级别概述

ERROR

ERROR是最高级别错误，反映系统发生了非常严重的故障，无法自动恢复到正常态工作，需要人工介入处理。系统需要将错误相关痕迹以及错误细节记录ERROR日志中，方便后续人工回溯解决。

WARN

WARN是低级别异常日志，反映系统在业务处理时触发了异常流程，但系统可恢复到正常态，下一次业务可以正常执行。但WARN级别问题需要开发人员给予足够关注，往往表示有参数校验问题或者程序逻辑缺陷，当功能逻辑走入异常逻辑时，应该考虑记录WARN日志。

INFO

INFO日志主要记录系统关键信息，旨在保留系统正常工作期间关键运行指标，开发人员可以将初始化系统配置、业务状态变化信息，或者用户业务流程中的核心处理记录到INFO日志中，方便日常运维工作以及错误回溯时上下文场景复现。

DEBUG

DEBUG日志是INFO日志的好帮手，开发人员可以将各类详细信息记录到DEBUG里，起到调试的作用，包括参数信息、调试细节信息、返回值信息等。其它等级不方便显示的信息都可以通过DEBUG日志来记录。

2、记录日志的时机

在看线上日志时，我们可曾陷入到日志泥潭？该出现的日志没有，无用的日志一大堆，或者需要的信息分散在各个角落，特别是遇到紧急的在线bug时，有效的日志被大量无意义的日志信息淹没，焦急且无奈地浪费大量精力查询日志。那什么是记录日志的合适时机呢？

总结几个需要写日志的点：

编程语言提示异常：如今各类主流的编程语言都包括异常机制，业务相关的流行框架有完整的异常模块。这类捕获的异常是系统告知开发人员需要加以关注的，是质量非常高的报错。应当适当记录日志，根据实际结合业务的情况使用WARN或者ERROR级别。

业务流程预期不符：除开平台以及编程语言异常之外，项目代码中结果与期望不符时也是日志场景之一，简单来说所有流程分支都可以加入考虑。取决于开发人员判断能否容忍情形发生。常见的合适场景包括外部参数不正确，数据处理问题导致返回码不在合理范围内等。

系统核心角色，组件关键动作：系统中核心角色触发的业务动作是需要多加关注的，是衡量系统正常运行的重要指标。建议记录INFO级别日志，比如电商系统用户从登录到下单的整个流程；微服务各服务节点交互；核心数据表增删改；核心组件运行等，如果日志频度高或者打印量特别大，可以提炼关键点INFO记录，其余酌情考虑DEBUG级别。

系统初始化：系统或者服务的启动参数。核心模块或者组件初始化过程中往往依赖一些关键配置，根据参数不同会提供不一样的服务。务必在这里记录INFO日志，打印出参数以及启动完成态服务表述。

3、警惕日志性能代价

不管是多么优秀的日志工具，在日志输出时总会对性能产生或多或少的影响，为了将影响降低到最低，有以下几个准则需要遵守：

根本原则：有必要才记录日志，频繁过量日志对性能是有损耗的，并且这种风险不常在系统正常时出现，系统出现问题时大量ERROR、INFO等问题相关日志有可能产生连锁反应，造成严重的后果。将关键信息保存到日志，同时考虑极端场景日志爆发。

Logger获取：根据系统使用的日志框架组合，确定正确的实例获取方式。在log4j的早期版本，一般要求使用static，而在高版本以及后来的slf4j等一些框架封装中，该问题已经得到优化，获取（创建）logger实例的成本已经很低。但对于多例，尤其是需要频繁创建的class，推荐添加static前缀。