在一个较大的web项目中，大家一般会选择在哪里打日志？

Question

感觉打日志应该有通用的技巧，不知道各位大神对此有何见解？

比如在我看到的项目中，会考虑：

• 调用第三方接口时会打印日志：具体的Request和Response

• 调用组件时候打印具体日志，比如DB、MQ等

Answer 1

这个问题我深有体会.原来项目有做过基于 winston 的 log 系统.
首先一定要明确日志的功能.

• 调试功能，可以方便快速定位和解决问题
• 记录功能,保存系统运行状态
• 分析功能,基于记录的数据进行挖掘,实现系统的优化和升级

首先调试功能,这个需要结合业务逻辑.原则是能够利用 log 快速定位问题
常见的要点包括:

• log 分级别,具体的标准参见 stackoverflow log 级别讨论

• log 分情况

  • 类似一般服务器会把 log 分为 error.log, access.log 这个需要结合你的具体需求
  • 也可在 log 上添加 label ,这样的标志按模块或业务逻辑分,但是这个就不需要分文件了

对于记录功能,在保证了调试的方便性上,尽可能保证数据的有效性及规范化

• 有效性就是记录一些关键参数,比如响应时间等
• 标准化这个在后面分析 log 时会极有价值.

而分析功能是在系统能够长期稳定运行后,通过 log 的数据对系统进行优化

此外还可以利用 log 实现一些自动化功能,例如异常的推送等,关键指标的监控推送等

Answer 2

打印哪些log，楼上已经有很多回答了。还有两点建议：

1. log严格分level，这样方便在debug的时候查询信息，平时log也不至于过大。
2. log最好按照日期或者size自动切分

Answer 3

你考虑的确是的，我增加几点吧!

• 错误异常处理。try{}catch(Exception $e){}。
• crontab定时任务的输出。
• 整个请求的链路上。
• 关键接口的定制。

Answer 4

1.接口出错,抛出异常的时候.

2.邮箱,消息发送失败的时候

Answer 5

1、对外部的调用封装
2、状态变化
3、重要方法的输入和输出
4、业务异常
5、非预期执行（比如删除一条数据，可能成功可能数据本省不存在）
6、很少出现的else情况
7、程序运行时间
8、大批量数据的执行进度

Answer 6

日志宜多不宜少，控制好日志级别就行。
说一下我的一个体会吧：
如果一个业务的处理流程会经过多个处理节点，那么在每个节点的出口和入口都要打印包含该条业务id的日志，业务处理出现异常时，grep一把这条业务的id，就可以定位是哪个节点处理出现异常。

Answer 7

嗯，楼上已经说的比较全面了。
补充一些
1.支付的时候，打log是很有必要的，因为直接涉及到收益，另外，提现一类操作也要打log。
2.对接其他接口的时候，如socket之类
3.对接一些第三方接口的时候，如极光推送等，要确认推送状态
等等吧

Answer 8

写了篇博客，可以来看看——小谈日志与其实践

Answer 9

PHP在高并发的时候，如果日志不严格控制，仅仅log的打印就会消耗掉很多的请求时间、cpu，我们在严格测试代码之后都是每次请求进行一次日志存储，基本都会打印在/data/log或者是/mnt/log 前提是/mnt是挂载的 SSD盘性能相当快！日志一旦收集达到阈值我们就会将日志收集到 elk中，然后通过elk分析日志做出服务上的一些判断和改进

Answer 10

方法的入参处,必要参数(敏感信息加密),同时要把这个方法设计的flow流程的描述要加到前面.如果涉及到远程方法调用,traceId是会一直跟着所有日志输出
在调用其他方法的前后
涉及资金等核心操作的每一步
对于catch里面,可能会error输出一些错误描述,然后throw到最上面,统一打印exception信息

Answer 11

1. 定时任务开始, 结束

2. 调用接口

3. 执行到哪个功能

4. 打印入参, 等关键参数

Answer 12

一般是在调用sql和服务器交互的时候打印日志

Answer 13

我是这样想的..一起讨论...看项目的架构设计打日志的系统..
打在客户端,打在服务端,还是打到分布式系统中..

1. 对日志进行分类,方便快速定位.(可能会出现错误异常并且需要的分析的地方都可以打日志)

2. 如果日志打得比较散,如何把这些日志收集起来.(本地日志,还是构建日志服务)

3. 日志级别(参考这个:链接描述)

4. 是不是要监控日志

至于究竟在哪个点打日志, 就是在基于业务需求上可能会出现异常并分析的地方;比如,支付系统不打日志不行吧?

Answer 14

1. 请求第三方接口之前和之后 因为第三方接口经常会有报错 如果是资源性接口要准备后备接口进行备用兼容
2. 后台运行异步任务之前记录时间和运行结束之后的时间 并且记录消耗的内存 建议使用try/catch运行 这样可以准确监控到是否报错 及报错信息.
3. 后台所有操作都必须有行为记录 记录URL 参数 method 以及请求的用户 可以快速定位具体问题及记录变化 方便回退
4. 敏感sql记录
5. 关键操作重点多步记录日志 比如充值改变用户余额 必要使用事务保证数据一致性及记录详细流程日志及时间
6. 还有就是说下日志储存的时间 最好是$_SERVER['REQUEST_TIME']使用请求时间 这样能更容易找到问题 可以跟nginx日志及其他日志对应 如果一直使用time()获取的话如果程序时间执行过长会不准确,给调试带来麻烦.

Answer 15

另外还有对性能比较关注的逻辑需要加StopWatch日志

Answer 16

其实个人认为日志的打印是一门学问的,打的位置关键不关键,输出的内容必要不必要
见过很多系统的日志,打的很多,看似很全.但是到出现问题的时候,排查错误很难靠日志快速定位.

我自己的习惯可能是:

1. 方法的入参处,必要参数(敏感信息加密),同时要把这个方法设计的flow流程的描述要加到前面.如果涉及到远程方法调用,traceId是会一直跟着所有日志输出
2. 在调用其他方法的前后
3. 涉及资金等核心操作的每一步
4. 对于catch里面,可能会error输出一些错误描述,然后throw到最上面,统一打印exception信息

自己的拙见,还请大家指点

Answer 17

1、日志尽量全，毕竟现在存储成本不高。
2、日志要按日期或者size分，毕竟量大了。
3、日志尽量描述清楚，毕竟打出来来是给你自己看的，如果你自己都不愿意看，还有个鸟用。

Answer 18

setInterval() 结束后最好打个日志，便于发现无限循环的情况。

Answer 19

关于打日志的技巧，上次看到一篇很不错的文章--“最佳日志实践（v2.0）”，可以借鉴下。

Answer 20

我们一般 是 系统web日志 和app 日志两种 是一般的 业务逻辑日志，web是系统日志 如NGINX

Answer 21

支付的时候每一步都打日志。另外系统出现异常时打日志

Answer 22

elasticsearch、logstash、kibana三件套

Answer 23

log分level

Answer 24

参与一个真实的要做 支付的web 项目，比如 P2P项目，把所有坑踩完，日志怎么打，就差不多了

Answer 25

日志是最好的调试工具，还有服务器的错误日志等

Answer 26

正确的时候打不打日志都不重要，只要有异常的地方，最好都打上日志

Answer 27

支持支持支持支持支持支持支持支持支持支持