写在开篇
基于上次的 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主备计划的布局和部署就全都讲完了,欢送宽广盆友能够按笔者的计划实际实际,并给出更好的计划,咱们独特学习和提高。再次感激大家!望多多关注咱们,转发、珍藏、点赞!
本文转载于:
https://mp.weixin.qq.com/s/gF…
发表回复