现在我打印了每个接口的请求体(脱敏后)，以及返回结果，sql 信息，异常信息，为了方便场景复现以及记录信息，但是老大觉得没必要，因为这会浪费大量的磁盘空间。有必要的记录就行，想请教一下前辈们意见，是否有必要
This topic created in 2802 days ago, the information mentioned may be changed or developed.
 |
yanaraikaMar 3, 2019
1
配个 logrotate 自动压缩、删除超出限制大小的 log。当然最主要的问题是可能对 CPU 负载比较大。
|
 |
fox0001Mar 3, 2019 via Android
2
浪费磁盘空间是小事，文件太大，想拖下来分析也是麻烦事。所以记录下来是为了什么？很多错误，在测试阶段就可以 fix 了，上线后就没必要记录这么多了
|
 |
hcymk2Mar 3, 2019 via Android
3
日志分级别吧
|
 |
alfchinMar 3, 2019 via Android
4
我觉得没啥必要。越详细分析的时候找数据越痛苦。
|
 |
sun1991Mar 3, 2019
5
纯技术方面的可能没必要. 但是如果以后要和客户撕逼的话, 日志还是越详细越好. 就我个人经验, 客户有时也会为了推卸责任而撒谎.
|
 |
lianyueMar 3, 2019 via iPhone
6
我的 http 状态码 <400 就记录 ua ip 时间 400 记录 错误消息 > 500 记录所有信息
|
 |
catalinaMar 3, 2019 via Android
7
不同的错误需要的日志详细程度是不一样的啊。。。
有的问题一下子就看出来了，有的问题你可能需要开到 DEBUG2 才有踪迹显现出来。 |
 |
CbdyMar 3, 2019 via Android
9
Unix 的哲学是如果没啥事就保持沉默
|
 |
nicevarMar 3, 2019
10
没有必要，分等级，再说日志配置也可以动态开启的啊
|
 |
everwannaMar 4, 2019 via iPhone
11
后台日志要解决两个问题：和使用方对账，发现两个系统协作的问题；发现内部实现的 bug。正确的方法是，
1. 所有输入输出都要有记录，否则解决不了第一个问题 2. 同时记录关键状态信息，内部关键步骤。保证通过记录的关键信息能够复现输出，这样才能离线分析和判定问题。新人甚至很多有一定经验的人打印的日志往往上下文关键信息太少或者没有，导致判断问题非常困难。 |
 |
jssMar 4, 2019 via iPhone
12
完全没必要，系统运行 2~3 个月后硬盘报警，一排查 99G 日志
|
 |
ccgoing10Mar 4, 2019
13
日志可以放到 debug 里面，动态开启
|
 |
14
@everwanna 现在就是所有输入输出都有记录，但是日志过大以及无用信息太多，排查也不方便 ， 另一方面如果不记录日志，又会导致判断问题困难，所以不知道如何取舍
|
 |
vivisideaMar 4, 2019
15
异常(exception)日志建议把出错时的关键参数都打出来，排查问题方便
|
 |
dingyx99Mar 4, 2019 via iPhone
16
可以把异常存下来，关键操作压缩存下来滚删，前面那位说避免客户扯皮的感觉好有道理 hhhh
|
 |
NoKeyMar 4, 2019
17
没有定论的，看需求的好么。。。
公司组织架构不同，处理方式都不一样 从你的描述可以看出，你们很在意磁盘容量，那么只需要输出关键信息即可 有的公司根本不在乎，服务器性能也不错，想怎么搞都可以 有的公司研发运维完全分离，运维需要看日志，这种就得输出的很清楚 等等。。。 都是就事论事的 |
Select Language