Go 轻量级，高性能，低成本日志系统，适合小团队及个人项目

提到日志系统最先想到的就是 ELK 。但是对于小团队或者个人使用，它的成本是否太高昂了？？？

如果只是针对 Go 语言的项目，或许还有另外一种比较低成本的解决方案。

额外成本只有 Mongodb，就能做到快捷的日志收集 /查看 /报警 /统计

Qelog https://github.com/bbdshow/qelog

关于写入性能:

1.取决于 Mongodb 的批量写入上限

2.不同的模块是写入到不同的分片集合，所以在容量索引建立都有极大的优势

3.客户端实现的异步，日志批量压缩写入，节约 IO

PS: 不严谨测试单点（ 4C/8G 本地 Mongodb ）可做到 13W+/s 日志写入

对于集群部署，写入能力取决于背后集群配置了多少 Mongodb 节点。理论可一直横向扩展

关于读取性能：

1.我们都知道 Mongodb 使用不当比较占用资源，特别是贪婪内存模型，导致吃了内存就不在下降了，通过存储使用优化，索引优化，查询限制优化，我们不必担心多用户查询导致 Mongodb 的内存上升。

2.因为时时写入，所以日志几乎没有读取延迟

关于管理后台:

1.部署 Admin 进程，就可直接使用。写入权限取决于是否创建模块名(内网没有过多的权限拦截)。

2.只有简单的登录权限，没有其他的权限限制，因为定位，所以没必要搞复杂的权限模型。

目前该项目已经有上百 TB 的写入数据了，稳定性是可以保证，即便日志服务异常挂掉，也不影响使用进程的运行状态，Client 端也会重新 Push 日志。

关于设计和功能和使用帮助请看 https://github.com/bbdshow/qelog 谢谢

如果您觉得对你的项目有帮助，可以收藏一下，在使用过程中有问题就可以提 Issue

极少发帖，有不足之处还请谅解

liuhan907

2021-08-31 11:57:48 +08:00

@hopingtop
1. Loki 的配置已经很简单了，会需要大规模日志收集的基本上也需要指标监控和追踪。在使用 prometheus 的前提下几乎没有啥额外成本。如果是全新上一套新的项目要引入的话那这件事本身就是一个 KPI 嘛。
2. 配置复杂这件事我觉得和 mgo 的分片复制集相比半斤八两。。。
3. 远端存储里，别的不谈，我还没见过云厂商有不提供 S3 兼容存储的。
4. Label 那块确实有坑，按一般理解来用的话会踩大坑倒是，不过那个最佳实践其实十分钟就能读完了。
5. 那个规则是可以实时变更的，至于写起来是否复杂我不能决定，这玩意就和语言一样看个人。
6. Loki 的存储压力比作为数据库的 mgo 的压力更小的，而且 mgo 需要做分片复制的关系压力其实更大，因为其是一个数据库没有针对性做优化。关于数据存储这块你可以继续参考官方文档，他们有不少优化。日志这种东西如果因为量大就删除的频繁我觉得不是个好主意。
7. 展示这个。。好吧他确实没有 Kibana 做的好。

hopingtop

2021-08-31 12:20:00 +08:00

@liuhan907
1.配置简单对比 Qelog 我不赞同，你可能是对比其他的日志服务。当前背景是中小团队和个人项目，不一定拥有 Prometheus，况且 Label 的方式和普通日志的方式还是有一定的区别。这里应该是选择？需要一个 Prometheus 还是需要一个快速解决问题的日志系统？
2.我这里 mongodb 并没有采用他自有的分片集群配置，自有的 sharding 配置和维护确实有点繁琐。我是根据程序自动路由到不同的 mongo 库实例中
3.关于远端存储如果选择 S3 我认为在存储这里不知道会不会有问题，特别是索引，还有是否会有碎片化的问题，特别是容量清楚的时候，KV 的存储方式，不清楚是否会扫描 K，然后在删？
5.对于不知道 Prometheus 报警规则的，没接触过，又是一个学习成本。
6.因为没有使用 sharding 集群，所以每一次，每一个租户都相当于独立拥有单集合的批量写入，达到最高性能。mongodb 的 sharding 反而会更慢，因为他会把一批数据打散，不能充分利用批量写入特性。也不利于数据维护，
关于量大删除，这里为什么会分集合，对于 mongodb 如果要删除一个集合当中的某些数据，其实开销是很大的。而且删除的数据空间也不会马上被系统回收，还是会被当前集合占有，但是对于 drop collection 的开销就很小很小了。因为在删除这个集合的时候，同时集合是不会承担写入请求的。而且占有磁盘会马上释放。所以采用这样的删除逻辑可能更优。

以上几点是对应几点的，解释。你看看是否还有疑问

liuhan907

2021-08-31 18:31:36 +08:00

@hopingtop
1. 关于配置的复杂与否，我觉得还是看是否熟悉这套东西。比方说如果从来没用过 mgo 的团队，重新了解一个新数据库的工作量也不小。
2. 不用分片复制集的话，数据安全怎么保证呢？
3. S3 存储不会有啥问题，它的日志存储模式就和一般的日志系统不太一样。碎片化是肯定不会有的，它的日志存储是会分块存储的，类似 HDFS 。
5. 这个我同意，但是报警本身就是一个很复杂的事情，过于简单的配置线上用起来感觉有点束手束脚的。我其实觉得 alert 那个都还是表达能力有点弱了 2333333
6. mgo 分片集的分散写问题，只需要加大一些批量写入的条目数问题就能解决了。如果没那么大量的话可以考虑不用 hash 模式来做分片。

关于数据存储的占用这块，Loki 的存储模式和数据库这种其实差异很大，最直观的例子就是你用时序数据库和常规的数据库比如 mgo 同样存储一些连续点数据，看看数据占用。这个是对比度最强烈的。