是否应该把程序日志写入到 Mysql 数据库中

[Mianmiss]

RT 我发现我司很多开发以及一些外采的系统 都很喜欢把程序日志写入到数据库中。

数据库压力、性能开销等都会受到影响

[cnsdytedison]

我认为应该，压力，性能开销花钱可以解决。持久化的日志没有的话锅就会在你身上。

[ewpui]

@cnsdytedison 中肯!

[isno]

日志如果要持久化，选择 es 、Loki 或者 Clickhouse 。选择 MySQL 肯定不合适。

https://www.thebyte.com.cn/Observability/logging.htm

[Ayanokouji]

关键是有给提供其他选择吗

[sakilascott]

@isno 小系统用不着这么复杂的架构。

[lstz]

过早的性能优化是万恶之源

[lstz]

不过我不建议 db 存日志，听起来挺奇怪的，sftp 加文件更合理点

[adoal]

用 syslog 协议写到专门的日志服务器去，那边再怎么处理归专人负责

[beneo]

1. 看需求，如果你只有存的需求，MySQL 只要能抗住有空间，也无妨
2. 有能力有时间就折腾 ELK 那套，毕竟用户可能提需求说要做分析

[idontnowhat2say]

我只见过审计和操作日志需要写 db 的，程序日志写 db 那也太奇葩了吧。日志这种顺序写的东西，存 db 还不如直接写磁盘吧。

[nuk]

还行吧，得看日志多少，主要是如果要在页面查询会比较方便

[nqlair]

量少无所谓 大的话存 s3 然后 es 加对应的索引用来查询

[hui9000]

存是肯定得存，选择什么也有个先后顺序，工作是干不完的，不要一次解决，持续优化。
不关你的事情别管。自己知道应该存哪就好。

[potatowish]

@isno MongoDB 适合吗

[isno]

@potatowish

如果是标准化的日志系统（有分析、检索、告警），用传统的数据库不论是 MongoDB, 还是 MySQL 都不合适，索引太占内存，副本机制太占存储。

看看 Loki 吧，有报警插件，有视图 Grafana ，搞出一套也不复杂。

[YaD2x]

这是你考虑的吗，日志收集转换不是运维的工作吗

[Garphy]

把日志结构化，插入数据库更合适

[potatowish]

@isno 谢谢

[jiangzm]

操作日志可以写数据库， 系统日志还是不要存数据库。

[FawkesV]

需要追溯的可以写,不需要的临时日志不用了

[wheat0r]

直接写数据库意义不大，处理过之后存进去就不错

[via]

阿里云的 sls 很香

[dongzhuo777]

看你现场实施运维的水平，如果你司现场实施运维只会数据库，那写入 mysql 没问题，反正都是异步丢进去 出问题了 他自己知道去捞日志。尤其是一些对外的接口调用的日志。

[salmon5]

日志也是数据的一种，比如计费日志、操作日志等，这些都要长期保存。也不是不可以。

[egfegdfr]

如果是业务上需要的日志，可以记，我司有些系统把程序日志也存里面了， 不过好像除了花钱，也没啥问题， 因为那个表也不对外提供服务

[cctv1005s927]

转存别的吧，重要的资产扔 rds ，日志类的，扔 es 或者 clickhouse 就行，避免对主业务的影响。

[wanguorui123]

定期自动清理就行

[miaotaizi]

最烦这种把日志写到数据库的低级行为了, 正事儿不干, 就在那研究怎么写留言板

接个 SLS 很难吗

[skywalkerfc]

写到无所谓，弄个脚本定期清理就可以

[guo4224]

@lstz 日志就是为了存，不是为了用是吧

[cdlnls]

我觉得这个是一种很 low 的行为。

[lx0758]

刚刚部署了一个 loki

[johnhuangemc2]

审计日志可以存数据库.
运行日志就还是选传统方式吧, 轻量服务存文件, 大型服务存日志中心

[eastjoehan]

可以记，例如关键的增删改操作日志
程序日志就没必要了，像楼上说的直接搞个日志采集组件，再搞个面板看看就好

[qW7bo2FbzbC0]

@potatowish 简单查查的话 OK 的，我有这样用。复杂的查询还是建议 loki es 啥的。mongodb 的数据压缩率还是可以的

[luozic]

真为了性能+追踪，那都是用 kakfa 等 mq 去异步写入，至于之后存在啥地方，看公司规划

[xinshoushanglu]

看有没有价值，如果日志很关键，后续有查询需求，不管放 mysql 还是 es ，mongodb 都值得

[mezhangkai]

es ，省心就阿里云 sls 花不了几个钱，比 s3 还便宜

[lxdlam]

日志需要持久化，尤其是有跨天 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 的。

[lxdlam]

@lxdlam 没写完发出去了。补充一下特性第一条：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。

[securityCoding]

边缘内部系统 qps 不过 10 爱咋存咋存，挂了也是靠人吼

[huijiewei]

数据库只存操作日志和审计日志

系统的日志都是单独存的

[wenye123]

看项目 小项目咋搞都行 大项目肯定还是得规范化

[akira]

有存就行，至于好不好，看实际情况再说。。。

业务没起来前，存哪不重要，重要的是要存。
业务起来了，钱到位怎么改都行。。。

[bthulu]

具体问题具体分析. 如果是公司内部部署到公网服务器, 对外提供服务, 那肯定不合适.
如果是像我司这种, 都是部署在客户普通 PC 机上的, 不写数据库你写哪? 还整什么 es, loki, clickhouse, 你这不是让现场实施找罪受么, 不怕人家回公司打死你?

[dog82]

关键的操作日志可以写进去，不过日志表的引擎换成 myisam

[nutting]

直接写太侵入了吧，先正常写日志，到文件。再用采集模块到 es 什么的入库，这样解藕

[snitfk]

感觉放 ES 是比较合适的方案。速度快，查询也方便。支付的量级也比较大。数据库单表一大就会卡。

[julyclyde]

写到关系型数据库，基本上可以认为是整个项目组没见过什么世面吧