程序员怎样做出优秀的日志1、日志的级别一定要搞清楚
ERROR
ERROR是最高级别错误，反映系统发生了非常严重的故障，无法自动恢复到正常态工作，需要人工介入处理。系统需要将错误相关痕迹以及错误细节记录ERROR日志中，方便后续人工回溯解决。
WARN
WARN是低级别异常日志，反映系统在业务处理时触发了异常流程，但系统可恢复到正常态，下一次业务可以正常执行。但WARN级别问题需要开发人员给予足够关注，往往表示有参数校验问题或者程序逻辑缺陷，当功能逻辑走入异常逻辑时，应该考虑记录WARN日志。
INFO
INFO日志主要记录系统关键信息，旨在保留系统正常工作期间关键运行指标，开发人员可以将初始化系统配置、业务状态变化信息，或者用户业务流程中的核心处理记录到INFO日志中，方便日常运维工作以及错误回溯时上下文场景复现。
DEBUG
DEBUG日志是INFO日志的好帮手，开发人员可以将各类详细信息记录到DEBUG里，起到调试的作用，包括参数信息、调试细节信息、返回值信息等。其它等级不方便显示的信息都可以通过DEBUG日志来记录。
2、记录日志的时机，一定要仔细考量
在排除故障的时候，该要出现的日志没有，无用的日志一大堆，或者需要的信息分散在各个角落，特别是遇到紧急的在线bug时，有效的日志被大量无意义的日志信息淹没，焦急且无奈地浪费大量精力查询日志。那什么是记录日志的合适时机呢？
当方法或者功能处理过程中产生不符合预期结果或者有框架报错时可以考虑使用，常见问题处理方法包括：
“增加判断处理逻辑，尝试本地解决抛出异常，交给上层逻辑解决记录日志，报警提醒使用返回码包装错误做返回”
DEBUG级别。系统初始化：系统或者服务的启动参数。核心模块或者组件初始化过程中往往依赖一些关键配置，根据参数不同会提供不一样的服务。务必在这里记录INFO日志，打印出参数以及启动完成态服务表述。
编程语言提示异常：如今各类主流的编程语言都包括异常机制，业务相关的流行框架有完整的异常模块。这类捕获的异常是系统告知开发人员需要加以关注的，是质量非常高的报错。应当适当记录日志，根据实际结合业务的情况使用WARN或者ERROR级别。
业务流程预期不符：除开平台以及编程语言异常之外，项目代码中结果与期望不符时也是日志场景之一，简单来说所有流程分支都可以加入考虑。取决于开发人员判断能否容忍情形发生。常见的合适场景包括外部参数不正确，数据处理问题导致返回码不在合理范围内等。
系统核心角色，组件关键动作：系统中核心角色触发的业务动作是需要多加关注的，是衡量系统正常运行的重要指标。建议记录INFO级别日志，比如电商系统用户从登录到下单的整个流程；微服务各服务节点交互；核心数据表增删改；核心组件运行等，如果日志频度高或者打印量特别大，可以提炼关键点INFO记录，其余酌情考虑
3、日志也会消耗性能，要牢记性能意识，不要随意浪费资源
所有的日志工具，在日志输出时总会对性能产生或多或少的影响，为了将影响降低到最低，有以下几个准则需要遵守：
根本原则：有必要才记录日志，频繁过量日志对性能是有损耗的，并且这种风险不常在系统正常时出现，系统出现问题时大量ERROR、INFO等问题相关日志有可能产生连锁反应，造成严重的后果。将关键信息保存到日志，同时考虑极端场景日志爆发。
Logger获取：根据系统使用的日志框架组合，确定正确的实例获取方式。在log4j的早期版本，一般要求使用static，而在高版本以及后来的slf4j等一些框架封装中，该问题已经得到优化，获取（创建）logger实例的成本已经很低。但对于多例，尤其是需要频繁创建的class，推荐添加static前缀。
输出等级校验：在log4j1.x版本，对于可以预见的会频繁产生的日志输出，先判断一下(logger.isXXXEnabled()，对于性能有很大提升，在其它外观框架或者log4j2.x中已经自动实现。输出格式：禁止使用字符串拼接，使用参数方式。样式配置：布局配置输出的信息也会影响到性能，需要根据logger的具体使用场景来选择输出合适信息。
核心都是减少日志量，前两点偏向设计，后四点偏向日志框架及习惯，并且这四点目前一些框架组合已经能帮开发人员减少不少工作，比如log4j2.x在实例获取，输出等级判断都有优化。