这是一个创建于 240 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT 我发现我司很多开发以及一些外采的系统 都很喜欢把程序日志写入到数据库中。
数据库压力、性能开销等都会受到影响
49 条回复 • 2024-04-03 19:14:32 +08:00
 |
1
cnsdytedison 240 天前 via Android
我认为应该，压力，性能开销花钱可以解决。持久化的日志没有的话锅就会在你身上。
|
 |
2
ewpui 240 天前  2
@cnsdytedison 中肯!
|
 |
3
isno 240 天前 5
日志如果要持久化，选择 es 、Loki 或者 Clickhouse 。选择 MySQL 肯定不合适。
https://www.thebyte.com.cn/Observability/logging.htm |
 |
4
Ayanokouji 240 天前
关键是有给提供其他选择吗
|
 |
5
sakilascott 240 天前 2
@isno 小系统用不着这么复杂的架构。
|
 |
6
lstz 240 天前 via Android
过早的性能优化是万恶之源
|
|
7
lstz 240 天前 via Android
不过我不建议 db 存日志，听起来挺奇怪的，sftp 加文件更合理点
|
 |
8
adoal 240 天前
用 syslog 协议写到专门的日志服务器去，那边再怎么处理归专人负责
|
 |
9
beneo 240 天前
1. 看需求，如果你只有存的需求，MySQL 只要能抗住有空间，也无妨
2. 有能力有时间就折腾 ELK 那套，毕竟用户可能提需求说要做分析 |
 |
10
idontnowhat2say 240 天前
我只见过审计和操作日志需要写 db 的，程序日志写 db 那也太奇葩了吧。日志这种顺序写的东西，存 db 还不如直接写磁盘吧。
|
 |
11
nuk 240 天前
还行吧，得看日志多少，主要是如果要在页面查询会比较方便
|
 |
12
nqlair 240 天前
量少无所谓 大的话存 s3 然后 es 加对应的索引用来查询
|
 |
13
hui9000 240 天前
存是肯定得存，选择什么也有个先后顺序，工作是干不完的，不要一次解决，持续优化。
不关你的事情别管。自己知道应该存哪就好。 |
 |
14
potatowish 240 天前 via iPhone
@isno MongoDB 适合吗
|
|
15
isno 240 天前
@potatowish
如果是标准化的日志系统（有分析、检索、告警），用传统的数据库不论是 MongoDB, 还是 MySQL 都不合适，索引太占内存，副本机制太占存储。 看看 Loki 吧，有报警插件，有视图 Grafana ，搞出一套也不复杂。 |
 |
16
YaD2x 240 天前 via iPhone
这是你考虑的吗，日志收集转换不是运维的工作吗
|
 |
17
Garphy 240 天前
把日志结构化，插入数据库更合适
|
|
18
potatowish 240 天前 via iPhone
@isno 谢谢
|
 |
19
jiangzm 240 天前
操作日志可以写数据库， 系统日志还是不要存数据库。
|
 |
20
FawkesV 240 天前
需要追溯的可以写,不需要的临时日志不用了
|
 |
21
wheat0r 240 天前
直接写数据库意义不大，处理过之后存进去就不错
|
 |
22
via 240 天前 via iPhone
阿里云的 sls 很香
|
 |
23
dongzhuo777 240 天前
看你现场实施运维的水平，如果你司现场实施运维只会数据库，那写入 mysql 没问题，反正都是异步丢进去 出问题了 他自己知道去捞日志。尤其是一些对外的接口调用的日志。
|
 |
24
salmon5 240 天前
日志也是数据的一种，比如计费日志、操作日志等，这些都要长期保存。也不是不可以。
|
 |
25
egfegdfr 240 天前
如果是业务上需要的日志，可以记，我司有些系统把程序日志也存里面了， 不过好像除了花钱，也没啥问题， 因为那个表也不对外提供服务
|
 |
26
cctv1005s927 240 天前
转存别的吧，重要的资产扔 rds ，日志类的，扔 es 或者 clickhouse 就行，避免对主业务的影响。
|
 |
27
wanguorui123 240 天前
定期自动清理就行
|
 |
28
miaotaizi 240 天前
最烦这种把日志写到数据库的低级行为了, 正事儿不干, 就在那研究怎么写留言板
接个 SLS 很难吗 |
 |
29
skywalkerfc 240 天前
写到无所谓，弄个脚本定期清理就可以
|
 |
31
cdlnls 239 天前
我觉得这个是一种很 low 的行为。
|
 |
32
lx0758 239 天前
刚刚部署了一个 loki
|
 |
33
johnhuangemc2 239 天前
审计日志可以存数据库.
运行日志就还是选传统方式吧, 轻量服务存文件, 大型服务存日志中心 |
 |
34
JoeDH 239 天前
可以记，例如关键的增删改操作日志
程序日志就没必要了，像楼上说的直接搞个日志采集组件，再搞个面板看看就好 |
 |
35
qW7bo2FbzbC0 239 天前
@potatowish 简单查查的话 OK 的，我有这样用。复杂的查询还是建议 loki es 啥的。mongodb 的数据压缩率还是可以的
|
 |
36
luozic 239 天前
真为了性能+追踪，那都是用 kakfa 等 mq 去异步写入，至于之后存在啥地方，看公司规划
|
 |
37
xinshoushanglu 239 天前
看有没有价值，如果日志很关键，后续有查询需求，不管放 mysql 还是 es ，mongodb 都值得
|
 |
38
mezhangkai 239 天前 via iPhone
es ，省心就阿里云 sls 花不了几个钱，比 s3 还便宜
|
 |
39
lxdlam 239 天前
日志需要持久化，尤其是有跨天 case 的可能性。使用 MySQL 或者其他 OLTP DB 是一种方案，但是不是最好的方案。
将日志当作事件流，思考日志的使用场景： - 问题定位：最常见的 case ，通过请求、用户、设备等等维度抽取一个特定的事件流分析，哪一步出现了问题，这种 case 通常需要对一些特定的 field 当作 key ，抽取查询相关联的事件。 - 数据分析：通过对特定事件进行聚合，计算出来一些业务或者技术指标，诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代，但是在错误日志聚合上仍然有价值。 同时，日志有一些自己的特性： - Append only：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑 - 丢失冗余：根据日志量的关系，其实允许一定程度的日志丢失和冗余，也就是没有严格事务要求。 - 量级和查询需求：很多日志都是大海捞针，允许一定的查询延迟和一定延长的运行时间 从上面的角度，其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统，搭配 Kafka 之类将日志落进去；而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ；如果量小，使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。 |
|
40
lxdlam 239 天前
@lxdlam 没写完发出去了。补充一下特性第一条：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。
|
 |
41
securityCoding 239 天前 via Android
边缘内部系统 qps 不过 10 爱咋存咋存，挂了也是靠人吼
|
 |
42
huijiewei 239 天前
数据库只存操作日志和审计日志
系统的日志都是单独存的 |
 |
43
wenye123 239 天前
看项目 小项目咋搞都行 大项目肯定还是得规范化
|
 |
44
akira 239 天前
有存就行，至于好不好，看实际情况再说。。。
业务没起来前，存哪不重要，重要的是要存。 业务起来了，钱到位怎么改都行。。。 |
 |
45
bthulu 239 天前
具体问题具体分析. 如果是公司内部部署到公网服务器, 对外提供服务, 那肯定不合适.
如果是像我司这种, 都是部署在客户普通 PC 机上的, 不写数据库你写哪? 还整什么 es, loki, clickhouse, 你这不是让现场实施找罪受么, 不怕人家回公司打死你? |
 |
46
dog82 239 天前
关键的操作日志可以写进去，不过日志表的引擎换成 myisam
|
 |
47
nutting 239 天前
直接写太侵入了吧，先正常写日志，到文件。再用采集模块到 es 什么的入库，这样解藕
|
 |
48
snitfk 239 天前
感觉放 ES 是比较合适的方案。速度快，查询也方便。支付的量级也比较大。数据库单表一大就会卡。
|
 |
49
julyclyde 238 天前
写到关系型数据库，基本上可以认为是整个项目组没见过什么世面吧
|
Select Language