感谢关注 PHP学习坊 ，文章内容由 PHP学习坊 收集整理，如有错误或者疏漏之处，欢迎在评论区指出，也欢迎大家积极评论转发。小编需要来自你们 订阅 的支持
昨天的介绍PHP操作数据库的文章，被识别为旧闻，没有推荐，好郁闷，今天不讲新东西，介绍一下日志也是小编被怒怼的经历。
此篇番外背景：小编在某知名互联网公司一个成立不到两年的业务线工作，前期由于项目迭代速度过快，好多不规范之处。现在项目趋于稳定，老大开始规范代码，看到日志这一块，老大将十几个壮汉外加一个水灵妹子按在地上一顿怼，这日志简直太糟糕了，不过大家无法反驳，因为人家说得对啊。
于是小编痛定思痛，整理一下日志相关的内容！日志一定要重视起来！日志核心思想： 要让不懂代码的人，通过日志就能看出你要干啥！这就厉害了！
打日志谁不会啊？ 开玩笑~
比写代码简单多了好吗，都有框架，写一行就行了，so easy~
是吗？
1、日志级别
常用日志级别有：
DEBUG < TRACE < NOTICE < WARNING < FATAL
日志级别说明（从低到高）：
| 日志级别 | 说明 |
|---|---|
| DEBUG | debug顾名思义为调试级别，打调试信息。// 线下 测试环境 一律开debug；// 线上环境绝不可能开debug； |
连接数据库失败，重试也全部失败，打Fatal；
业务代码有一些逻辑分支，理论上业务流程绝不应该走到这里来，打Fatal；
| // 对于http服务，若本请求能打出Fatal，通常也就意味着，Http Response的Http Status Code是5**没跑了// 区别于Warning，有时候业务流程无法继续执行，比如缺参数，打的Warning。但同样都是无法继续执行，为啥这里打Fatal呢，可以认为这里的异常，是业务可控的 | |
| TRACE | 通常用于打出处理流程中的关键步骤日志，用于展示业务运行环节。一个请求打 3~5条TRACE 级别较为合理。// 说通俗一点，对TRACE日志的要求，一个完全没看代码的人（特指QA & OP），能看懂本请求的处理过程，以及每个关键步骤的处理结果 |
连接数据库失败（可以继续重试），打Warning；
请求入参的参数检查，发现参数异常，比如签名过期/签名校验不一致，比如缺参数，打Warning；
访问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 ”这种没营养的东西……
