共计 25248 个字符，预计需要花费 64 分钟才能阅读完成。
写在开篇
对于 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 的管理工具，敬请期待推出！我不造车，我只造整机。
一、布局和标准
1. 设施布局（本示例为测试环境）
| 角色 | 物理 IP | VIP | 装置组件 | 告警推送形式 |
|---|---|---|---|---|
| master | 192.168.11.146 | 192.168.11.203（以后接管） | prometheus、alertmanager（均拉起） | webhook 形式，脚本拉起 |
| slave | 192.168.11.147 | prometheus、alertmanager（均拉起） | webhook 形式，脚本不拉起（备用） |
2. 对立装置门路标准
master 和 slave 主机的规范装置门路均为：/usr/local/，笔者装置组件后的环境如下:
/usr/local/keepalived（留神：倡议 keepalived 配置成非抢占模式）/usr/local/prometheus
/usr/local/alertmanager至于装置门路的标准，请自行依据理论状况敲定。
3. prometheus 组件配置文件和目录标准
- 所有配置文件统一标准门路：/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 的配置文件布局案例十分重要，请务必参照此标准。
4. alertmanager 组件配置文件和目录标准
对于 Alertmanager 组件的配置文件，相对来说没 prometheus 那么简单，次要的布局还是在 prometeus 中
- alertmanager 的主配置文件统一标准门路放在 prometeheus 的 conf 中：/usr/local/prometheus/conf/alertmanager.yml
5. 备份门路标准
在 master 主机上，会主动备份原有的 conf 配置文件目录
-
Prometheus 组件
对立备份门路为：/usr/local/prometheus/backup/
-
Alertmanager 组件
不波及到备份
6. 日志目录标准
在 master 主机和 slave 主机上运行的脚本日志均对立寄存在指定目录
-
Prometheus 组件
对立日志目录：/usr/local/prometheus/logs/
-
AlertManager 组件
对立日志目录：/usr/local/alertmanager/logs/
二、组件装置部署
留神：master 和 slave 均须要装置如下组件
- keepalived 高可用组件
- prometheus 监控组件
- alertmanager 警报组件
因组件的装置部署不是本文的主题，所以笔者在这里就不再撰写装置步骤，在此省略了哈，请自行装置好即可。
三、prometheus 配置文件目录同步部署
阐明 1：均须要在 master 和 slave 上部署文件同步相干脚本
阐明 2：以下的每一步操作，请均进入到“/usr/local/prometheus/”目录下进行操作（此目录是之前曾经定为装置标准的目录），如您的标准目录和笔者的不同，请进入到您本人的标准目录下。
阐明 3：以下波及的脚本，波及的目录：conf、backup、logs、cfmd5，请自行在标准的目录下进行创立即可。
1. master 部署配置文件下载服务
- 通过 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日常保护中，如有须要进行全副服务的需要，运行该脚本即可。
2. slave 部署配置文件拉取服务
特地阐明：在 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} donepull_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日常保护中，如需一次性进行服务，执行该脚本即可
四、监控 mysql 案例
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 *************************** -
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:
- ‘192.168.11.150:9104’
labels:
ip: ‘192.168.11.150’
monitype: ‘mysql’
project: ‘ 测试业务 A ’
business: ‘ 测试业务 A ’ - ‘192.168.11.150:9104’
- targets：拉取指标，这里指向 mysql 服务器的 IP 地址，mysqld_exporter 的端口是 9104
- labels：这是标签，标签的次要作用是能够通过指定的标签查问指定的数据。
标签的作用：Prometheus 中存储的数据为工夫序列，是由 Metric 的名字和一系列的标签 (键值对) 惟一标识的, 不同的标签代表不同的工夫序列，即通过指定标签查问指定数据。不同的标签代表不同的工夫序列，即通过指定标签查问指定数据。指标 + 标签实现了查问条件的作用，能够指定不同的标签过滤不同的数据。
在 Prometheus UI 中对应的 Labels 信息如下图可见：
假如有个需要，须要晓得被监控的 mysql 服务器所在的机房地位，那么就能够减少一个自定义标签，如下：
-
./conf/business/test_bus_a/job/mysql.yml
-
targets:
- ‘192.168.11.150:9104’
labels:
ip: ‘192.168.11.150’
monitype: ‘mysql’
project: ‘ 测试业务 A ’
business: ‘ 测试业务 A ’
region: ‘ 广州机房 ’
- ‘192.168.11.150:9104’
- 不论你是用 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/
[root@prosvr-master job]# cat host.yml
- targets:
- '192.168.11.150:9100'
labels:
ip: '192.168.11.150'
monitype: 'linux-centos7'
project: '测试业务 B'
business: '测试业务 B'
region: '深圳机房'在 Prometheus UI 中查看新增的测试业务 B
- 不论你是用 VIP、还是 master、slave 的物理 IP 去拜访 UI，后果都一样的，不信你试试。
十分不错，只有检测到配置文件发生变化，master 会主动热重启，slave 也会主动拉取配置目录而后热重启，十分的省心、省力。自我感觉这个 DIY 的主备计划简直靠近完满，尽管没有用很高大上的语言、工具去实现，但笔者的这个思路自我感觉是十分的不错，这难道就是传说中的自我感觉良好？当然，笔者当前会通过 Go 或者 Python 打造一个治理 Promtheus 主备的工具，且是带 UI 的管理工具，敬请期待推出！我不造车，我只造整机。
六、AlertManager 警报组件配置
阐明：基于二进制包的 alertmanager 组件请自行在 master 和 slave 中装置部署到标准的目录，之后持续上面的步骤。
- 挪动 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 [root@prosvr-master conf]#特地留神：上述操作，在 master 和 slave 上都要操作，且在 slave 服务器挪动 alertmanager.yml 配置文件后，往后就能够不必去管 slave 上的 alertmanager.yml 配置文件了，次要的配置变更都在 master 上进行就好，如果有变更，slave 会主动拉取配置目录。通常警报组件的 alertmanager.yml 配置文件一旦配置好后，改变的频率比拟少。
特地阐明：之所以这么设计，有两个益处：1）配置的变更都在同一个目录下进行；2）利用了现有 master 和 slave 的配置目录同步能力
- 在 master 上配置警报的主配置文件 /usr/local/prometheus/conf/alertmanager.yml
-
在警报组件中配置告警音讯发往的接口地址, 让其能够调用接口，配置形式很简略，只须要指定一下接口地址即可
global: resolve_timeout: 5m route: group_by: [...] group_wait: 1s group_interval: 1s repeat_interval: 1000d receiver: 'web.hook' -
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 的技能点，敬请大家的关注。谢谢！感谢您的关注，望多多转发、点赞。谢谢！
https://mp.weixin.qq.com/s/Zj…
