关于prometheus:重磅DIY的Prometheus主备方案全网唯一生产未上测试先行

对于 prometheus 的高可用计划，通过笔者一直的钻研、比照、和搜寻，发现不论是官网、还是各大搜索引擎搜寻进去的计划，都不合乎笔者的需要。因而，笔者本人设计了一套 prometheus 主备的计划。该计划是一个很 low 的计划，但通过一直的实际、验证，最初发现还挺实用。对于本计划，笔者当前还会找机会用 go 或者 python 开发一个带 UI 界面的 prometheus 主备管理器，让它的性能更加欠缺，做到更自动化和智能化。Prometheus 是监控畛域的新启之秀，后劲十分大，K8S 内置对它间接反对，间接有提供 exporter，而 K8S 又是将来基础架构的主力军。而监控方面，prometheus 成为将来的主力军是胜券在握，把它玩透了你相对不吃亏。好了，前戏有点多了。敬请大家的关注、点赞、转发。上面的正式进入主题！！！

DIY 的 prometheus 主备计划架构图

计划阐明

两台主机（master 和 slave）别离部署 keepalived，让 master 主机接管 VIP，留神：keepalived 倡议配置成非抢占模式
之所以采纳 VIP 的起因如下：
为了不便日常拜访 Prometheus 页面和 Alertmanager 页面，在主备切换时，可无需更换拜访 ip。
下层可视化利用（如 grafana）通过 VIP 来对接 Prometheus 的数据源，当主备切换时，无需在 grafana 上批改对应的数据源。
日常由 master 主机处于工作状态，在 master 中，启动 Promethues 和 Alertmanager 组件，启动 webhook 脚本（告警音讯推送脚本，用于将告警推送到其余平台）。
slave 主机备用状态，在 slave 中，须要启动 Promethues 组件（用于拉取指标数据），启动 Alertmanager 组件（用于接管警报音讯），这里留神，webhook 脚本需处于进行状态（不进行告警推送到其余平台）。这样做是为了躲避推送反复告警的问题，尽管 Alertmanager 有本身的去重告警性能，但这样的设计基本就没有告警反复，曾经将反复扼杀在摇篮里了。
在接入监控对象时（部署对应的 exporter），切记，仅须要在 master 上做配置即可， slave 定期从 master 拉取配置文件（包含主配置文件、警报规定文件等），定期和 master 放弃配置同步。
master 和 slave 的配置放弃同步，意味着两边都会拉取被监控对象的监控指标数据。监控指标的拉取、警报的触发两台均一起工作，但告警的推送只有 master 在负责，slave 不负责告警的推送，如果 master 不可用了，就须要将 slave 上的 webhook 脚本手动拉起来，由 slave 上的 webhook 脚本接管告警推送的工作。
配置文件同步的做法是采纳最原始、最简略、最粗犷的方法，master 和 slave 的配置文件同步计划如下：

Master 主机：

master 提供配置文件下载服务，由 python 自带的 SimpleHTTPServer 模块实现，且须要在 prometheus 或 alertmanager 标准装置门路下（如 /usr/local/prometheus）进行 SimpleHTTPServer 模块的启动，拉起后，默认的监听端口是 8000。
master 检测配置文件变动状况，如达到条件则触发备份和打包新的配置目录。在 master 上，设计了一个保留告诉动作的文件 notice_slave.action，配置发生变化写入 1，配置没有发生变化写入 0。同时，该检测脚本作为常驻过程在后盾运行。

Slave 主机：

slave 从 master 下载告诉动作的文件 notice_slave.action，依据状态码（1 和 0）来决定接下来的动作，如果是 1，则：从 master 下载配置压缩包、备份原有配置目录、解压新下载后的配置压缩包、热重启相干组件（prometheus、alertmanger），如果是 0 则什么都不做。

对于配置文件的同步，也是有两种实现形式的，要么是推，要么是拉，笔者的这个计划里是后者，笔者目前之所以折腾零散的 shell 脚本来去做高可用的治理，是为了能疾速解决需要，因而才做了这个简陋的计划，笔者的准则是：艰难的事件简略做，简略的事件咱不做（开玩笑哈！！！）。当然，笔者当前会通过 Go 或者 Python 打造一个治理 Promtheus 主备的工具，且是带 UI 的管理工具，敬请期待推出！我不造车，我只造整机。

角色	物理 IP	VIP	装置组件	告警推送形式
master	192.168.11.146	192.168.11.203（以后接管）	prometheus、alertmanager（均拉起）	webhook 形式，脚本拉起
slave	192.168.11.147		prometheus、alertmanager（均拉起）	webhook 形式，脚本不拉起（备用）

master 和 slave 主机的规范装置门路均为：/usr/local/，笔者装置组件后的环境如下:

/usr/local/keepalived（留神：倡议 keepalived 配置成非抢占模式）/usr/local/prometheus
/usr/local/alertmanager

至于装置门路的标准，请自行依据理论状况敲定。

所有配置文件统一标准门路：/usr/local/prometheus/conf/
prometheus 主配置文件：/usr/local/prometheus/conf/prometheus.yml
按业务粒度，一个业务对应一个目录，业务下不同的监控对象都放在对应的业务目录下：/usr/local/prometheus/conf/business

特地阐明 1：请自行在 prometheus 组件的装置目录下创立 conf 目录，并将默认的 prometheus.yml 配置文件挪动进去

特地阐明 2：请自行在 prometheus 组件的配置文件统一标准门路（./conf）下创立业务目录 business

特地阐明 3：业务目录下，又蕴含两个目录：job 和 rule，job 用于寄存监控拉取配置文件，rule 用于寄存警报规定配置文件

配置文件目录和业务目录布局示范，如下:

/usr/local/prometheus/ # 这是标准的装置门路
/usr/local/prometheus/conf/ # 这是标准的配置目录
/usr/local/prometheus/conf/prometheus.yml # 这是主配置文件
/usr/local/prometheus/conf/business 这是按业务粒度布局的业务根目录

# 如下是业务 A 的布局案例：/usr/local/prometheus/conf/business/a_business/ 这是业务 a 的目录
/usr/local/prometheus/conf/business/a_business/job/oracle.yml 这是业务 a 下拉取 oracle 监控配置数据的 yml 配置文件
/usr/local/prometheus/conf/business/a_business/rule/oracle.rules 这是业务 a 下 oracle 的警报规定 rules 配置文件

特地阐明：上述对业务 A 的配置文件布局案例十分重要，请务必参照此标准。

对于 Alertmanager 组件的配置文件，相对来说没 prometheus 那么简单，次要的布局还是在 prometeus 中

alertmanager 的主配置文件统一标准门路放在 prometeheus 的 conf 中：/usr/local/prometheus/conf/alertmanager.yml

在 master 主机上，会主动备份原有的 conf 配置文件目录

Prometheus 组件

对立备份门路为：/usr/local/prometheus/backup/
Alertmanager 组件

不波及到备份

在 master 主机和 slave 主机上运行的脚本日志均对立寄存在指定目录

Prometheus 组件

对立日志目录：/usr/local/prometheus/logs/
AlertManager 组件

对立日志目录：/usr/local/alertmanager/logs/

留神：master 和 slave 均须要装置如下组件

keepalived 高可用组件
prometheus 监控组件
alertmanager 警报组件

因组件的装置部署不是本文的主题，所以笔者在这里就不再撰写装置步骤，在此省略了哈，请自行装置好即可。

阐明 1：均须要在 master 和 slave 上部署文件同步相干脚本

阐明 2：以下的每一步操作，请均进入到“/usr/local/prometheus/”目录下进行操作（此目录是之前曾经定为装置标准的目录），如您的标准目录和笔者的不同，请进入到您本人的标准目录下。

阐明 3：以下波及的脚本，波及的目录：conf、backup、logs、cfmd5，请自行在标准的目录下进行创立即可。

通过 python 拉起简略的 Http 服务，默认监听端口为 8000，创立脚本 startPromconfSyncApi.sh

startPromconfSyncApi.sh 脚本内容如下：

#!/bin/sh
nohup /usr/bin/python -m SimpleHTTPServer > /dev/null &

运行配置文件下载服务的脚本

sh startPromconfSyncApi.sh

拉起 http 服务脚本后查看端口

[root@prosvr-master prometheus]# netstat -tulnp | grep 8000
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      1293/python         
[root@prosvr-master prometheus]#

创立配置文件变动查看脚本 startTarPackConf.sh

留神，请在标准的装置门路 /usr/local/prometheus/ 上面创立 startTarPackConf.sh 脚本，以及创立目录 cfmd5

startTarPackConf.sh 脚本内容：

#!/bin/sh
time_log=`date "+%Y-%m-%d %H:%M:%S"`
echo "${time_log} 配置查看器启动"

task_wait_sec=4

find ./conf -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.list

while true
do
  time_bak=`date "+%Y%m%d%H%M%S"`
  time_log=`date "+%Y-%m-%d %H:%M:%S"`

  md5sum -c ./cfmd5/cfmd5.list > ./cfmd5/check_cfmd5.log
  md5ret=`cat ./cfmd5/check_cfmd5.log | grep "FAILED" | wc -l`

  while true
  do
    if [${md5ret} -gt 0 ]
    then
      echo "${time_log} 配置文件发生变化，触发备份和打包压缩"
      mv ./conf.tar.gz ./backup/conf.tar.gz_bak_${time_bak}
      tar -zcf conf.tar.gz conf/
      echo 1 > ./notice_slave.action
      curl -X POST http://127.0.0.1:9090/-/reload
      break
    else
      echo 0 > ./notice_slave.action
      break
    fi
  done
  find ./conf -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.list
  sleep ${task_wait_sec}
done

脚本实现阐明：很简略，就是递归搜寻 conf 目录下的所有配置文件且生成 md5 值保留在./cfmd5/cfmd5.list，并应用 md5sum - c 实时查看./cfmd5/cfmd5.list 中的文件 md5 值是否有变动，且将后果输入到./cfmd5/check_cfmd5.log，再通过 cat ./cfmd5/check_cfmd5.log 进行过滤 ”FAILED” 并统计，只有呈现有 ”FAILED”，就认为配置文件有产生过变动，要么是减少了，要么是现有的配置文件做了批改。统计的后果保留在 md5ret 变量，判断条件就是 md5ret 后果大于 0 就触发南方和打包压缩配置目录，同时 master 中的配置文件发生变化后，也会主动触发热重启。接着将状态码 1 写入到./notice_slave.action 文件中，如果没有变动，将状态码就是 0。notice_slave.action 文件是存储状态变动的（在这里就罗唆叫告诉文件吧！）。

对于告诉文件（notice_slave.action）设计的具体阐明：对 slave 端来讲，由 slave 被动拉取这个告诉文件并读取后果，如果是 1 就触发拉取 master 打包好的压缩目录并解压，且持续热重启相应的组件，如果是 0 就啥也不干。

对于参数 task_wait_sec=4，工作等待时间，master 目前配置的是 4 秒，也就是每隔 4 秒检测一次。对于 slave 端，也有一个 pull_wait_sec= 2 参数（目前是 2 秒），也就是每隔 2 秒拉取一次告诉文件，并做判断。这里要留神，slave 的 pull_wait_sec 拉取工夫肯定要小于 master 的 task_wait_sec 工夫，别问为什么，本人思考去。

拉起配置文件变动查看脚本

# 拉起
nohup sh ./startTarPackConf.sh >> ./logs/tar_pack.log &

查看过程

[root@prosvr-master prometheus]# ps -aux | grep tar
root       2473  0.0  0.3 113284   848 pts/1    S    09:48   0:02 sh start_tar_pack_conf.sh

拉起后会作为后盾过程常驻，须要进行的话，查看 pid，而后 kill 掉即可。

创立启动 prometheus 组件，脚本 startPrometheusSvr.sh

startPrometheusSvr.sh 内容：

#!/bin/sh
nohup ./prometheus --storage.tsdb.retention.time=180d --web.enable-lifecycle --config.file=./conf/prometheus.yml --log.level=warn --log.format=json >> ./logs/prometheus_run_status.log &

数据保留周期是 180 天，请依据理论状况调整，其余参数的意义请自行 help

在下面脚本的启动参数中，也能够通过参数 –storage.tsdb.path=”data/” 批改本地数据存储的门路，不指定的话，时序数据默认是在 prometheus 的 data 目录下，如需批改数据的存储门路，倡议寄存在性能好（SSD、高端磁盘阵列）、容量大的目录中。

接着启动 prometheus

# 拉起
[root@prosvr-master prometheus]# sh startPrometheusSvr.sh

查看过程，查看是否启动胜利

[root@prosvr-master prometheus]# ps -aux | grep prometheus
root       1201  0.0 30.1 1100628 66840 pts/0   Sl   08:45   0:22 ./prometheus --web.enable-lifecycle --config.file=./conf/prometheus.yml --log.level=warn --log.format=json

为了不便热重启操作，创立脚本 hot_restart_prometheus.sh，当批改了配置文件后，就手动执行这个脚本进行热重启
```
#!/bin/sh
curl -X POST http://127.0.0.1:9090/-/reload
```
平滑重启示例
```
[root@prosvr-master prometheus]# sh hot_restart_prometheus.sh 
```
在日常保护中，当配置文件产生了变更就能够利用该脚本进行平滑重启

创立汇总启动脚本 start_all.sh

#!/bin/sh
sh ./startPromconfSyncApi.sh
nohup sh ./startTarPackConf.sh >> ./logs/tar_pack.log &
sh ./startPrometheusSvr.sh

当前就不必一个一个脚本拉起了，间接拉起该脚本即可一并启动

为了减少安全性，仅容许 slave 主机拜访配置文件拉取服务的端口（笔者这里是 8000 端口）

在 tcp 协定中禁止所有的 ip 拜访本机的 8000 端口，仅容许 slave 主机（192.168.11.147）拜访本机的 8000 端口（留神按程序执行）

iptables -I INPUT -p tcp --dport 8000 -j DROP
iptables -I INPUT -s 192.168.11.147 -p tcp --dport 8000 -j ACCEPT

查看规定

[root@prosvr-master prometheus]# iptables -nvL
Chain INPUT (policy ACCEPT 9 packets, 744 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    8   552 ACCEPT     tcp  --  *      *       192.168.11.147       0.0.0.0/0            tcp dpt:8000
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8000

保留规定

留神：应用此命令的规定地位能够是任意的，此形式保留的规定在重启机器后无奈主动失效，须要应用命令 iptables-restart 复原），笔者这里是保留在了 /etc/sysconfig/my-iptable-rule-script

# 保留
[root@prosvr-master prometheus]# iptables-save > /etc/sysconfig/my-iptable-rule-script

# 查看
[root@prosvr-master prometheus]# cat /etc/sysconfig/my-iptable-rule-script
# Generated by iptables-save v1.4.21 on Mon May 30 10:37:12 2022
*filter
:INPUT ACCEPT [49:4408]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:4840]
-A INPUT -s 192.168.11.147/32 -p tcp -m tcp --dport 8000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8000 -j DROP
COMMIT
# Completed on Mon May 30 10:37:12 2022

手动清空规定，模仿规定失落后，从文件中加载

# 查看
[root@prosvr-master prometheus]# iptables -nvL
Chain INPUT (policy ACCEPT 122 packets, 12944 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       192.168.11.147       0.0.0.0/0            tcp dpt:8000
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8000

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 86 packets, 14400 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[root@prosvr-master prometheus]# 

# 手动清空
[root@prosvr-master prometheus]# iptables -F

# 清空后查看
[root@prosvr-master prometheus]# iptables -nvL
Chain INPUT (policy ACCEPT 12 packets, 1056 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 7 packets, 1080 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[root@prosvr-master prometheus]# 

# 应用 iptables-restore 命令还原 iptables-save 命令所备份的 iptables 配置
[root@prosvr-master prometheus]# iptables-restore < /etc/sysconfig/my-iptable-rule-script 

# 还原后查看
[root@prosvr-master prometheus]# iptables -nvL
Chain INPUT (policy ACCEPT 34 packets, 2992 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       192.168.11.147       0.0.0.0/0            tcp dpt:8000
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8000

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 18 packets, 2480 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[root@prosvr-master prometheus]#

特地阐明：预防规定重启后失落的方法还有一种，就是将配置规定写入到启动文件中，如 /etc/rc.local，笔者之前将规定保留在 /etc/sysconfig/my-iptable-rule-script 文件中，那么就能够将复原的命令 iptables-restore < /etc/sysconfig/my-iptable-rule-script 写入到 /etc/rc.local 中

特地留神：如果您的环境和笔者不一样，请自行更改为您本人的 IP 和端口即可。

创立汇总进行脚本 stop_all.sh

#!/bin/sh
ps -aux | grep SimpleHTTPServer | grep -v grep | awk '{print $2}' | xargs kill
ps aux | grep startTarPackConf.sh | grep -v grep | awk '{print $2}' | xargs kill
ps -aux | grep -v grep | grep prometheus | awk '{print $2}' | xargs kill

日常保护中，如有须要进行全副服务的需要，运行该脚本即可。

特地阐明：在 slave 主机上，请在标准的目录下创立 conf、logs、backup 目录

将首次装置实现的 prometheus.yml 文件挪动到以后的 conf 目录下
```
mv ./prometheus.yml ./conf/
```
之所以要挪动 slave 自身的 prometheus.yml，是因为要从 master 同步过去曾经布局好的 conf 配置目录，拉取后会笼罩 slave 上的 conf 目录，当前都以 master 的配置为主
筹备启动 prometheus 组件的脚本
脚本 /usr/local/prometheus/startPrometheusSvr.sh，代码：
```
#!/bin/sh
nohup ./prometheus --storage.tsdb.retention.time=180d --web.enable-lifecycle --config.file=./conf/prometheus.yml --log.level=warn --log.format=json >> ./logs/prometheus_run_status.log &
```
数据保留周期是 180 天，请依据理论状况调整，其余参数的意义请自行 help

在下面脚本的启动参数中，也能够通过参数 –storage.tsdb.path=”data/” 批改本地数据存储的门路，不指定的话，时序数据默认是在 prometheus 的 data 目录下，如需批改数据的存储门路，倡议寄存在性能好（SSD、高端磁盘阵列）、容量大的目录中。

接着启动 prometheus，并查看是否启动胜利

[root@prosvr-slave prometheus]# sh startPrometheusSvr.sh
[root@prosvr-slave prometheus]# ps -aux | grep prometheus
root       5107  3.7 16.0 768960 35456 pts/0    Sl   17:18   0:00 ./prometheus --web.enable-lifecycle --config.file=./conf/prometheus.yml --log.level=warn --log.format=json
root       5114  0.0  0.4 112812   976 pts/0    R+   17:18   0:00 grep --color=auto prometheus
You have new mail in /var/spool/mail/root

[root@prosvr-slave prometheus]# netstat -tulnp | grep prometheus
tcp6       0      0 :::9090                 :::*                    LISTEN      5107/./prometheus   
[root@prosvr-slave prometheus]#

筹备从 master 拉取配置文件目录的脚本 startUpdateSyncConf.sh，代码：

#!/bin/sh
time_log=`date "+%Y-%m-%d %H:%M:%S"`
echo "${time_log} 配置更新器启动"

pull_wait_sec=2

while true
do
  wget http://192.168.11.146:8000/notice_slave.action -O notice_slave.action > /dev/null 2>&1
  status=`cat ./notice_slave.action`
  if [${status} -eq 1 ]
  then
 time_bak=`date "+%Y%m%d%H%M%S"`
 time_log=`date "+%Y-%m-%d %H:%M:%S"`
 echo "${time_log} 从 master 下载配置压缩包文件"
 wget http://192.168.11.146:8000/conf.tar.gz -O conf.tar.gz
 echo "${time_log} 备份原有的配置目录"
 mv ./conf ./backup/conf_bak_${time_bak}
 echo "${time_log} 解压下载后的配置压缩包"
 tar -zxf conf.tar.gz
 echo "${time_log} 热重启 prometheus 服务"
 curl -X POST http://127.0.0.1:9090/-/reload
  fi
  sleep ${pull_wait_sec}
done

pull_wait_sec 参数管制每隔工夫工作一次，首先会从 master 中拉取告诉文件 notice_slave.action，并读取外面的后果，如果是 1，则阐明 master 上的配置文件有变动，接着会执行一系列操作。如果是 0，则什么也不做。

创立热重启的脚本 hot_restart_prometheus.sh
```
#!/bin/sh
curl -X POST http://127.0.0.1:9090/-/reload
```
日常保护中，在 slave 主机上，如有必要时不便手动执行热重启
创立汇总启动脚本 start_all.sh
```
#!/bin/sh
nohup sh startUpdateSyncConf.sh > ./logs/update_sync.log &
sleep 3
sh ./startPrometheusSvr.sh
```
日常保护中，如需一次性拉起服务，执行该脚本即可

创立汇总进行脚本 stop_all.sh

#!/bin/sh
ps -aux | grep startUpdateSyncConf.sh | grep -v grep | awk '{print $2}' | xargs kill
ps -aux | grep -v grep | grep prometheus | awk '{print $2}' | xargs kill

日常保护中，如需一次性进行服务，执行该脚本即可

prometheus 如何监控 mysql？很简略，只须要在运行 mysql 的主机上安装 mysqld_exporter，mysqld_exporter 的用处是啥？说白了它就是用来收集 mysql 数据库相干指标的程序（官网就有，而且是 go 语言写的），mysqld_exporter 启动后默认监听 9104 端口（当然启动时能够通过相应参数进行更改），且它连贯上数据库采集相应指标，并等着 prometheus 服务器来拉取。所以，须要在 mysql 中创立一个专门用于采集监控指标的数据库账号，让 mysqld_exporter 通过这个账号去登录数据库采集指标，且这个账号要有相干权限（适合的权限即可）。所以的适合，请自行依据理论状况决定要给什么权限，如果是生产环境，个别的准则是：最小准则、够用就好。

mysql 测试环境信息
以下是笔者的 mysql 测试环境

数据库	操作系统	IP
mysql8.0	centos7	192.168.11.150

阐明：本篇只解说如何应用 Prometheus 监控 MySQL，MySQL 自身的装置过程不在本篇范畴内，请自行将 MySQL 装置好。

下载 mysqld_exporter

wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.14.0/mysqld_exporter-0.14.0.linux-amd64.tar.gz

登录 mysql 创立用于采集指标数据的专有账户

# 创立账号
mysql> create user 'exporter_user'@'localhost' identified by 'Root.123456' with max_user_connections 3;
Query OK, 0 rows affected (0.06 sec)

# 受权
mysql> grant process, replication client, select on *.* to 'exporter_user'@'localhost';
Query OK, 0 rows affected (0.00 sec)

# 刷新权限
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

# 查看权限
mysql> show grants for exporter_user@localhost\G;  
*************************** 1. row ***************************
Grants for exporter_user@localhost: GRANT SELECT, PROCESS, REPLICATION CLIENT ON *.* TO `exporter_user`@`localhost`
 1 row in set (0.00 sec)
ERROR: 
No query specified
# 查看账号
mysql> select user,host from mysql.user;
+------------------+-----------+
| user             | host      |
+------------------+-----------+
| exporter         | localhost | # 这个，笔者已经创立过的，不论它了
| exporter_user    | localhost | # 这个是刚刚创立好的，就用这个啦！| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
| ttr1             | localhost |
+------------------+-----------+
rows in set (0.00 sec)
mysql>
 对于 mysql 的数据库账号权限的受权和回收的常识，笔者当前会出一个专题，专门深入浅出的分析，敬请大家的关注！

部署 mysqld_exporter

# 下载实现后，解压，并挪动到规定的目录下（目录可自定义哈）tar -zxf mysqld_exporter-0.14.0.linux-amd64.tar.gz 
[root@mysql8db ~]# mkdir /usr/local/exporter/
[root@mysql8db ~]# mv mysqld_exporter-0.14.0.linux-amd64 /usr/local/exporter/mysqld_exporter
[root@mysql8db ~]# cd /usr/local/exporter/mysqld_exporter/
[root@mysql8db mysqld_exporter]# ll
total 14824
-rw-r--r-- 1 3434 3434    11357 Mar  5 00:30 LICENSE
-rwxr-xr-x 1 3434 3434 15163162 Mar  5 00:25 mysqld_exporter # 这个就是可执行程序
-rw-r--r-- 1 3434 3434       65 Mar  5 00:30 NOTICE

创立连贯 mysql 的配置文件并启动 mysqld_exporter

# 创立连贯 mysql 的配置文件
[root@mysql8db mysqld_exporter]# cat > exporter_conn_mysql.conf <<EOF
> [client]
> user=exporter_user
> password=Root.123456
> EOF
# 查看创立好的配置文件
[root@mysql8db mysqld_exporter]# cat exporter_conn_mysql.conf 
[client]
user=exporter_user
password=Root.123456
[root@mysql8db mysqld_exporter]#

启动 mysqld_exporter

# 为了不便启动，创立一个启动脚本
[root@mysql8db mysqld_exporter]# cat > start_mysqld_exporter.sh <<EOF
> nohup ./mysqld_exporter --config.my-cnf=./exporter_conn_mysql.conf &
> EOF
[root@mysql8db mysqld_exporter]#
# 查看创立好的启动脚本 
[root@mysql8db mysqld_exporter]# cat start_mysqld_exporter.sh 
nohup ./mysqld_exporter --config.my-cnf=./exporter_conn_mysql.conf &
[root@mysql8db mysqld_exporter]# 
# 开始启动
[root@mysql8db mysqld_exporter]# sh start_mysqld_exporter.sh 
# 启动后查看相干端口（默认的端口为 9104）[root@mysql8db mysqld_exporter]# netstat -tulnp | grep mysql
tcp6       0      0 :::33060                :::*                    LISTEN      1916/mysqld         
tcp6       0      0 :::3306                 :::*                    LISTEN      1916/mysqld         
tcp6       0      0 :::9104                 :::*                    LISTEN      2073/./mysqld_expor # 这个就是啦！[root@mysql8db mysqld_exporter]# 
[root@mysql8db mysqld_exporter]#

阐明：咦！–config.my-cnf 这个参数我咋晓得的？当然是能够应用 help 啦! 这样 ./mysqld_exporter –help 就能够晓得有哪些选项啦！

还有一个奇怪的问题，怎么只有 ipv6 在监听？没有 IPV4？其实不是啦！centos7 以上，都是 ipv6 优先的准则，对 ipv6 的反对默认是开启的，ipv4 其实也是有在监听的啦!

启动后，通过浏览器拜访指标页面
裸露的 HTTP 服务地址（http://192.168.11.150:9104/me…）

看到这些指标了吗？Prometheus 服务端会周期性的从 Exporter 裸露的 HTTP 服务地址（通常是 /metrics）拉取监控样本数据。

指标内容简略阐明：
HELP：用于解释以后指标的含意
TYPE：阐明以后指标的数据类型

比方上面的一个指标
```
# HELP mysql_up Whether the MySQL server is up. # MySQL 服务器是否启动
# TYPE mysql_up gauge # 指标的数据类型是 gauge，测量、检测的意思，也有仪表盘的意思？mysql_up 1 # mysql_up 反馈以后的状态，以后的值为 1，阐明是启动的，也可能为 0（进行状态）
```
笔者去把 Mysql 给进行了，再次刷新指标页面，查看这个指标，发现的确变成了 0

查看采集过程输入的相干信息

刚刚是通过 nohup 将 mysqld_exporter 程序丢入到后盾启动的，所以相干的输入信息默认是会写入 nohup.out 文件中

[root@mysql8db mysqld_exporter]# tailf nohup.out 
ts=2022-05-21T13:40:01.735Z caller=mysqld_exporter.go:277 level=info msg="Starting mysqld_exporter" version="(version=0.14.0, branch=HEAD, revision=ca1b9af82a471c849c529eb8aadb1aac73e7b68c)"
ts=2022-05-21T13:40:01.735Z caller=mysqld_exporter.go:278 level=info msg="Build context" (gogo1.17.8,userroot@401d370ca42e
...
...

到此为止，在 Mysql 服务器主机上部署 mysqld_exporter 的工作算是功败垂成。

接下来回到 Prometheus Master 中持续以下的操作

在 Prometheus Master 中配置从 mysqld_exporter 收集监控数据

在 Master 中的 prometheus 主配置文件中的 scrape_configs 配置项增加基于文件的主动发现 job

肯定要留神：只需在 master 上做相干配置，slave 主机会定时拉取 master 的配置目录和 master 放弃同步，且 slave 的配置产生变更还会主动热重启使其失效，也就是说 slave 不必你操心，你只需治理好你的 master 就好。

再罗嗦一次：以下操作仅在 master 上操作。

在主配置文件 /usr/local/prometheus/conf/prometheus.yml 中增加测试业务 A 的 job

阐明：上面的 job_name 为 prometheus_server 是拉取 prometheus 自身的指标数据（也就是监控其自身），IP 地址是指向 VIP：192.168.11.203，指向 VIP 这是倡议的做法。
```
scrape_configs:
  - job_name: 'prometheus_server'
 static_configs:
 - targets: ['192.168.11.203:9090']

  - job_name: '测试业务 A'
 file_sd_configs:
 - files:
   - './business/test_bus_a/job/*.yml'
   refresh_interval: 1s
```
参数阐明：
‘ 测试业务 A ’ 的 job_name：定义自发现的采集工作名称，按业务的维度进行定义名称，笔者这里叫“测试业务 A”
file_sd_configs：这是基于文件的主动发现，即 <file_sd_configs>，上面这块配置都是和 file_sd_configs 无关的，具体阐明如下:
```
 file_sd_configs: # 指定这是基于文件的主动发现
 - files:
   - './business/test_bus_a/job/*.yml' # 指定主动发现配置文件的门路，这里示意在该门路下发现所有.yml 格局的配置文件
   refresh_interval: 1s # 主动发现距离，工夫默认是 5 秒，笔者这里设置了 1 秒。
```
在布局好的业务目录（business）下创立对应的业务文件夹：test_bus_a，以及在业务目录 test_bus_a 上面创立 job 目录，并进入 job 目录创立 mysql.yml（该名称可自定义，也可叫 mon_mysql.yml 或者其余，次要你喜爱就好！）在 mysql.yml 中定义拉取 mysql 的监控指标数据
./conf/business/test_bus_a/job/mysql.yml 的内容如下：

参数阐明：
targets：拉取指标，这里指向 mysql 服务器的 IP 地址，mysqld_exporter 的端口是 9104
labels：这是标签，标签的次要作用是能够通过指定的标签查问指定的数据。

标签的作用：Prometheus 中存储的数据为工夫序列，是由 Metric 的名字和一系列的标签 (键值对) 惟一标识的, 不同的标签代表不同的工夫序列，即通过指定标签查问指定数据。不同的标签代表不同的工夫序列，即通过指定标签查问指定数据。指标 + 标签实现了查问条件的作用，能够指定不同的标签过滤不同的数据。

在 Prometheus UI 中对应的 Labels 信息如下图可见：

假如有个需要，须要晓得被监控的 mysql 服务器所在的机房地位，那么就能够减少一个自定义标签，如下：
./conf/business/test_bus_a/job/mysql.yml

在 Prometheus UI 中能够看到：
不论你是用 VIP、还是 master、slave 的物理 IP 去拜访 UI，后果都一样的，不信你试试。

自定义标签的次要利用场景：有了这些标签能够针对特定的标签去查问，比方笔者在下面的假如需要中，须要定义一个依据自定义标签 region 作为标识机房地位。总而言之，增加的标签越多，查问的维度就会越细。

在 UI 界面中的 Graph 面板中应用 PromQL 表达式查问特定监控指标的监控数据，如下查问“mysql_up”指标，如下图：

PromQL 是 Prometheus 自定义的一套弱小的数据查询语言，除了应用监控指标作为查问关键字认为，还内置了大量的函数，帮忙用户进一步对时序数据进行解决。例如应用 rate()函数，能够计算在单位工夫内样本数据的变动状况即增长率，通过 PromQL 咱们能够十分不便的对数据进行查问，过滤，以及聚合，计算等操作。通过这些丰盛的表达式语句，监控指标不再是一个独自存在的个体，而是一个个可能表白出正式业务含意的语言。当然，对于更多的 PromQL 常识，当前笔者会缓缓分享，本篇的重点是主备架构，可别跑题了呢！

五、监控主机案例

为了可能采集到主机的运行指标如 CPU, 内存，磁盘等信息。能够应用 Node Exporter。Node Exporter 同样采纳 Golang 编写，并且不存在任何的第三方依赖，只须要下载，解压即可运行。

下载 node_exporter 并解压以及部署到指定目录

wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
tar -zxf node_exporter-1.3.1.linux-amd64.tar.gz
mv node_exporter-1.3.1.linux-amd64 /usr/local/exporter/node_exporter
cd /usr/local/exporter/node_exporter/

可通过 help 查看一堆启动参数

[root@mysql8db node_exporter]# ./node_exporter --help
usage: node_exporter [<flags>]

 Flags:
  -h, --help                     Show context-sensitive help (also try --help-long and --help-man).
   --collector.bcache.priorityStats  
                              Expose expensive priority stats.
   --collector.cpu.guest      Enables metric node_cpu_guest_seconds_total
   --collector.cpu.info       Enables metric cpu_info
...
...

启动 node_exporter

# 丢入后盾运行
[root@mysql8db node_exporter]# nohup ./node_exporter &
# 查看监听的端口
[root@mysql8db node_exporter]# netstat -tulnp | grep node_exporte
tcp6       0      0 :::9100                 :::*                    LISTEN      1935/./node_exporte 
[root@mysql8db node_exporter]# 
# 通过 nohup 丢入后盾运行，相干的输入会追加到 nohup.out 文件中，必要时可查看该文件诊断相干问题
[root@mysql8db node_exporter]# tailf nohup.out 
ts=2022-06-04T00:45:58.822Z caller=node_exporter.go:115 level=info collector=thermal_zone
ts=2022-06-04T00:45:58.822Z caller=node_exporter.go:115 level=info collector=time
ts=2022-06-04T00:45:58.822Z caller=node_exporter.go:115 level=info collector=timex
ts=2022-06-04T00:45:58.822Z caller=node_exporter.go:115 level=info collector=udp_queues
...
...

笔者没啥非凡的需要，所以无需额定在给定启动参数，间接丢入后盾运行即可，默认的监听端口是 9100

通过浏览器查看 node_exporter 裸露的指标
在 prometheus 的 master 服务器中配置从 node_exporter 收集监控数据

假如笔者的这台主机是测试业务 b（test_bus_b）的一台主机，请依照之前的业务目录标准，在标准的业务目录（conf/business）下创立业务文件夹 test_bus_b。

再次罗嗦一次：仅需在 master 上做配置即可，slave 会定时拉取 masetr 的配置目录，不要去管 slave，OK？一个大男人那么罗嗦，真的很惹人讨厌啊！

在主配置文件中增加业务 B 的 job

主配置文件：/usr/local/prometheus/conf/prometheus.yml

scrape_configs:
  - job_name: 'prometheus_server'
 static_configs:
 - targets: ['192.168.11.203:9090']

  - job_name: '测试业务 A'
 file_sd_configs:
 - files:
   - './business/test_bus_a/job/*.yml'
   refresh_interval: 1s

  - job_name: '测试业务 B' # 这是新减少的测试业务 B
 file_sd_configs:
 - files:
   - './business/test_bus_b/job/*.yml'
   refresh_interval: 1s

在标准的业务目录（conf/business）下创立业务文件夹 test_bus_b，而后创立 host.yml，减少 targets（拉取指标）的配置

[root@prosvr-master business]# cd /usr/local/prometheus/conf/business/
[root@prosvr-master business]# mkdir test_bus_b
[root@prosvr-master business]# cd test_bus_b/
[root@prosvr-master business]# mkdir job
[root@prosvr-master business]# cd job/

targets:
- ‘192.168.11.150:9100’
  labels:
ip: ‘192.168.11.150’
monitype: ‘linux-centos7’
project: ‘ 测试业务 B ’
business: ‘ 测试业务 B ’
region: ‘ 深圳机房 ’
不论你是用 VIP、还是 master、slave 的物理 IP 去拜访 UI，后果都一样的，不信你试试。

十分不错，只有检测到配置文件发生变化，master 会主动热重启，slave 也会主动拉取配置目录而后热重启，十分的省心、省力。自我感觉这个 DIY 的主备计划简直靠近完满，尽管没有用很高大上的语言、工具去实现，但笔者的这个思路自我感觉是十分的不错，这难道就是传说中的自我感觉良好？当然，笔者当前会通过 Go 或者 Python 打造一个治理 Promtheus 主备的工具，且是带 UI 的管理工具，敬请期待推出！我不造车，我只造整机。

六、AlertManager 警报组件配置

阐明：基于二进制包的 alertmanager 组件请自行在 master 和 slave 中装置部署到标准的目录，之后持续上面的步骤。
1. 挪动 master 和 slave 上的警报组件的主配置文件 alertmanager.yml
  在 master 和 slave 服务器上，alertmanager 组件的二进制包解压到标准的目录后，将警报的主配置文件“alertmanager.yml”挪动到 prometheus 组件的 conf 目录下
```
# 挪动后（也就是用 mv 命令挪动），查看如下：[root@prosvr-master conf]# pwd
/usr/local/prometheus/conf
[root@prosvr-master conf]# ll
total 12
-rw-r--r-- 1 3434 3434  348 Jun  4 13:26 alertmanager.yml # 警报组件的主配置文件曾经也在 prometheus 组件下的 conf 目录
drwxr-xr-x 4 root root   42 Jun  4 09:18 business
-rw-r--r-- 1 3434 3434 1033 Jun  4 12:27 prometheus.yml
```

特地留神：上述操作，在 master 和 slave 上都要操作，且在 slave 服务器挪动 alertmanager.yml 配置文件后，往后就能够不必去管 slave 上的 alertmanager.yml 配置文件了，次要的配置变更都在 master 上进行就好，如果有变更，slave 会主动拉取配置目录。通常警报组件的 alertmanager.yml 配置文件一旦配置好后，改变的频率比拟少。

特地阐明：之所以这么设计，有两个益处：1）配置的变更都在同一个目录下进行；2）利用了现有 master 和 slave 的配置目录同步能力

在 master 上配置警报的主配置文件 /usr/local/prometheus/conf/alertmanager.yml
在警报组件中配置告警音讯发往的接口地址, 让其能够调用接口，配置形式很简略，只须要指定一下接口地址即可
```
[root@prosvr-master conf]# 
global:
 resolve_timeout: 5m
route:
 group_by: [...]
 group_wait: 1s
 group_interval: 1s
 repeat_interval: 1000d
 receiver: 'web.hook'
receivers:
name: 'web.hook'
 webhook_configs:
 - url: 'http://127.0.0.1:5001/webhook'
send_resolved: true
```
上述配置中，次要蕴含两大部分，路由（route）和接收器（receivers），所有的告警信息都会从配置中的顶级路由 (route) 进入路由树，依据路由规定将告警信息发送给相应的接收器。本篇次要是配置接收器，应用 webhook 的形式，假如是将告警音讯推送到第三方平台。当然，在本篇仅为示例，打印进去而已。

在 master 和 slave 上创立 Alertmanager 组件启动脚本
留神：该步骤肯定要进入到 /usr/local/alertmanager/ 目录下进行操作
创立脚本，名称：startAlertManagerSvr.sh
```
#!/bin/sh
nohup ./alertmanager --config.file=/usr/local/prometheus/conf/alertmanager.yml >> ./logs/alert.log &
[root@prosvr-master alertmanager]# 
```
留神：startAlertManagerSvr.sh 脚本在 masetr 和 slave 中都要创立，且 –config.file 应用绝对路径指向 alertmanager.yml

通过该脚本拉起 alertmanager 组件
```
sh startAlertManagerSvr.sh
```
留神：master 和 slave 都要拉起

启动后，通过 VIP 或 master 和 slave 的物理 IP 都能够拜访到警报的页面，笔者这里是应用 VIP 进行拜访，如下图：
关联 Prometheus 与 Alertmanager

留神：仅在 master 上配置即可，因为 slave 会从 master 上拉取
/usr/local/prometheus/conf/prometheus.yml
```
alerting:
  alertmanagers:
  - static_configs:
 - targets:
   - 192.168.11.203:9093
```
笔者这里通过 VIP 跟 Alertmanager 组件通信，当 prometheus 中的警报规定触发了告警后，告警音讯就会发送到警报组件监听的 9093 端口，由 alertmanager 组件进行解决
配置警报规定文件的主动发现

留神：仅在 master 上配置即可
/usr/local/prometheus/conf/prometheus.yml
```
rule_files:
  - "./business/test_bus_a/rule/*.rules"
  - "./business/test_bus_b/rule/*.rules"
```

配置 mysql 的警报规定，当 mysql 挂掉后，使其触发警报

留神：仅在 master 上配置即可
/usr/local/prometheus/conf/business/test_bus_a/rule/mysql.rules

groups:
  - name: mysql-alert
 rules:
 - alert: "MysqlDown"
   expr: mysql_up{job="测试业务 A"}==0
   for: 1m
   labels:
   annotations:
     summary: "MySQL 数据库服务:{{$labels.ip}}产生进行告警"
     description: "测试业务 A 的环境 MySQL 数据库服务:{{$labels.ip}}已进行，以后 UP 状态值为：{{$value}}，已触发告警条件：mysql_up = 0，持续时间：1m。"
     alertLevel: 5

下面的案例很简略，expr 是表达式，该表达式是说：如果 mysql_up 指标的值等于 0 那么就触发该警报

能够通过 promtool 工具查看警报规定配置文件是否有误

[root@prosvr-master prometheus]# ./promtool check rules ./conf/business/test_bus_a/rule/mysql.rules 
Checking ./conf/business/test_bus_a/rule/mysql.rules
  SUCCESS: 1 rules found

配置文件产生了变更后，master 会主动热重启，slave 会主动拉取配置并热重启，间接在 UI 界面上能够查看到该规定

笔者在这里假如用 python 编写了一个最简略的 webhook 接口，让其能够接管来自 alertmanager 的警报音讯，而后打印进去

特地阐明：只需在 master 上编写的 webhook 接口脚本，并且也放在标准的 conf 目录下：/usr/local/prometheus/conf/webhook.py，该 API 脚本会被 slave 拉取到
webhook.py 简略的 API 代码如下：
```
import json
from flask import Flask, request
app = Flask(__name__)
@app.route('/webhook', methods=['POST'])
def webhook():
 data = json.loads(request.data)
 print(data)
if __name__ == '__main__':
 app.run('0.0.0.0', 5001)
```
特地阐明 1：此示例 API 只是演示应用，请依据理论状况编写相干代码，本实例仅仅只是打印进去，并没有将告警推送到其余平台，如钉钉、邮件、或其余告警收敛平台。

特地阐明 2：如果您也想在您的测试环境将笔者的这个 webhook.py 跑起来，请自行装置 python 的 flask 库，笔者不在本篇解说 python 的相干常识。python 编程笔者后续会专门抽时间作为专题给大家分享，敬请您的关注。
创立 webhook API 的启动脚本

阐明：在 master 和 slave 都要创立 startWebHook.sh 脚本
```
#!/bin/sh
nohup python ./conf/webhook.py >> ./logs/webhook.log &
```
仅在 master 上启动 webhook API
```
[root@prosvr-master prometheus]# sh startWebHook.sh 
```
特地留神：千万不要在 slave 上启动 webhook API，具体起因在本篇的最后面曾经有过解释（防止告警反复推送），只有当 master 不可用了，slave 才拉起 webhook API 脚本进行承当告警推送的工作。
模仿 mysql 故障，验证告警是否能够失常触发，验证由 webhook 是否能够失常接管
在 master 上用 tailf 命令实时监测./logs/webhook.log
```
[root@prosvr-master prometheus]# tailf ./logs/webhook.log 
 * Serving Flask app "webhook" (lazy loading)
 * Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://0.0.0.0:5001/ (Press CTRL+C to quit)
```
登录 Mysql 主机，停掉 mysql
```
[root@mysql8db ~]# cat stop_mysql.sh 
#!/bin/bash
/usr/local/mysql8/bin/mysqladmin  -S /usr/local/mysql8/mysql.sock -uroot -pRoot.123456 shutdown
[root@mysql8db ~]# 
[root@mysql8db ~]# sh stop_mysql.sh 
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
[root@mysql8db ~]# 
```
没过多久，webhook api 就接管到了告警音讯

同样，在 Alertmanager 告警页面中，也能看到告警音讯

写在最初

到目前为止，该 DIY 的 prometheus 主备计划的全程搭建过程就曾经完结了，期间波及到很多知识点都还没有去深刻的分析，比方：PromQL，Metric 类型，告警的分组、克制、静默等等知识点。本篇的外围主题是把这个 DIY 的计划给搞起来，后续笔者会逐个分享更多对于 prometheus 的技能点，敬请大家的关注。谢谢！感谢您的关注，望多多转发、点赞。谢谢！

写在开篇

一、布局和标准

1. 设施布局（本示例为测试环境）

2. 对立装置门路标准

3. prometheus 组件配置文件和目录标准

4. alertmanager 组件配置文件和目录标准

5. 备份门路标准

6. 日志目录标准

二、组件装置部署

三、prometheus 配置文件目录同步部署

1. master 部署配置文件下载服务

2. slave 部署配置文件拉取服务

四、监控 mysql 案例

五、监控主机案例

六、AlertManager 警报组件配置

站内搜索