乐趣区

关于prometheus:全网唯一的DIY的Prometheus高可用方案生产未上测试先行

作者：

jiezi

在

写在开篇

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

  • DIY的prometheus主备计划架构图

计划阐明

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

  1. 通过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]#

  1. 创立配置文件变动查看脚本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掉即可。

  1. 创立启动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

  1. 为了不便热重启操作，创立脚本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

在日常保护中，当配置文件产生了变更就能够利用该脚本进行平滑重启

  1. 创立汇总启动脚本start_all.sh

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

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

  2. 为了减少安全性，仅容许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和端口即可。

  1. 创立汇总进行脚本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目录

  1. 将首次装置实现的prometheus.yml文件挪动到以后的conf目录下

    mv ./prometheus.yml ./conf/

    之所以要挪动slave自身的prometheus.yml，是因为要从master同步过去曾经布局好的conf配置目录，拉取后会笼罩slave上的conf目录，当前都以master的配置为主

  2. 筹备启动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、高端磁盘阵列）、容量大的目录中。

  1. 接着启动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]#

  2. 筹备从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，则什么也不做。

  3. 创立热重启的脚本hot_restart_prometheus.sh

    #!/bin/sh
curl -X POST http://127.0.0.1:9090/-/reload

    日常保护中，在slave主机上，如有必要时不便手动执行热重启

  4. 创立汇总启动脚本start_all.sh

    #!/bin/sh
nohup sh startUpdateSyncConf.sh > ./logs/update_sync.log &
sleep 3
sh ./startPrometheusSvr.sh

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

  5. 创立汇总进行脚本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通过这个账号去登录数据库采集指标，且这个账号要有相干权限（适合的权限即可）。所以的适合，请自行依据理论状况决定要给什么权限，如果是生产环境，个别的准则是：最小准则、够用就好。

  1. mysql测试环境信息
  2. 以下是笔者的mysql测试环境
数据库 操作系统 IP
mysql8.0 centos7 192.168.11.150

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

  1. 下载mysqld_exporter

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

  2. 登录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 ***************************

  3. 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

  4. rows in set (0.00 sec)

    mysql>

    > 对于mysql的数据库账号权限的受权和回收的常识，笔者当前会出一个专题，专门深入浅出的分析，敬请大家的关注！

  5. 部署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

  6. 创立连贯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]#

  7. 启动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其实也是有在监听的啦!

  1. 启动后，通过浏览器拜访指标页面

  2. 裸露的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

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

    刚刚是通过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中持续以下的操作

  1. 在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秒。
  1. 在布局好的业务目录（business）下创立对应的业务文件夹：test_bus_a，以及在业务目录test_bus_a上面创立job目录，并进入job目录创立mysql.yml（该名称可自定义，也可叫mon_mysql.yml或者其余，次要你喜爱就好！）在mysql.yml中定义拉取mysql的监控指标数据

  2. ./conf/business/test_bus_a/job/mysql.yml的内容如下：

  3. targets:

    • ‘192.168.11.150:9104’
      labels:

    ip: ‘192.168.11.150’
    monitype: ‘mysql’
    project: ‘测试业务A’
    business: ‘测试业务A’

  4. targets：拉取指标，这里指向mysql服务器的IP地址，mysqld_exporter的端口是9104
  5. 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: ‘广州机房’
  • 不论你是用VIP、还是master、slave的物理IP去拜访UI，后果都一样的，不信你试试。

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

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

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

五、监控主机案例

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

  1. 下载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/

  2. 可通过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
...
...

  3. 启动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

  4. 通过浏览器查看node_exporter裸露的指标

  1. 在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中装置部署到标准的目录，之后持续上面的步骤。

  1. 挪动master和slave上的警报组件的主配置文件alertmanager.yml

  2. 在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的配置目录同步能力

  1. 在master上配置警报的主配置文件/usr/local/prometheus/conf/alertmanager.yml

  2. 在警报组件中配置告警音讯发往的接口地址, 让其能够调用接口，配置形式很简略，只须要指定一下接口地址即可

    global:
  resolve_timeout: 5m
route:
  group_by: [...]
  group_wait: 1s
  group_interval: 1s
  repeat_interval: 1000d
  receiver: 'web.hook'

  3. name: ‘web.hook’
    webhook_configs:

    • url: ‘http://127.0.0.1:5001/webhook’

    send_resolved: true

    > 上述配置中，次要蕴含两大部分，路由（route）和接收器（receivers），所有的告警信息都会从配置中的顶级路由(route)进入路由树，依据路由规定将告警信息发送给相应的接收器。本篇次要是配置接收器，应用webhook的形式，假如是将告警音讯推送到第三方平台。当然，在本篇仅为示例，打印进去而已。
  4. 在master和slave上创立Alertmanager组件启动脚本
  5. 留神：该步骤肯定要进入到/usr/local/alertmanager/目录下进行操作

  6. 创立脚本，名称：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进行拜访，如下图：

在这里插入图片形容

  1. 关联Prometheus与Alertmanager

    留神：仅在master上配置即可，因为slave会从master上拉取

  2. /usr/local/prometheus/conf/prometheus.yml

    alerting:
  alertmanagers:
  - static_configs:
 - targets:
   - 192.168.11.203:9093

    笔者这里通过VIP跟Alertmanager组件通信，当prometheus中的警报规定触发了告警后，告警音讯就会发送到警报组件监听的9093端口，由alertmanager组件进行解决

  3. 配置警报规定文件的主动发现

    留神：仅在master上配置即可

  4. /usr/local/prometheus/conf/prometheus.yml

    rule_files:
  - "./business/test_bus_a/rule/*.rules"
  - "./business/test_bus_b/rule/*.rules"

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

    留神：仅在master上配置即可

  6. /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界面上能够查看到该规定

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

    特地阐明：只需在master上编写的webhook接口脚本，并且也放在标准的conf目录下：/usr/local/prometheus/conf/webhook.py，该API脚本会被slave拉取到

  2. 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编程笔者后续会专门抽时间作为专题给大家分享，敬请您的关注。

  1. 创立webhook API的启动脚本

    阐明：在master和slave都要创立startWebHook.sh脚本

    #!/bin/sh
nohup python ./conf/webhook.py >> ./logs/webhook.log &

  2. 仅在master上启动webhook API

    [root@prosvr-master prometheus]# sh startWebHook.sh

    特地留神：千万不要在slave上启动webhook API，具体起因在本篇的最后面曾经有过解释（防止告警反复推送），只有当master不可用了，slave才拉起webhook API脚本进行承当告警推送的工作。

  3. 模仿mysql故障，验证告警是否能够失常触发，验证由webhook是否能够失常接管

  4. 在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…

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章