高可用方案 | 易学教程

基本HA：服务可用性

此方案用户只需要部署多套Prometheus Server实例，并且采集相同的Exporter目标即可。

基本的HA模式只能确保Promthues服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Promthues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

基本HA + 远程存储

在基本HA模式的基础上通过添加Remote Storage存储支持，将监控数据保存在第三方存储服务上。

在保证Promthues服务可用性的基础上，同时确保了数据的持久化，当Promthues Server发生宕机或者数据丢失的情况下，可以快速的恢复。同时Promthues Server可能很好的进行迁移。因此，该方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保Promthues Server的可迁移性的场景。

基本HA + 远程存储 + 联邦集群

当单台Promthues Server无法处理大量的采集任务时，用户可以考虑基于Prometheus联邦集群的方式将监控采集任务划分到不同的Promthues实例当中，即在任务级别进行功能分区。

这种方案适用于两种场景：

场景一：单数据中心 + 大量的采集任务

这种场景下Promthues的性能瓶颈主要在于大量的采集任务，因此用户需要利用Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Promthues子服务中，从而实现功能分区。

场景二：多数据中心

这种模式也适合与多数据中心的情况，当Promthues Server无法直接与数据中心中的Exporter进行通讯时，在每一个数据中部署一个单独的Promthues Server负责当前数据中心的采集任务是一个不错的方式。这样可以避免用户进行大量的网络配置，只需要确保主Promthues Server实例能够与当前数据中心的Prometheus Server通讯即可。中心Promthues Server负责实现对多数据中心数据的聚合。

举例说明：

我们要监控mysqld的运行状态，可以使用1个主Prometheus+2个分片Prometheus(一个用来采集node_exporter的metrics、一个用来采集mysql_exporter的metrics)，然后在主Prometheus上做汇总

三台机器：

node1： prometheus2.0 （主）

node2：prometheus2.0 （采集node_exporter的metrics）

node3： prometheus2.0 （采集mysql_exporter的metrics）

node1:

修改prometheus.yml

scrape_configs:
- job_name: 'federate'
scrape_interval: 15s
honor_labels: true
metrics_path: '/federate'
params:
'match[]':
- '{job=~"prometheus.*"}'
- '{job="mysql"}'
static_configs:
- targets:
- 'node2:9091'
- 'node3:9092'

node2:

修改prometheus.yml

scrape_configs:

- job_name: 'prometheus25'

static_configs:
- targets: ['node2:9090']
- job_name: 'prometheus26'
static_configs:
- targets: ['node3:9090']

node3:

修改prometheus.yml

scrape_configs:

- job_name: 'mysqld'
static_configs:
- targets: ['node1:8089']

或者：

file_sd_configs:

- files: ['./mysqld.json']

cat mysqld.json
[
{
"targets": [
"node2:9104",
"node3:9104",
......
],
"labels": {
"services": "mysql_test",
}
}
]

来源：https://www.cnblogs.com/gschain/p/11697111.html

标签

数据中心

metrics