共计 1063 个字符，预计需要花费 3 分钟才能阅读完成。
开源我的项目地址:
我的项目地址: 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 做分片调配给衰弱的节点采集即可
正文完