Go + Mongodb 小巧，高性能，低成本日志服务

Qelog是一款小巧低成本轻运维的日志服务。其诞生的目的就是为了解决中小团队多服务群日志和报警问题。

已经稳定运行 2 年+，滚动写入超过 100+TB 数据。

后台示例地址账号：admin 密码：111111

日志系统特性:

Client

qelog 是项目的 Go 版本 Client 。Wrap Uber-zap ，扩展功能，对 WriteSyncer 进行本地和远程的实现。
本地扩展：日志的切割，压缩，保留期，动态切换等级等。
远程扩展：缓冲打包压缩传输日志数据，异常备份重试保证不丢失，支持 GRPC(默认) HTTP 协议，IO 控制保证带宽占用可控，内存占用低等特点。

Log receiver server

Receiver 进程可横向扩展，保证高可用，高性能。
通过对 Receiver 配置多存储实例，提高集群存储容量和写入性能。
报警模块，对每条日志进行报警规则检测。命中后可以根据规则和不同的报警方式送达。目前支持 DingTalk | Telegram
实现数据分片存储规则，支持自动管理容量，监控预警。存储扩展单独实例，不因中间件而产生瓶颈。
日志统计，等级分布，趋势报表等。

Log manager server

基于 vue-element-admin 修改，支持丰富的查询维度，比如等级、关键字、TraceId 、ClientIP 、多级条件等。因成本和性能问题暂不支持全文索引
友好的操作交互，简易的配置，高效的内容展示，几乎可做到开箱注册即用。
集群容量统计查询，手动干预等功能。

性能测试工具

/tools 包含 benchmark 与内存占用测试。
不同的运行环境和配置有不同的表现，可合理综合分析，初步检测此服务是否满足场景需求。

PS: 生产环境中，该项目经过几轮死循环“攻击”。。。

设计简图

使用建议

Client 端导入项目

go get -u github.com/bbdshow/qelog/qezap

Client 示例

服务快速部署

容器部署

git clone https://github.com/bbdshow/qelog.git
cd qelog
# custom you config
vim config.docker.toml
# build docker image
make image
# docker-compose start container
docker-compose up -d

主机部署

git clone https://github.com/bbdshow/qelog.git
cd qelog

# go build, output ./bin
make
cd ./bin
vim configs/config.toml
cd ./admin
# admin suggest single server, because have background task
nohup ./qelog_admin -f ../configs/config.toml >> nohup.out 2>&1  &
nohup ./qelog_receiver -f ../configs/config.toml >> nohup.out 2>&1  &

感谢支持，如果对您有用，希望Star以表支持,有问题请提 Issues ，持续更新并解决问题。

hopingtop

2022-12-12 21:48:22 +08:00

@Maboroshii 嗯，是直接入 DB 的。性能瓶颈，就是 Mongodb 的瓶颈。因为建立索引极其克制，所以批量写入性能很好，
项目 /tools 目录里面有 benchmark 工具，可以依据自己的环境来测试。2c4g 的 mongodb 空集合的情况下 7-8w/s 单条 /350bytes 还是可以的。

针对如果单进程有异常大的日志量，是建议 Bind 一个性能好点的 DB 实例上，进行纵向扩展性能，同时分片时间短一点，比如 7 天一个集合。这样能保证单集合不会过大，导致此进程写入日志性能下降。但是因为 Remote 写入实现是异步的，不会阻塞主进程。短时的峰值流量扛不住或者集群异常，会把日志写入备份本地文件，然后有异步逻辑补偿写入，直到备份文件内容追平。

不同的模块（理解成 APP 进程）可以绑定不同的 mongodb 实例里面，这样写入是分散的。但是做不到自动冷热分布，如果初期无法预估容量，可以通过统计趋势写入量的，然后通过后台手动绑定进程写入到哪个实例，来分布数据的冷热问题，达到均衡使用。

目前，我们部署方式很特殊，我们有很多独立的项目群。目前网络不互通的部署了 5 套，目前最大的集群，日写入量在压缩后有 35G 左右。平均 4000W 条吧，2c4G 的 Mongodb 就可以满足。

hopingtop

2022-12-13 10:08:17 +08:00

@sbex 嗯，你的问题很好！这里我们可以看到，当前系统，不支持全文搜索，不支持跳条件查询，这都是考虑到索引大小和查询速度，而牺牲更大的灵活性。traceId 这种查询就不说了，他是走的单索引。
我们觉得靠谱的日志打印，一定不是大海捞针才找到。一般来说通过 3 个查询维度，就能缩小到很小的范围。所以我们只建立了一个联合索引，并且查询条件设置顺序严格表现为前缀形式，比如：填了等级筛选，才能填入短消息筛选，填入一级条件，才能使用二级条件...

我们举一个应用场景：一个进程每天的写入量在 5000W 日志，那么我们设置此进程 3 天分一片，那么此模块下，单集合容量差不多在 1.5 亿的情况。这个时候如果时间范围控制的比较好，查询返回是在毫秒级别的。因为缓存问题，相似查询条件，第二次查询会更快。
当然这里就会产生一个限制，就是单次最大查询时间范围只有 3 天，我们不支持自动跨集合查询。因为产生了跨集合查询，可能会导致资源占用不可控。

因为我们自定义了 collection 隔离，所以需要大量 IO 查询的情况下，对其他的进程写入和查询也是不受影响的。

我们知道 Count 是很耗时的，所以在查询的时候我们优化了查询方式，异步最大 Count 5W 条 | MaxTimeout 3s 。所这里存在的问题就是，日志条件筛选后还大于 5W 条 Count 就是不准的了。

如果写入量还很大，比如一天达到了 3-5 亿，因为我们的最小粒度是天分片。所以 2c4g 的 mongo 对单表 5 亿的筛选是很有压力的。不过还是特别恭喜你！你可以有更多的钱去升级更好的系统了。或者升级此系统的 Mongo 也可以！