这是一个创建于 1519 天前的主题，其中的信息可能已经有所发展或是发生改变。
日志内容
不讨论针对用户行为的埋点日志，仅讨论业务日志。
待过两家公司，完全不同的日志策略：前者是内容平台（也是创业公司），基本上能不打日志就不打，只打一些异常日志；后者是交易平台，基本上所有用户请求都要 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 sparkssssssss 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