Prometheus集群+alertmanager集群+influxDB远程存储，实现监控高可用

服务器A ：192.168.1.190 （Prometheus、alertmanager）

服务器B ：192.168.1.206（Prometheus、alertmanager、influxdb、nginx）

基本HA + 远程存储

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

在B 上使用docker安装influxDB库

mkdir -p /data/infuxdb

vi  /data/infuxdb/docker-compose-monitor.yml

version: '2'
services:
  influxdb:
    image: influxdb
    container_name: influxdb
    hostname: influxdb
    restart: always
    command: -config /etc/influxdb/influxdb.conf
    ports:
      - "8086:8086"
      - "8083:8083"
    volumes:
      - /data/influxdb/conf:/etc/influxdb
      - /data/influxdb/data:/var/lib/influxdb/data 
      - /data/influxdb/meta:/var/lib/influxdb/meta
      - /data/influxdb/wal:/var/lib/influxdb/wal
    environment:
      - INFLUXDB_DB=prometheus
      - INFLUXDB_ADMIN_ENABLED=true
      - INFLUXDB_ADMIN_USER=admin
      - INFLUXDB_ADMIN_PASSWORD=xxx
      - INFLUXDB_USER=prom
      - INFLUXDB_USER_PASSWORD=xxx

启动后创建一个名称为 prometheus 的库

docker exec -it influxdb bash  
influx
create database prometheus

Prometheus集群

在A和B 上分别使用docker安装Prometheus

参照https://www.cnblogs.com/xiaoyou2018/p/14037006.html

A ：http://192.168.1.190:9090

B ：http://192.168.1.206.9090

在B 上安装nginx，使用nginx代理A和B 

[root@kibana vhost]# cat prometheus.conf 
upstream prom.midust.com{
        server 192.168.1.190:9090  max_fails=0 fail_timeout=0s weight=3;
        server 192.168.1.106:9090  max_fails=0 fail_timeout=0s weight=3;
        keepalive 300;
        }

    server {
        listen       80;
        server_name  prom.test.com;
        access_log /var/log/nginx/prom.midust.com.access.log;
        error_log  /var/log/nginx/prom.midust.com.error.log;
        # Load configuration files for the default server block.
        #include /etc/nginx/default.d/*.conf;

        location / {
             proxy_pass http://prom.test.com;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
                proxy_redirect default;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

解析之后，

访问 http://prom.test.com

A和B 上的Prometheus 接入 influxdb 

A 读和写

B只读

安装remote_storage_adapter 组件

链接：https://pan.baidu.com/s/1c0rWQhRg9QZpDb4eadkeOg
提取码：cu6n
放在 /data/prometheus目录

A和B 分别运行

nohup /data/prometheus/remote_storage_adapter --influxdb-url=http://192.168.1.206:8086 --influxdb.username=prom --influxdb.database=prometheus --influxdb.retention-policy=autogen &

A和B 上的Prometheus.yml 文件修改

A 的Prometheus.yml最后添加

remote_write:
  - url: "http://192.168.1.206:8086/api/v1/prom/write?db=prometheus&u=prom&p=xxx"

remote_read:
  - url: "http://192.168.1.206:8086/api/v1/prom/read?db=prometheus&u=prom&p=xxx"

B 的Prometheus.yml最后添加

remote_read:
  - url: "http://192.168.1.206:8086/api/v1/prom/read?db=prometheus&u=prom&p=TTdjy911.500"

稍等一会查看influxdb是否有数据

[root@localhost alertmanager-0.21.0.linux-amd64]# docker exec -it influxdb bash 
root@influxdb:/# influx
Connected to http://localhost:8086 version 1.8.3
InfluxDB shell version: 1.8.3
> use prometheus
Using database prometheus
> SHOW MEASUREMENTS

显示如下说明成功

管理influxDB 工具“InfluxDBStudio”

链接：https://pan.baidu.com/s/1c0rWQhRg9QZpDb4eadkeOg 
提取码：cu6n 

influxDB 设置保留数据期限：

Using database prometheus
> show retention policies
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------
autogen 2160h0m0s 168h0m0s 1 true

retention policy描述了influxdb中的数据会保留多长时间、数据保留几个副本（开源版的只能保留一个副本），以及每个shard保存多长时间的数据。每个influxdb数据库都有一个独立的retention policy。这里面涉及到几个基本概念，下面描述一下。

DURATION：这个描述了保留策略要保留多久的数据。这个机制对于时序型的数据来讲，是非常有用的。
SHARD：这个是实际存储influxdb数据的单元。每个shard保留一个时间片的数据，默认是7天。如果你保存1年的数据，那么influxdb会把连续7天的数据放到一个shard中，使用好多个shard来保存数据。
shard duration这个描述了每个shard存放多数据的时间片是多大。默认7天。需要注意的是，当数据超出了保留策略后，influxdb并不是按照数据点的时间一点一点删除的，而是会删除整个shard group。
SHARD GROUP：顾名思义，这个一个shard group包含多个shard。对于开源版的influxdb，这个其实没有什么区别，可以简单理解为一个shard group只包含一个shard，但对于企业版的多节点集群模式来讲，一个shard group可以包含不同节点上的不同shard，这使得influxdb可以保存更多的数据。
SHARD REPLICATION：这个描述了每个shard有几个副本。对于开源版来讲，只支持单副本，对于企业版来讲，每个shard可以冗余存储，这样可以避免单点故障。

默认数据一直保留

如果想修改retention policy的数据保留时间，可以使用alter retention policy语句

alter retention policy autogen on prometheus duration 30d  REPLICATION 1  SHARD DURATION 7d default

alertmanager集群

Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。

Gossip协议

Gossip是分布式系统中被广泛使用的协议，用于实现分布式节点之间的信息交换和状态同步。Gossip协议同步状态类似于流言或者病毒的传播，如下所示：

Gossip分布式协议

一般来说Gossip有两种实现方式分别为Push-based和Pull-based。在Push-based当集群中某一节点A完成一个工作后，随机的从其它节点B并向其发送相应的消息，节点B接收到消息后在重复完成相同的工作，直到传播到集群中的所有节点。而Pull-based的实现中节点A会随机的向节点B发起询问是否有新的状态需要同步，如果有则返回。在简单了解了Gossip协议之后，我们来看Alertmanager是如何基于Gossip协议实现集群高可用的。如下所示，当Alertmanager接收到来自Prometheus的告警消息后，会按照以下流程对告警进行处理：

通知流水线

• 在第一个阶段Silence中，Alertmanager会判断当前通知是否匹配到任何的静默规则，如果没有则进入下一个阶段，否则则中断流水线不发送通知
• 在第二个阶段Wait中，Alertmanager会根据当前Alertmanager在集群中所在的顺序(index)等待index * 5s的时间。
• 当前Alertmanager等待阶段结束后，Dedup阶段则会判断当前Alertmanager数据库中该通知是否已经发送，如果已经发送则中断流水线，不发送告警，否则则进入下一阶段Send对外发送告警通知。
• 告警发送完成后该Alertmanager进入最后一个阶段Gossip，Gossip会通知其他Alertmanager实例当前告警已经发送。其他实例接收到Gossip消息后，则会在自己的数据库中保存该通知已发送的记录。

因此如下所示，Gossip机制的关键在于两点：

Gossip机制

• Silence设置同步：Alertmanager启动阶段基于Pull-based从集群其它节点同步Silence状态，当有新的Silence产生时使用Push-based方式在集群中传播Gossip信息。

• 通知发送状态同步：告警通知发送完成后，基于Push-based同步告警发送状态。Wait阶段可以确保集群状态一致。

Alertmanager基于Gossip实现的集群机制虽然不能保证所有实例上的数据时刻保持一致，但是实现了CAP理论中的AP系统，即可用性和分区容错性。同时对于Prometheus Server而言保持了配置了简单性，Promthues Server之间不需要任何的状态同步。

下载alertmanager 组件，放在

https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz

A和B 都安装

tar zxvf alertmanager-0.21.0.linux-amd64.tar.gz -C /data/alertmanager/

服务器A 

vi /etc/systemd/system/alertmanager.service

[Unit]
Description=Alertmanager
After=network-online.target

[Service]
Restart=on-failure
ExecStart=/data/alertmanager/alertmanager-0.21.0.linux-amd64/alertmanager --web.listen-address=":9093" --cluster.listen-address="192.168.1.190:9094" --cluster.peer=192.168.1.206:9094 --config.file=/data/alertmanager/alertmanager-0.21.0.linux-amd64/alertmanager.yml

[Install]
WantedBy=multi-user.target

启动alertmanager

systemctl daemon-reload
systemctl start alertmanager
systemctl status alertmanager

服务器B

vi /etc/systemd/system/alertmanager.service

[Unit]
Description=Alertmanager
After=network-online.target

[Service]
Restart=on-failure
ExecStart=/data/alertmanager/alertmanager-0.21.0.linux-amd64/alertmanager --web.listen-address=":9093" --cluster.listen-address="192.168.1.206:9094"  --cluster.peer=192.168.1.190:9094  --config.file=/data/alertmanager/alertmanager-0.21.0.linux-amd64/alertmanager.yml

[Install]
WantedBy=multi-user.target

修改Prometheus.yml文件的Alertmanager configuration

验证：

关闭一台服务器的node_exporter

登录 http://192.168.1.190:9093 和  http://192.168.1.206:9093

都能看到接收到的告警信息，但是钉钉只接收到一条告警