日志的粒度请教?

[chaleaochexist]

不会打 log.
不知道哪些地方需要打 log.

目前的情况是总是丢 log.
线上的一些随机问题不知道是哪些地方引起的.

但是 log 太细,又觉得不太合适吧?

请教最佳实践.谢谢.

[VANHOR]

看看楼下怎么说

[maemual]

当遇到问题的时候你想知道哪些信息有助于你解决问题

[lihongjie0209]

遇到问题就加上, 加多了就有经验了

[jsjscool]

第三方的接口调用要打，服务的输入输出要打，其他的能不打就不打。写日志是帮助自己用最少的字符得到最有用的结论。

[arrow8899]

只在关键的地方记日志，服务调用请求和响应记日志，这样出现问题可以根据代码一步一步复现。

[mushishi]

## 场景 1. 判断程序中关键方法是否进入与正常退出。
3. 固定：类名+方法名+start+关键参数用于过虑日志

## 场景 2：判断关键方法内部逻辑是否正常进入和退出。
2. 固定：类名+方法名+逻辑主要功能名+start/end+关键参数用于过虑日志

## 场景 3：判断程序异常执行关键日志，及异常输出，如果是符合预期的异常捕获可以使用 wran 级别代替 error。
1. 固定：类名+方法名+[逻辑主要功能名]+got exception error+[关键参数用于过虑日志]+e.getMessage []中括号中的信息代码位置视情况需不需要加

[mushishi]

@mushishi 我们团队内部暂时使用的日志规范

[pkookp8]

用等级区分，不重要的或只是协助看流程的 debug 或 trace
出了问题用于快速定位问题区间的 info
意料外的但是能处理的 warn
无法恢复或不能简单处理的，error 或 critical
外部封装，内部 if 或 switchcase，一句判断条件语句不影响性能(影响的地方用 flag 或 count 记录，别的线程定时输出)

[stevenkang]

总结了以下几点：

1、API 的 I/O 日志，也就是请求参数和响应内容记录日志，这相当于整个系统的大门了，访问日志在排错、性能分析等方面非常有用；

2、第三方 API 的 I/O 日志，也就是请求第三方 API 发送了哪些参数，第三方 API 又响应了哪些参数，这有利于分析传递的数据是否正确；

3、异常块，所有捕获异常的位置均应当记录异常内容，除非一些用于业务逻辑判断的异常块（例如：利用异常来判断某个字符串是否能转换等）；

4、非正常请求，例如请求某个 API 报了 403，应当记录 >= WARN 级别的日志，这里和 #1 的区别是，#1 无论正常还是异常均记录请求、响应内容，这里的应当记录更加详细的内容，例如为什么会产生 403 响应，并且日志级别应当更高，方便分析、优化；

5、应用启停日志，在启动应用进行初始化时，应当记录各个参数的情况，便于在启动时遇到问题进行定位。同理，在应用停止的时候（特别是异常停止），应当记录详细的运行状况、运行参数等日志；

6、其他日志，根据实际业务情况需要，应当记录其他日志，例如调用短信接口时记录短信用量、剩余量等，这样可以通过编写日志报警规则来实现短信余额不足预警功能；

[jatsz]

这个是个好问题，我在自己的一篇博客中总结过： https://www.imzjy.com/blog/2018-07-06-writing-good-log

通常下面的情况可以考虑加一行日志：

- 程序的参数检查一下，函数输入决定输出，输入都不对，输出怎么可能对呢？
- 第三方回传的时候检查一下，返回数据了么，返回大小是多少，调用时间用了多少？
- 关键业务点，留下点脚印，打一些 Info 类的日志。
- 有副作用的函数，比如操作网络，操作磁盘，数据库操作，有时候越是难的 bug，越是这些觉得不可能出错的地方出错。
- 应用程序启动相关的，比如加载的模块，影响行为的配置文件，环境变量，等等。
- 数据驱动着应用，常常 bug 在数据中。加一些日志在已有的数据上，即使不记录具体内容，也要记一下大小。
- 别在同一个地方跌倒两次。抓到一个 bug，或者业务漏洞修复，写个测试区覆盖或许很难，但是记一行日志不费多少电。

[bulbzz]

你觉得有问题的地方加上就可以了 粒度是可以准确定位出问题所在。

[bravoer]

打日志，一定要注意要形成一个完整的链，从开始到结束，让别人从你的日志中就可以整天程序运行的整个流程，完整清晰的流程一般是一个流程图，分支进入什么的都要考虑到，整个流程一般使用 info，异常使用 error，用于调式什么的，使用 trace 或者 debug。

你需要明确一点就是，打日志的作用在哪。你就知道怎么打了。