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

写在开篇

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

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

再次坚固下计划

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

红色框局部，是 oracledb_exporter 的主备计划，联合上次的设计，这个图是残缺的监控架构了。

oracledb_exporter 的主备方案设计思路是跟 Prometheus 主备的设计思路大同小异的，架构不论如何设计，都是为了在生产环境上不要存在单点。

再次坚固笔者的环境规划

自定义指标的标准

1. 什么是自定义指标

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

• 应用 –custom.metrics 参数，前面指定指标文件

• 设置全局或部分环境变量，如下：

  export CUSTOM_METRICS=my-custom-metrics.toml

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

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

[[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 写好，且要调试好。

1. 笔者写好的获取 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');

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

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

3. 创立自定义指标文件”./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 = "每秒进行读写操作的次数"}

4. 启动 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 端口（拉起后默认的端口），这样就能够将该目录下所有业务的指标文件进行同步了。

1. 部署配置文件同步 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         

2. 部署配置文件变动时的检测脚本

   留神：此脚本也要运行在 /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 配置

1. 在数据目录下创立标准的目录

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

2. 部署拉取配置脚本

在该门路下创立定时拉取配置脚本 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 &

配置同步验证

1. 在 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 = "每秒进行读写操作的次数"}

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

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

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

• backup

!

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

写在最初

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

本文转载于：

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