这是一个创建于 1232 天前的主题，其中的信息可能已经有所发展或是发生改变。
日志内容
不讨论针对用户行为的埋点日志，仅讨论业务日志。
待过两家公司，完全不同的日志策略：前者是内容平台（也是创业公司），基本上能不打日志就不打，只打一些异常日志；后者是交易平台，基本上所有用户请求都要 trace，每个请求参数，返回值的关键信息，除了集合类型的数据，其他数据都是尽量落日志了。
我总结了下，前者因为是内容平台，内容多寡、精不精确，对用户其实没有承诺（当然用户会用脚投票），真有问题就让用户重新操作下就可以了；而后者因为涉及到交易，需要对交易链条上的每个环节负责到底，无论是因为用户操作不当还是系统问题都需要给出合理的解释。前者没有一个客服，后者一大帮客服。前者平台跟用户是互利的（流量换内容），后者用户是平台爸爸。
思考：用户对产品的认知有差异，产品越简单，这种差异越小，就越不需要客服，也就越不需要日志。减少日志的办法可能还是简化产品逻辑，使之符合更多人的预期。
日志级别
正常业务流程 info，业务异常 warn （可能是参数不对或者不能满足一些业务条件之类的），这两种都属于正常情况，ret=0,表示结果是可用的，前端可以直接展示给用户。业务异常不能打 error，否则会有大量报警。
只有系统异常（如超时）才打 error，ret 不等于 0，表示结果不可用，前端可以根据 errorcode 判断是要重试还是怎么处理。这种异常会报警，可以标识服务的状态。
errorcode 也是一个值得讨论的话题，不过这贴先不讨论了。
不知道 XDM 在项目中是如何实践的，欢迎分享讨论
第 1 条附言 · 2021-08-13 18:14:24 +08:00
日志的作用之一是极大地降低了与用户的沟通成本
 |
1
chendy 2021-08-13 17:51:24 +08:00  3
个人倾向是多打日志，多打日志最多导致需要更多的磁盘空间保存日志，但是用户遇到问题咨询甚至投诉的时候找不到日志才是真的要命
|
 |
2
raaaaaar 2021-08-13 18:58:48 +08:00
磁盘成本又不高
|
 |
4
guodong110 2021-08-13 21:05:53 +08:00
打出入口日志，中间业务逻辑看需求，有必要就打
|
 |
5
wangbenjun5 2021-08-13 21:34:48 +08:00
讲个实话，有些菜鸡喜欢一行一个日志，好像日志没有开销一样，个人感觉业务日志开发调试的时候可以打点，基本上稳定之后能删就删，真正有自信的人不用打日志，要打也是打关键地方。
|
 |
6
yitingbai 2021-08-13 22:02:04 +08:00
我跟你说微信 app 怎么打的吧, 我反编译看过, 他们在编译的时候, 给每个函数头部和尾部都插入了代码, 方便知道函数的调用链, 排查问题更方便. 日志千万不要省, 除非调用非常频繁的函数, 日志可以省点, 其他函数, 日志能多久多, 能详细就详细
|
 |
7
pengtdyd 2021-08-13 22:41:14 +08:00
日志太多,给运维带来困难,上线之后不应该出现 info 日志才对
|
|
9
pengtdyd 2021-08-13 23:10:11 +08:00
@GM 如果日志过多,如何从海量日志里面定位问题,日志如何存储,如何维护,保存多久等等一系列的问题就出现了,我觉得这些本身应该可以通过全链路压测解决
|
 |
11
GM 2021-08-14 00:18:23 +08:00
@pengtdyd 定位问题有办法的，每个请求进来先分配一个 requestId，之后所有这次请求相关的日志都带上这个 requestId，排查问题简直不要太方便。我公司现在就是保存全链路详细日志，日志保留 30 天，也就大约 100G 左右，一个月成本几十块钱，非常划算。
|
 |
12
witcherhope 2021-08-14 00:22:33 +08:00 via iPhone
日志太多和太少本质是同一个问题
|
 |
13
sujin190 2021-08-14 00:23:53 +08:00 1
我觉得楼主似乎混淆了，我们一般说的日志都是运行日志，这个只是监测、异常报告用的，所以一般打核心点和异常栈就行了，后面交易这个应该算业务日志，本身就是支付系统业务流程的一部分，认真说把运行日志和业务日志打在一起时极其傻叉的行为，本来两者的用途就不一样，其它的还有链路追踪用的，调试分析用的等等，每一种各有不同，也不需要同时启用所有日志，打日志的侧重点也不一样，保存周期可能也不同，本身就不应该混在一起打
|
 |
14
IvanLi127 2021-08-14 00:25:53 +08:00 via Android
我觉得，尽量在性能允许的范围内多打些日志。日志按级别分类存，然后低级别的日志存的时间短些。
|
|
15
IvanLi127 2021-08-14 00:28:01 +08:00 via Android
另外，楼主说的交易平台里的日志，应该是类似操作留痕之类的东西，和另一个项目的日志本质上不是同一个东西嘞
|
 |
16
nuk 2021-08-14 00:49:11 +08:00
当系统被入侵后或者有用户利用业务漏洞，日志的宝贵就体现出来了
|
 |
17
Sparkli 2021-08-14 00:54:22 +08:00
我有个想法啊，是不是日志的三个级别 Info 、Warm 、Error 可以通过冷温热进行分级存储呢？类似于 ES 策略，这样兼具存储成本和排查效率二者优点
|
 |
18
xuanbg 2021-08-14 06:18:42 +08:00
日志不是越多越好，而是越精准越好。精准的定义就是不需要的 1 条都没有，需要的 1 条都不少。
|
 |
19
chenshun00 2021-08-14 08:37:56 +08:00
@GM 30 天 100G 么，要是日志量翻个 20 倍，30 倍呢。
|
 |
21
coolloves 2021-08-14 13:30:38 +08:00
如果是性能日志或者程序的运行日志,当然是看大爷您心情了,只要你别出问题或者出问题了能快速定位.
但是如果是业务日志,还是要根据业务 /产品需求吧,别到时候客户要查自己啥时候登陆过,啥时候做个 xx 操作,你这边一脸糟比 |
 |
22
kongkongyzt 2021-08-14 13:39:55 +08:00
两种打日志的策略我都经历过, 我个人是觉得能多打日志的话就多打吧, 不然到时候追踪问题的时候就很麻烦了, 尤其是对方是惹不起的大客户的时候
|
|
23
GM 2021-08-14 15:14:18 +08:00 1
@chenshun00
算你翻 100 倍，又如何？ 1000 倍我更开心，说明有大量业务，花钱买就是了。 |
 |
24
zu1y 2021-08-15 00:43:41 +08:00
我们这网关一台服务器每小时打 500G 左右日志，也只打了出入参。。
挂了 4T 的硬盘，搞了个 crontab 每小时 zip 后转到 nfs 上去。。 虽说硬盘这玩意确实不值钱，但每天这上百 T 的日志也不是个事，量太大也不好搞 ELK 里去查。很是🥚疼 但应该是监管部门对这玩意有要求，需要至少保存 6 个月？ |
 |
25
PolarBears 2021-08-15 03:00:09 +08:00
@zu1y 虽然监管部门有要求要 6 个月,但没要求日志要详细到什么程度
|
 |
26
darknoll 2021-08-15 19:25:32 +08:00
我就不想打太多日志了，客户出问题我直接连对方调试呗
|
Select Language