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

[Mianmiss]

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

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

[wheat0r]

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

[via]

阿里云的 sls 很香

[dongzhuo777]

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

[salmon5]

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

[egfegdfr]

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

[cctv1005s927]

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

[wanguorui123]

定期自动清理就行

[miaotaizi]

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

接个 SLS 很难吗

[skywalkerfc]

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

[guo4224]

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

[cdlnls]

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

[lx0758]

刚刚部署了一个 loki

[johnhuangemc2]

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

[JoeDH]

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

[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 ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。