日志到底应该怎么打

[ljzxloaf]

日志内容

不讨论针对用户行为的埋点日志，仅讨论业务日志。

待过两家公司，完全不同的日志策略：前者是内容平台（也是创业公司），基本上能不打日志就不打，只打一些异常日志；后者是交易平台，基本上所有用户请求都要 trace，每个请求参数，返回值的关键信息，除了集合类型的数据，其他数据都是尽量落日志了。

我总结了下，前者因为是内容平台，内容多寡、精不精确，对用户其实没有承诺（当然用户会用脚投票），真有问题就让用户重新操作下就可以了；而后者因为涉及到交易，需要对交易链条上的每个环节负责到底，无论是因为用户操作不当还是系统问题都需要给出合理的解释。前者没有一个客服，后者一大帮客服。前者平台跟用户是互利的（流量换内容），后者用户是平台爸爸。

思考：用户对产品的认知有差异，产品越简单，这种差异越小，就越不需要客服，也就越不需要日志。减少日志的办法可能还是简化产品逻辑，使之符合更多人的预期。

日志级别

正常业务流程 info，业务异常 warn （可能是参数不对或者不能满足一些业务条件之类的），这两种都属于正常情况，ret=0,表示结果是可用的，前端可以直接展示给用户。业务异常不能打 error，否则会有大量报警。

只有系统异常（如超时）才打 error，ret 不等于 0，表示结果不可用，前端可以根据 errorcode 判断是要重试还是怎么处理。这种异常会报警，可以标识服务的状态。

errorcode 也是一个值得讨论的话题，不过这贴先不讨论了。

不知道 XDM 在项目中是如何实践的，欢迎分享讨论

日志的作用之一是极大地降低了与用户的沟通成本

[chendy]

个人倾向是多打日志，多打日志最多导致需要更多的磁盘空间保存日志，但是用户遇到问题咨询甚至投诉的时候找不到日志才是真的要命

[raaaaaar]

磁盘成本又不高

[delectate]

@raaaaaar 张小🐉点了个赞，下一个版本，微信又多占了 50g 的 rom 空间。

[guodong110]

打出入口日志，中间业务逻辑看需求，有必要就打

[wangbenjun5]

讲个实话，有些菜鸡喜欢一行一个日志，好像日志没有开销一样，个人感觉业务日志开发调试的时候可以打点，基本上稳定之后能删就删，真正有自信的人不用打日志，要打也是打关键地方。

[yitingbai]

我跟你说微信 app 怎么打的吧, 我反编译看过, 他们在编译的时候, 给每个函数头部和尾部都插入了代码, 方便知道函数的调用链, 排查问题更方便. 日志千万不要省, 除非调用非常频繁的函数, 日志可以省点, 其他函数, 日志能多久多, 能详细就详细

[pengtdyd]

日志太多,给运维带来困难,上线之后不应该出现 info 日志才对

[GM]

@pengtdyd 一旦系统出问题有交易失败，你查日志又找不到任何错误信息的时候，你就知道抓狂了

[pengtdyd]

@GM 如果日志过多,如何从海量日志里面定位问题,日志如何存储,如何维护,保存多久等等一系列的问题就出现了,我觉得这些本身应该可以通过全链路压测解决

[chendy]

@pengtdyd 日志要有，链路跟踪也要有，两者不冲突

[GM]

@pengtdyd 定位问题有办法的，每个请求进来先分配一个 requestId，之后所有这次请求相关的日志都带上这个 requestId，排查问题简直不要太方便。我公司现在就是保存全链路详细日志，日志保留 30 天，也就大约 100G 左右，一个月成本几十块钱，非常划算。

[witcherhope]

日志太多和太少本质是同一个问题

[sujin190]

我觉得楼主似乎混淆了，我们一般说的日志都是运行日志，这个只是监测、异常报告用的，所以一般打核心点和异常栈就行了，后面交易这个应该算业务日志，本身就是支付系统业务流程的一部分，认真说把运行日志和业务日志打在一起时极其傻叉的行为，本来两者的用途就不一样，其它的还有链路追踪用的，调试分析用的等等，每一种各有不同，也不需要同时启用所有日志，打日志的侧重点也不一样，保存周期可能也不同，本身就不应该混在一起打

[IvanLi127]

我觉得，尽量在性能允许的范围内多打些日志。日志按级别分类存，然后低级别的日志存的时间短些。

[IvanLi127]

另外，楼主说的交易平台里的日志，应该是类似操作留痕之类的东西，和另一个项目的日志本质上不是同一个东西嘞

[nuk]

当系统被入侵后或者有用户利用业务漏洞，日志的宝贵就体现出来了

[Sparkli]

我有个想法啊，是不是日志的三个级别 Info 、Warm 、Error 可以通过冷温热进行分级存储呢？类似于 ES 策略，这样兼具存储成本和排查效率二者优点

[xuanbg]

日志不是越多越好，而是越精准越好。精准的定义就是不需要的 1 条都没有，需要的 1 条都不少。

[chenshun00]

@GM 30 天 100G 么，要是日志量翻个 20 倍，30 倍呢。

[ruanimal]

@delectate 日志又不是都打本地，基本上是上报的

[coolloves]

如果是性能日志或者程序的运行日志,当然是看大爷您心情了,只要你别出问题或者出问题了能快速定位.
但是如果是业务日志,还是要根据业务 /产品需求吧,别到时候客户要查自己啥时候登陆过,啥时候做个 xx 操作,你这边一脸糟比

[kongkongyzt]

两种打日志的策略我都经历过, 我个人是觉得能多打日志的话就多打吧, 不然到时候追踪问题的时候就很麻烦了, 尤其是对方是惹不起的大客户的时候

[GM]

@chenshun00
算你翻 100 倍，又如何？ 1000 倍我更开心，说明有大量业务，花钱买就是了。

[zu1y]

我们这网关一台服务器每小时打 500G 左右日志，也只打了出入参。。

挂了 4T 的硬盘，搞了个 crontab 每小时 zip 后转到 nfs 上去。。

虽说硬盘这玩意确实不值钱，但每天这上百 T 的日志也不是个事，量太大也不好搞 ELK 里去查。很是🥚疼

但应该是监管部门对这玩意有要求，需要至少保存 6 个月？

[PolarBears]

@zu1y 虽然监管部门有要求要 6 个月,但没要求日志要详细到什么程度

[darknoll]

我就不想打太多日志了，客户出问题我直接连对方调试呗