开源我的项目地址:
我的项目地址: https://github.com/ning1875/prome_shard
我的项目阐明
prometheus采集端单点问题
采集类型
- 采集机器级别的指标
- 采集k8s根底监控指标
- 采集部署在lb前面的vm业务指标
- 采集部署在pod里的业务指标
- 采集各种中间件的指标 如kafka zk clickhouse等
面对如此简单的采集类型，个别会应用一批采集Prometheus各司其职
sd发现问题
面对不同的采集起源，有对应的服务发现类型，如k8s_sd，咱们批改Prometheus代码适配不同的服务发现类型，
- 比方有一些指标挂在lb的前面，须要通过lb的服务发现来感知后端server的变动
- 然而问题是每个采集器都是单点的，而且批改适配不同的发现源
- 当然也可能够无脑启动多个雷同的采集器采集同一组jobs，配合remote_write等补足单点问题，但带来额定的老本开销
各自适配不同发现源毛病总结
- prometheus版本无奈对立
- 配置文件形形色色
- 须要定义各种采集源或者sd办法
本我的项目介绍
应用一组采集器注册server到consul中，通过python反射运行定时工作，通过服务树等内部接口拿到targets池，一致性哈希分发给后端，对立通过file_sd失效，consul会对各组采集器实例做探活，当节点变动(宕机或扩容)会触发targets rebalance达到HA目标
架构阐明
- 解析配置文件
- 同步注册服务到consul中
- 开启监听watch后果变动的消费者
- 异步watch各服务
- 触发/get_service生成哈希环
- 定时获取指标列依据哈希环生成各个节点的专属文件
- 通过ansible下发 sd_result文件并reload prometheus
现有形式
- 配置文件定义方法名称和对应的实例列表，在get_targets中反射定义对应的办法
sd实质阐明:均能转换成file_sd，只须要给出对应的 target构造体就能够
{ "labels": { "group": "SGT", "env": "prod", "service": "scrape_prome", "region": "ap-southeast-3", "scrape_type": "vm", }, "targets": [ "localhost:9090" ] }
采集器单点/固定分片问题
- 无论是单点还是固定分片，都不是ha的，只有某一个分片的采集器挂了，那么损失对应的数据
- 采纳consul_watch_service形式，依据返回的衰弱实例生成一致性哈希环
- 将target做分片调配给衰弱的节点采集即可