1
chendy 270 天前
老项目,无日志收集,出问题只能人肉看,日志文件 20m 一滚,超过一月压缩,超过三月删除
但是日志量没这么大,一天几百 m |
2
Sanko 270 天前
我这里是 10M 一滚
|
3
rorwprint 270 天前
看场景是否可以按小时滚
|
4
zliea 270 天前
我赞同 3# 这个数量可以小时
|
5
feelinglucky 270 天前
无定式,看使用场景以及服务器的配置等各种条件而定
话说没有被日志撑爆服务器磁盘的经验,对于后端开发职业精力而言是不完整的,哈哈哈 |
6
guo4224 270 天前
4-5g 的文件,你还能折腾出花来吗
|
7
drymonfidelia OP @feelinglucky 已经发生过不知道多少次日志撑爆硬盘了 要不我们能跑就行的代码连压缩都不会做
|
8
ladypxy 270 天前 via iPhone
按时间不是按大小,
|
9
drymonfidelia OP @ladypxy 我们产品不同时间活跃用户量差异很大,不适合按时间
|
10
darksheep9527 270 天前
@drymonfidelia #9 我觉得按时间会更合适 因为去 support 的时候 可以按照用户操作时间 直接找对应的日志文件
按大小切片 找日志文件就会慢一些 |
11
drymonfidelia OP @darksheep9527 文件名里有创建时间呀,只要知道发生问题的时间还是可以一次定位到日志文件
|
12
knightdf 270 天前
以 vim 打开不卡为标准,哈哈
|
13
kneo 270 天前 via Android
一天一个文件比较方便。建议 10g 。
|
14
bronyakaka 270 天前
建议按天滚动,保留 1 个月。
体积的话多大都行的,看存储够不够用,不会有太大性能问题 (推荐一下我的 kafka gui 客户端,非常好用: https://github.com/Bronya0/Kafka-King/) |
15
paopjian 270 天前
保存报错日志,操作日志就随意吧?
|
16
laminux29 270 天前 1
这要根据财力来。
比如,如果给每台设备的系统盘,就配置了 2TB SSD ,单个日志 100GB 都没问题。 至于归档,直接 7z 最高压缩方式。 |
17
julyclyde 270 天前
科学的讲,你都不该写到盘上
日志 是流 |
18
qiyilai 269 天前
我这边 100M
|
19
CHENXCHEN 269 天前
我们是按大小+时间来轮转,保留最近 1 个月或者最近 20 个文件
|