业务系统日志存储选型讨论

[steelshadow39]

本人学生，最近项目在讨论日志存储的选型，后端是 springboot ，日志格式为 JSON ，组内有人提议使用 MYSQL 存储日志（因为系统体量不是特别大），我选的是 graylog （存储用的是 elasticsearch ，比 ELK 更轻量）。我觉得无论日志量大小，elasticsearch 的检索和日志处理都要比单纯用 MYSQL 强很多，用 MYSQL varchar 存 JSON ，查询出来还要解析，效率也太低了。并且处理日志本来就是 elasticsearch 的强项。

想请教各位前辈，公司开发在日志这块一般是怎么处理的，感谢各位前辈指点。

[dedemao]

先用 MySQL 存吧，遇到问题了再换也不迟

[steelshadow39]

@fatyoung 这是不是相当于我把 es 的 CRUD API 自己实现了一遍？我现在是通过配置 logback ，GELF UDP 发到 graylog ，这样是实时发送吧。如果用 API 的话，是不是只能定期上传，做不到实时吧，实时是否意味着要一直调 API

[Rorysky]

直接写文件

[zhaohua]

阿里云的 sls 非常便宜,小公司一年也就几百块钱顶天了.

[aaronkk]

VictoriaLogs 看一下
牛吹得很大，号称比 es 大幅节省成本，号称比 loki 快，号称比 clickhouse 易用

[wwwz]

如果都用 springboot
日志生成用 logback 等生成格式相同的日志文件，这一步为止都是没有学习成本的

再考虑采集加工储存查询使用什么，多台服务器采集可以搭集群然后集中管理
ELK 资源耗用比较多，LOKI 轻量一点
graylog 没用过不评价

[steelshadow39]

@wwwz 日志上传好像是无回执，就是没有返回值，所以别人可能不知道自己上传是否成功，还得简单学一下 es API

[julyclyde]

@steelshadow39 导师的渠道搞来的国家级项目啊？那随便写写就行了

[Jat001]

选型最忌讳的就是搞一个所有人都没用过的超复杂工具，特别是那些配置复杂的分布式项目，谁去部署谁未来就是救火队员。我还见过日志存文件，自己写 api 查询的呢，又不是不能用😅

[steelshadow39]

@Jat001 嗯，这确实是我的错误，想选一个功能对口的组件，没太考虑学习成本

[Betsy]

@julyclyde 我的出发点是系统本身用的是 MySQL ，没有必要额外引入一个新的组件增加维护成本。所以换个代码更少依赖更少的组件，本质上还是需要新增人来维护，徒增烦恼。

[onceMore]

日志先全部存文件，效率比较高，后面做检索可以落地到 MySQL 、ES 加钱用服务都方便

[Betsy]

@steelshadow39 这样啊，你的初衷是快速完成这个项目？还是想学习点新的东西？还有这个项目有没有亮点？能不能放到你未来校招的简历上？如果真的普普通通毫不起眼，你将来还指望找个不错的工作，那么请务必力推 ES ，一套完整的日志系统也足够校招吹牛批了。如果想快速弄完这个项目，那 MySQL 就很不错

[FrankAdler]

可能 loki 都比 mysql 来的好，考量一下数据量稍微多一点点和查询性能

[ccagml]

公司有写文件的，写 MySQL ，写 es 的，还是看数据量吧？一天一条日志，上什么集群对吧？

[steelshadow39]

@Betsy 我的初衷是学东西，找工作。这个项目肯定是要作为简历中的一项。加上我是主要开发，所以我更倾向选择一些企业常用的，比较成熟的方案。

[Betsy]

@steelshadow39 其实写 MySQL 也是企业常用的、成熟的方案。🤣🤣

[sadfQED2]

目前使用最广的是 elk

但是目前头部互联网公司很多都在往 ck 迁移（存储成本比 es 低）

[sadfQED2]

你数据没有达到 pb 级别的话，直接 es
如果日志连 tb 级别都没达到的话，那无所谓，什么技术方案都没影响

[frank42a]

elk 太重