Prometheus
横向扩展当Exporter
或者采集信息须要愈来愈多时就会考虑高可用,高可用优势不会由于集群中某个节点down
而致使Prometheus
不可用,可让算力下沉;
缺点是A-Prometheus
和B-Prometheus
这两个实例会定时去scrape
数据,而且存储在各本地,这样致使数据会存储两份;数据库
将Prometheus
启动两个实例,配置同样只须要暴露的service
的端口不一样,'Nginx Controller'配置session-affinity
的service
名称;网络
Prometheus
联邦在多个数据中心部署Prometheus
须要将多数据中心数据合在一块儿管理,使用联邦模式很是合适,若是担忧数据单点,能够在联邦的基础上再扩展高可用;
优势集中式管理数据,报警,不须要为每一个Prometheus
实例管理数据,若有些敏感节点报警要求高能够在Prometheus
数据节点上加报警信息,能够按功能环境划分启动多个Prometheus
采集实例;
缺点数据集中化,网络可能会延时,数据单点等问题;session
Prometheus
是支持远程读写TSDB
数据库,请看官方网站支持哪些数据库的读写,由于有些数据只支持写而不支持读,你内网搭建TSDB
集群,你全部启动的Prometheus
实例都把数据写入到远程数据库,再使用高可用方案支持查询,只支持远程读,这样就可无限扩展采集实例和查询实例,很是的爽,做者没有实践过只是YY中;网站
Metrics
远程写入TSDB
Prometheus
远程读TSDB