perf(opentsdb): 数据拉取以ident分发，并把list方式改为chan方式，提高消费效率。

[qzhello]

起因：我们遇到了多个几千个收集的targets，使得n9e发送到prometheus的效果不是很好。
想法：由于每个采集点都有一个ident，这样n9e处理的有些慢。
改造：默认提取ident，每个ident都有一个chan进行分发处理，提升消费效率。

[UlricQin]

原来的写法，性能瓶颈在哪段代码？如果调大QueuePopSize到20000，是否可以改善；或者仅仅把SafeListLimited改成channel，是否可以改善

[qzhello]

我觉得瓶颈就是大量的请求进来，会迅速让队列中的数据超过QueueMaxSize，导致数据丢失或阻塞。如果用ident来分的话，可以加快发送prometheus的速度，单纯的增加QueuePopSize会使请求体过大，响应时间变长，由于是单协程处理，会影响到其他ident的数据发往prometheus。

其实改chanal更重要的是为了让每个ident都有一个chanal队列去发送，让下游处理速度变快并互不影响。
还有个好处就是ident标签如果提取出来了，放到header里，可按照规则路由到指定的prometheus。

[famosss]

@UlricQin 用ident单独queue发 再配上ident的header。发送prometheus的时候走nginx可以配置个header的一致性hash,这样可以下游用多个prometheus实例。配上thanos可以做一个简单的prometheus集群。就不需要引用M3等新的技术栈了

[UlricQin]

你这个改动上了你们的生产了么？前后性能数据有么？

[famosss]

你这个改动上了你们的生产了么？前后性能数据有么？

现在生产环境核心的监控就是基于这套来做的,所有的容器监控都基于这套来搞的,大概3w+容器。
性能方面:其实是把大批拆成了很多小批加上多并发,确实有一定的改善。
主要改动还是架构方面,核心是2点:

1. 按照ident拆分,也能做到假如某个ident量太大时候,其实仅仅影响这一个ident的数据,但是不会影响到全局的监控流量数据
2. 配上nginx的一致性hash,可以做成分布式prometheus集群,没有引入像M3等新的技术栈,而是用了更熟悉的prometheus+thanos,运维成本也大大降低了。如下图,我们搞了7个prometheus。
   

[laiwei]

@zhuqunzhou @qzhello 挺好的实践，期待深入交流下， 我的微信 laiweivic
也欢迎把你们的实践和经验分享给社区： #897