感谢关注 PHP学习坊 ，文章内容由 PHP学习坊 收集整理，如有错误或者疏漏之处，欢迎在评论区指出，也欢迎大家积极评论转发。小编需要来自你们 订阅 的支持

昨天的介绍PHP操作数据库的文章，被识别为旧闻，没有推荐，好郁闷，今天不讲新东西，介绍一下日志也是小编被怒怼的经历。

此篇番外背景：小编在某知名互联网公司一个成立不到两年的业务线工作，前期由于项目迭代速度过快，好多不规范之处。现在项目趋于稳定，老大开始规范代码，看到日志这一块，老大将十几个壮汉外加一个水灵妹子按在地上一顿怼，这日志简直太糟糕了，不过大家无法反驳，因为人家说得对啊。

于是小编痛定思痛，整理一下日志相关的内容！日志一定要重视起来！日志核心思想： 要让不懂代码的人，通过日志就能看出你要干啥！这就厉害了！

打日志谁不会啊？ 开玩笑~

比写代码简单多了好吗，都有框架，写一行就行了，so easy~

是吗？

1、日志级别

常用日志级别有：

DEBUG < TRACE < NOTICE < WARNING < FATAL

日志级别说明（从低到高）：

日志级别	说明
DEBUG	debug顾名思义为调试级别，打调试信息。// 线下 测试环境 一律开debug；// 线上环境绝不可能开debug；

1. 连接数据库失败，重试也全部失败，打Fatal；

2. 业务代码有一些逻辑分支，理论上业务流程绝不应该走到这里来，打Fatal；

// 对于http服务，若本请求能打出Fatal，通常也就意味着，Http Response的Http Status Code是5**没跑了// 区别于Warning，有时候业务流程无法继续执行，比如缺参数，打的Warning。但同样都是无法继续执行，为啥这里打Fatal呢，可以认为这里的异常，是业务可控的
TRACE	通常用于打出处理流程中的关键步骤日志，用于展示业务运行环节。一个请求打 3~5条TRACE 级别较为合理。// 说通俗一点，对TRACE日志的要求，一个完全没看代码的人（特指QA & OP），能看懂本请求的处理过程，以及每个关键步骤的处理结果

1. 连接数据库失败（可以继续重试），打Warning；

2. 请求入参的参数检查，发现参数异常，比如签名过期/签名校验不一致，比如缺参数，打Warning；

3. 访问Codis失败(包括重试)，降级走Mysql服务继续执行，打Codis访问失败相关Warning；

NOTICE	标识整个请求处理完成，打出结论性日志。一个请求 只打1条NOTICE 级别日志，同时对这条日志的要求是，是只看这一条日志，就能完整知道处理 结果。 // 有的地方也叫INFO级别// 一般情况下，正式线上环境只开NOTICE级别
WARNING	请求处理过程中遇到异常，但仍然可以继续执行，打Warning用于提示运行过程中遇到一点障碍。这里的异常，包括系统异常和业务异常。
FATAL	系统遇到严重故障，无法继续执行。

日志开启说明：

	DEBUG	TRACE	NOTICE	WARNING	FATAL
线下测试环境	☑️	☑️	☑️	☑️	☑️
预发环境		☑️	☑️	☑️	☑️
小流量环境		☑️	☑️	☑️	☑️
线上环境			☑️	☑️	☑️

2、日志输出

DEBUG & TRACE & NOTICE –> ***.log

WARNING & FATAL –> ***.log.wf

3、打日志的意识 & 日志信息量

日志的信息量等同于日志级别~！

要拿出写代码等量的精力，来写高级别的日志，尤其是 warning 和 fatal 级别~！

【常见问题 1】

小明同学打了一手漂亮的NOTICE日志，系统运行一切正常时，皆大欢喜。

一旦遇到系统故障，啥错误信息都没打……

好不容易有一条日志，都是“ *** error happen，please check ”这种没营养的东西……