推荐阿里云的 SLS 服务

@mokeyjay 然而我只是班门弄斧?现在你才是大佬啊，有时间带带我?救救孩子吧

你这个问题基本上涵盖了计算机本科的大部分知识，要讲明白，相当于得为你写好几本科目的教材。

如果你真想学明白，可以去搜搜国内 TOP5 计算机本科或软件本科的科目，然后去找相关教材学习。

如果只是想随便了解下，一楼兄弟给的方案就不错，或者自己把几种方案都尝试一下也行。只是，一旦遇到问题，或者结论与你设想的不一样，没有足够的知识，你是没办法查明问题的根源所在。

@linxiaojialin

文件顺序写 IO 即可，数据库即使不算事务，也有数据库自己的处理逻辑，总归是慢一点的

另外，日志没有不切分的，按规则切分，配合 grep，awk 之类的，比数据库方便多了
例如，查询包含 error 字符串的日志，数据库就很麻烦

建议集中到第三方存储，毕竟现在各种分布式架构，本地存储方案只适应用单机项目了

最近我司在转 clickhouse

需要分析和查询的话还是 ELK 简单
日志量不大的情况下比数据库还是舒服的，量大的话就如上面所说一言难尽，除非你非常有钱

@linxiaojialin #4 嗨呀，好久不见
说起来头头是道的，厉害呀，没少进步
哪像我还在文件+脚本定期清理

对 Elasticsearch 一言难尽，还是 Loki 舒适简单。

日志打进文件简单稳定，给个文件就能打，用户想落库自己捞就好
开源项目日志直接落库的话，要考虑各种数据库各种环境，虽然有日志工具但是还是太复杂

ELK 里 E 纯粹是浪费性能，因为大多数日志不需要结构化解析。
所以现在推荐 Grafana 出的 Loki

kafka -> mysql -> es 目前是这样

看项目规模，小型项目节点很少，通过日志组件直接记录文件就好了，偶尔排查个问题啥的
如果项目较大，节点较多，日志分散在文件中，定位问题需要查找多个文件相对较为麻烦，另外如果还有分析，告警之类的需求，则 ELK 这类的技术栈更为合适

数据量不大的，直接存到数据库，有钱又有价值的上 es
我们公司就是存数据库的，而且大多数都是如此做

@wangyanrui 感觉和你理解的有点不一样，第一个问题，“存”日志时不会启用事务（可以用 MyISAM ），所以存的效率也不低，而“查”日志时数据库效率比较高，特别是一个日志文件有几十上百 G 时，区别更明显的，文件打开时非常慢，更别说筛选查看。

第二问题，跟你的观点一致，额外补充：①数据库比较占内存，而文件只是占磁盘；②一般应用日志跟业务无关，应独立出来，避免占用“业务数据库”资源。

@naoh1000 所以开源项目“默认使用”文件存储日志，可能是考虑项目初期（小项目）服务器的资源问题。等项目大了，可以把日志的存储配置改成数据库，单独搞一个的“日志数据库”，或者上 ES 、ELK 等等。

楼上说的都没问题，一般还是具体问题具体对待，如果是小规模的项目，就用最简单，最方便的方式就对了。
综合来看，大部分项目使用的是本地写文件的方式，定期会归档，清理。
如果涉及较多的机器，一般也会集中将每台机器上的日志收集起来。

第一个问题，一般文件更高，因为数据库牵扯到事务，会多一层逻辑，所以数据库效率不高

第二个问题，因为小项目日志怎么搞无所谓，大项目必须要 高性能，高搜索支持度，结构一致，以及便捷的支持后续的数据分析

一般都有集中的日志中心。大佬们都推荐 ELK 。