RT 我发现我司很多开发以及一些外采的系统 都很喜欢把程序日志写入到数据库中。
数据库压力、性能开销等都会受到影响

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

中肯!

日志如果要持久化，选择 es 、Loki 或者 Clickhouse 。选择 MySQL 肯定不合适。 www.thebyte.com.cn/Observability/logging.htm

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

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

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

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

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

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

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

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

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

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

MongoDB 适合吗

如果是标准化的日志系统（有分析、检索、告警），用传统的数据库不论是 MongoDB, 还是 MySQL 都不合适，索引太占内存，副本机制太占存储。看看 Loki 吧，有报警插件，有视图 Grafana ，搞出一套也不复杂。

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

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

谢谢

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

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

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

阿里云的 sls 很香

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

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

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

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

定期自动清理就行

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

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

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

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

刚刚部署了一个 loki

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

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

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

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

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

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

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

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

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

数据库只存操作日志和审计日志系统的日志都是单独存的

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

有存就行，至于好不好，看实际情况再说。。。业务没起来前，存哪不重要，重要的是要存。业务起来了，钱到位怎么改都行。。。

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

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

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

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

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