今年的 实体 物品怕不便宜，毕竟有通胀等问题

frp 是你上面描述的用过的方案吗？
其实你大可不必担心域名和端口泄露问题。
生成一个随机的 X 位字符串,当二级域名不就行了吗？是不是可以当密码的思路用？
如果你这样还担心泄露，域名和端口，还担心你的 NAS 破解验证。 你就当我什么都没说吧

@hopingtop 这里只单纯讨论为什么可能出现超时，不讨论为什么要这么用 ETCD

一百万数据并不多的。如果在读场景少的情况下。 从节点不多的情况，一般不会出现这样的情况。
出现问题，主要是看 client 的使用方式是否有问题，还有就是 ETCD 的配置。如果是云服务，一般是大多数场景的最佳配置。特别注意一下 关于 ETCD 存储大小和压缩相关的设置
看看 client 端吧。 如果是基于 v2 版本的 HTTP ， 也要注意一下 Request 包是否有什么问题。
还有就是每一个 KV ，V 是否过大？
如果会其他语言，可以试着换一种语言的 Client 试试

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

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

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

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

@HertzHz 后期我更新上去

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

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

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

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

自行车+八方中置电机+锂电池

nuc8 使用用户，之前装了黑果， 就是舍不得改网卡，现在装回 windows 了。。。

比较好的一个社区，不过这个 太阳码 也太夸张了

这种情况多数是自身写的 BUG 所致，看看是否用到了 goroutine， 如果用到了，那么人肉编译，就不一定看得出来问题。如果是必然现象就断点，如果必然现象，就再好好理一理代码吧。特别是一些 初始化的问题。多看看

对于高频访问 IP，直接返回缓存数据或者投毒，让调用者认为他目的达到就行了。玩心理战， 代理池也是有一定成本的。对方大概率不会每次请求就使用代理。特别是当他访问畅通时。代理可能就不会用。

如果服务是短链接，例如 HTTP 这种，高并发情况下，会创建很多新的 TCP 新链接。当服务器主动发起 FIN 包关闭链接时，会出现 2 个 MSL 的等待时间（此时的 fd 资源是没有释放的），这都是为了安全关闭 TCP 链接所做的机制。可以修改系统参数，适当的缓解 time_wait 这种情况。

看完了再批判，目前你所看到的剧情只是表象，背后还有无形的大手。后面还有很多东西！