服务器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 prometheusPrometheus集群
在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 defaultalertmanager集群
Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。
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
都能看到接收到的告警信息，但是钉钉只接收到一条告警
