看看 Dockerfile 是否有通过 环境变量 配置这个 ServerName

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

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

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

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


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

@gerorim 嗯，前端这块不是我的强项，是要优化一下，后面空了，我来弄 详细的 error code 来处理，这块的提醒。目前只有验证类型的错误会直接返回给前端，偷了个懒，哈哈。

@gerorim qezap.New(qezap.WithLevel(YourLevel)) 默认 DEBUG 。 在初始化指定一下就行。 指定 info, 就是 info 及以上。其他日志级别同理

@hopingtop 日志趋势写入量，管理后台已经统计好，可以直接查看，然后灵活调整。
正式因为部署方式特殊，所以才出现这个日志系统。 假想一下，部署 5 套 ELK... 这成本不敢想象。如果要求不高， 这套东西。1c2g 的机器也可以稳稳的跑，畅快的写。

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

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

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

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

@xuzhzzz 哈哈，其实就是有两次团队小伙伴，在写定时任务的时候，有个异常逻辑 select 里面 break 了，并不是退出 for 循环，这个在 Go 语言的 Bug 里面也比较常见。 结果 for 循环了好几个小时，2c4g 的 mongo 写了 8 亿多条数据。最后 mongo 使用内存报警了接近打满了，然后通过后台直接删除异常的 mongo 集合，重启 mongodb 恢复。

@xdeng 哈哈，想法不错，可以考虑考虑，不过连 docker 拉一个 mongo 就觉得麻烦了嘛 555

除非正儿八经做钱包的需要，但是正儿八经的现在不怎么赚钱了。其他的一般不需要，他们更会 随便发一个白皮书，起一个基金会的名字，然后去 用基金会的名字 去注册。 用完就丢， 你懂得

好贴！希望有经验的人，详细讨论一下

我自己的 .com 续费 4 年了，明年 6 月到期，打算不续了，还备案了的，目前打算 进行域名迁移了。
确实觉得 真实名字的意义不大， 反而 网名，我个人感觉更适合。

加班也留不住。计划说 砍 50% 名单就这一两天，说是 2 个月的遣散费。

如果为了用某个东西，而去迎合，设计出一些别扭的方案。容易偏，一上来就整些各种中间组件是很不好的习惯。

最低成本的好用的方案，就是 #3 leeraya 的思路，如果觉得真有必要上 redis ，在把这些数据 Set 上去就行了。

err 目前就是这样，没得什么黑魔法包装，无非就是多两行代码，但是他能给你暴露更多东西，能够第一时间处理。而不是一上来直接一个 try catch 然后 1000 行逻辑代码（例子比较极端）。。。
golang 写出的代码就是开水代码，人人都能看懂。其实这种风格，在工程上来说，是真的讨喜，就算屎的代码，也好扒拉。
但是对于程序员来说，还是多多少少有点其他遗憾， 比如不能 特炫技能，黑魔法，容易交接替代。

最终也并不一定这里有问题，这只是一个 排查方向 @sadfQED2

当前你贴的代码，确实没得什么问题，asyncSendMetricLoop 这个方法调用，只会有一次吗？是 sync.Once 吗？
Counter 里面 会涉及到锁的问题吗？
asyncSendMetricLoop 因为 metricCell chan 不关闭，这个 goroutine 就会常驻， 所以这个方法如何使用就很关键。