写在开篇
基于上次的 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 # 监控测试环境oracle source .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/sh nohup /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 8000 tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 1462/python
- 部署配置文件变化时的检测脚本
注意：此脚本也要运行在/data/database_monitoring/路径下
创建startTarPackConf.sh
#!/bin/sh time_log=`date "+%Y-%m-%d %H:%M:%S"` echo "${time_log} 配置检查器启动" task_wait_sec=4 find ./business -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 ./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 Tar root 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/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.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主备方案的规划和部署就全都讲完了，欢迎广大盆友可以按笔者的方案实践实践，并给出更好的方案，我们共同学习和进步。再次感谢大家！望多多关注我们，转发、收藏、点赞！
