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

[hopingtop]

提到日志系统最先想到的就是 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

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

Qelog & Loki 对比

Loki优势：

1. Client端丰富，支持多种写入源,有多种扩展组件
2. 支持本地文件存储（也仅建议用于测试环境）
3. 文档齐全，社区较活跃
4. 报警可以根据指标报警，但是配置又比较复杂
5. 支持查询Cache
6. 具有一定的普适性

Loki不足:

1. 学习成本高，要熟悉 Prometheus 与 Grafana 或者单独学习 Lable|LogQL|Alert Rule 等一些规则。 Qelog 没有其他的额外学习成本， qezap包(基于Uber-Zap)能使用就行了，常用功能都已封装好
2. 配置复杂 主要体现在storage、ruler、table_manager 等等，有太多的配置项需要参考学习，具体可点击查看， Qelog只用在部署的时候设置一次配置，且极其简单，最主要一点就是配置 mongo group 所携带的URI连接信息需要注意一下。对于日志的管理配置等都是可以通过后台点点点就能操作的。
3. 远端存储支持的DB（Cassandra，GCS，S3）非普适性，多数为专有云供应商提供，在国内使用，国内云不一定支持。自有搭建运维可能会存在问题。
4. Label使用有较多的限制，需要参考 最佳实践 去实施，那么对于已有项目的迁移会是一大挑战,同时又是一部分学习成本
5. 针对普通报警方式，依托Prometheus Alart Rule，配置不方便，随时改变报警规则不方便，报警携带内容有限。 Qelog 采用日志即报警的设计策略，缺少Loki这种指标报警的功能，但是配置极其简单，根据项目+日志等级+关键字，就可构成报警规则，报警内容会携带日志本身的信息。同时支持报警频率/开关/报警方式设置
6. 存储周期，存储分片和索引大小问题，存储周期是所有项目共享删除周期，比如项目1需要保存6个月，项目2因为日志量很大只需要保存1个月，这时就会有问题。分片同理。同时当租户过多，日志量增长很快，不确定是否索引会快速膨胀，导致存储和写入查询都存在压力。 Qelog 采用租户隔离，享有自有的存储周期、分片规则、索引存储。更灵活，可快捷针对每个租户定制。如果一个日志量很大的项目，可以分3天一个集合，只保存1个月的数据，那么日志就会分布在 mongodb 11个集合中，每个集合分摊的存储数据较少，这样对于Mongodb存储优化，索引增长都有好处，同时集合过期会自动删除，彻底释放mongodb之前占有的磁盘空间。同时后台会有当前库容量的存储统计展示，可以随时根据磁盘空间对日志的空间占用进行手动管理。保存磁盘的高效利用。
7. 日志展示不够友好，目前Loki是依托Grafana展示日志，例如 tail -f 一行行显示。 Qelog 提供友好的日志显示页面，针对复杂日志还有JSON结构格式化，让问题和查看更加清晰。拥有独立的后台，在日志系统使用过程中更有优势。

Qelog不足:

1. 目前Client端单一
2. 日志不会有指标(例如：一小时内 500X 出现多少次)的提现，只有ClientIP、日志等级分布条数。因为定位暂时不会考虑Loki那种复杂指标
3. 后台没有多租户权限隔离，只要知道后台密码任何租户的日志都可查询
4. 查询条件没有 Loki 那么灵活，但是在绝大数场景下是足够使用的。

以上的总结，只针对中小团队 /个人项目的背景总结。
如果针对日志系统有很多精力与人力付出设计架构等。建议选择更通用的方案！

后台示例地址 http://qelog.hoping.top:31086/admin 账号：admin 密码：111111

qelog 这个服务就接入了自己，这样在你们点击的时候就会有日志。方便有内容查看
本人不怎么会前端，所有各位大佬将就看到吧

[hopingtop]

如果有想要使用咨询、问题、建议，可以随时留言。一起沟通讨论

[liuhan907]

那么问题来了，和 Loki 相对比有什么优势？

[biubiuF]

感谢，正在做日志收集，参考了

[hopingtop]

@biubiuF 如果有疑问可以随时沟通

[hopingtop]

@liuhan907 之前没接触过，等会我去看下 Loki 的架构和实现，总结一下再回复你

[hopingtop]

@liuhan907 我上午看了一下 Loki 的文档，并总结了一下。
可能有理解不对的地方，还请指出，一起探讨

[HertzHz]

Star 了，readme 放个后台 demo 就好了

[liuhan907]

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

[hopingtop]

@HertzHz 后期我更新上去

[hopingtop]

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

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

[hopingtop]

后台 Demo 已经放到 README.md 上面了

[liuhan907]

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

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

[hopingtop]

@liuhan907 嗯，很多问题都是选择合适的。没有最强只有最合适！适合自己的使用场景就好。
感谢一起沟通这么多！