关于prometheus:意犹未尽的第2篇再次推出继续讲解oracledbexporter监控Oracle一个入侵性极低的监控方案

写在开篇

基于上次的 oracledb_exporter监控Oracle，一个入侵性极低的监控计划文章中，本篇持续解说如下内容：

依据理论业务需要编写自定义监控指标，让其真正能够在生产上玩起来
oracledb_exporter的备机拉取master配置

再次坚固下计划

本篇讲的是下图中的红色框局部

红色框局部，是oracledb_exporter的主备计划，联合上次的设计，这个图是残缺的监控架构了。
oracledb_exporter的主备方案设计思路是跟Prometheus主备的设计思路大同小异的，架构不论如何设计，都是为了在生产环境上不要存在单点。

再次坚固笔者的环境规划

用处	主备角色	物理IP	VIP接管	VIP地址
oracledb_exporter	Master	192.168.11.20	接管	192.168.11.200
oracledb_exporter	Backup	192.168.11.21	待接管	192.168.11.200

自定义指标的标准

什么是自定义指标

如果oracledb_exporter默认的监控指标没有你想要的，怎么办？非常简单！oracledb_exporter反对自定义指标，依照它的标准格局进行编写相应的指标，将自定义指标编写在文件格式以.toml结尾的配置文件里（指标文件），那oracledb_exporter如何应用这个自定义的指标文件？有两种形式，如下：

应用--custom.metrics参数，前面指定指标文件
设置全局或部分环境变量，如下：
```
export CUSTOM_METRICS=my-custom-metrics.toml
```

自定义指标文件格式和标准

编写自定义指标文件，必须依照它的标准进行编写，咱们拿官网的小栗子来解释解释，解剖解剖，官网小栗子如下：

[[metric]]context = "test"request = "SELECT 1 as value_1, 2 as value_2 FROM DUAL"metricsdesc = { value_1 = "Simple example returning always 1.", value_2 = "Same but returning always 2." }

依据下面的小栗子，能够晓得，必须蕴含的元素有如下：

一个或多个指标，就须要一个或多个[[metric]]局部，也就是一个指标，就对应一个[[metric]]局部
对于每个[[metric]]局部，最起码要有上面的字段：
context：指标名称（有意义的）
request：编写自定义sql
metricsdesc：对指标的形容

自定义指标实战

上面咱们通过一个更贴合理论的案例来实战一下，假如要获取IOPS指标，这个指标是须要计算的。特地要留神，在编写自定义指标之前，肯定要先把sql写好，且要调试好。

笔者写好的获取iops的sql如下：

select sum(decode(name,'physical read IO requests',value,'physical write IO requests',value,0)) as iops, sum(decode(name,'physical read bytes',value,'physical write bytes',value,0)) / 1024 / 1024 as mbps from v$sysstat where name in ('physical read IO requests','physical write IO requests','physical read bytes','physical read total bytes', 'physical write bytes','physical write total bytes','physical read total IO requests','physical write total IO requests');

通过plsql工具连贯到oracle进行执行和调试，看看后果是否达到预期，成果如下：

完满！达到预期了，么么哒。

创立自定义指标文件”./custom_metrics/performance_metric.toml“编写如下：

[[metric]]context = "reads_and_writes_per_second"labels = ["iops"]request = "select sum(decode(name,'physical read IO requests',value,'physical write IO requests',value,0)) as iops, sum(decode(name,'physical read bytes',value,'physical write bytes',value,0)) / 1024 / 1024 as mbps from v$sysstat where name in ('physical read IO requests','physical write IO requests','physical read bytes','physical read total bytes', 'physical write bytes','physical write total bytes','physical read total IO requests','physical write total IO requests')"metricsdesc = { iops = "每秒进行读写操作的次数" }

启动oracledb_exporter

启动脚本如下：

#!/bin/sh# 监控测试环境oraclesource .env_var/.9161_192.168.11.8_PDB1_ZABBIX.DB nohup oracledb_exporter --log.level warn --web.listen-address :9161 --custom.metrics ./custom_metrics/performance_metric.toml >> ./logs/9161_192.168.11.8_PDB1_ZABBIX.DB.log &

开始启动：

[root@exporter-server-master oracle]# sh start.sh

成果如下图：

完满！所有都达到了预期！

对于指标的其它字段

在理论的利用中，可能还会应用到指标局部中的labels和ignorezeroresult字段，上面咱们简略的理解下它们的应用场景。

labels：顾名思义，这个是标签的意思，除了给指标取一个有意义的名字之外，其实还能够定义一些标签（当然如果有需要的话）上面是它的定义格局：
```
[[metric]]...labels = ["iops", "io", "io_performance"]...
```
在方才的案例中，就有应用到labels，同一个指标是能够定义多个标签的，逗号分隔即可。
ignorezeroresult：这个字段又是什么鬼？这个字段用处是疏忽为0的后果，假如你自定义的指标中，如果在某个工夫获取到的值是0，但想要疏忽它，那么就能够应用这个字段了。它的定义格局如下：
```
ignorezeroresult = true
```
当然，如果不显示指定的话，那就是默认不疏忽为0的后果。

oracledb_exporter的主备配置

oracledb_exporter的slave服务器须要拉取master服务器的配置，当master的配置产生扭转，就告诉slave，而后slave再拜访masetr进行拉取。其实这个原理和笔者在之前设计prometheus主备计划时的配置文件拉取的原理是一样的，而且脚本也能够改改就能复用了，上面我来配置一下。

master配置

依照咱们之前的布局，所有数据库监控的根目录是在/data/database_monitoring/门路下，因而咱们将上面的脚本放在此目录，并拉起。当slave来拉配置的时候，它拜访的是8000端口（拉起后默认的端口），这样就能够将该目录下所有业务的指标文件进行同步了。

部署配置文件同步Api

创立startOracledbExporterConfSyncApi.sh

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

拉起脚本和查看

[root@exporter-server-master database_monitoring]# sh startOracledbExporterConfSyncApi.sh[root@exporter-server-master database_monitoring]# netstat -tulnp | grep 8000tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      1462/python

部署配置文件变动时的检测脚本
留神：此脚本也要运行在/data/database_monitoring/门路下

创立startTarPackConf.sh

#!/bin/shtime_log=`date "+%Y-%m-%d %H:%M:%S"`echo "${time_log} 配置查看器启动"task_wait_sec=4find ./business -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.listwhile truedo  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 ./business.tar.gz ./backup/business.tar.gz_bak_${time_bak}      tar -zcf business.tar.gz business/      echo 1 > ./notice_slave.action      break    else      echo 0 > ./notice_slave.action      break    fi  done  find ./business -type f -print0 | xargs -0 md5sum > ./cfmd5/cfmd5.list  sleep ${task_wait_sec}done

[root@exporter-server-master database_monitoring]# mkdir cfmd5[root@exporter-server-master database_monitoring]# mkdir backup[root@exporter-server-master database_monitoring]# mkdir logs

拉起脚本和查看

[root@exporter-server-master database_monitoring]# nohup sh ./startTarPackConf.sh >> ./logs/tar_pack.log &[root@exporter-server-master database_monitoring]# ps -aux | grep Tarroot       1755  0.0  0.6 113292  1464 pts/0    S    19:40   0:00 sh ./startTarPackConf.sh

Backup配置

[root@exporter-server-backup ~]# mkdir -p /data/database_monitoring[root@exporter-server-backup ~]# cd /data/database_monitoring/[root@exporter-server-backup database_monitoring]#

部署拉取配置脚本

在该门路下创立定时拉取配置脚本startUpdateSyncConf.sh

#!/bin/shtime_log=`date "+%Y-%m-%d %H:%M:%S"`echo "${time_log} 配置更新器启动"pull_wait_sec=2while truedo  wget http://192.168.11.20: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.20:8000/business.tar.gz -O business.tar.gz    echo "${time_log} 备份原有的配置目录"    mv ./business ./backup/business_bak_${time_bak}    echo "${time_log} 解压下载后的配置压缩包"    tar -zxf business.tar.gz  fi  sleep ${pull_wait_sec}done

创立脚本所需的目录

[root@exporter-server-backup database_monitoring]# mkdir backup[root@exporter-server-backup database_monitoring]# mkdir logs

拉起脚本和查看

nohup sh startUpdateSyncConf.sh > ./logs/update_sync.log &

配置同步验证

在master上批改配置文件

笔者关上之前配置好的配置文件，批改了context内容，在前面减少了test，变为：”reads_and_writes_per_second_test“

[[metric]]context = "reads_and_writes_per_second_test"labels = ["iops"]request = "select sum(decode(name,'physical read IO requests',value,'physical write IO requests',value,0)) as iops, sum(decode(name,'physical read bytes',value,'physical write bytes',value,0)) / 1024 / 1024 as mbps from v$sysstat where name in ('physical read IO requests','physical write IO requests','physical read bytes','physical read total bytes', 'physical write bytes','physical write total bytes','physical read total IO requests','physical write total IO requests')"metricsdesc = { iops = "每秒进行读写操作的次数" }

在backup下面查看是否有触发拉取

批改了配置文件后，笔者马上登录backup查看了一下，胜利和master放弃同步。

把backup的oracledb_exporter也拉起来后看看成果
master

backup

十分完满！都是OK的呢，都能失常采集监控指标。但须要留神：在正式生产应用时，仅需拉起master的oracledb_exporter，backup的oracledb_exporter不必拉起，当master挂了，VIP会漂移到backup进行接管。这时候能够去backup上手动拉起oracledb_exporter，也能够再编写脚本实现主动拉起，笔者就不做演示了哈！

写在最初

到此为止，oracledb_exporter主备计划的布局和部署就全都讲完了，欢送宽广盆友能够按笔者的计划实际实际，并给出更好的计划，咱们独特学习和提高。再次感激大家！望多多关注咱们，转发、珍藏、点赞！

本文转载于：

https://mp.weixin.qq.com/s/gF...