写在开篇
基于上次的 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主备计划的规划和布置就全都讲完了,欢迎广大盆友能够按笔者的计划实践实践,并给出更好的计划,咱们共同学习和进步。再次感谢大家!望多多关注咱们,转发、保藏、点赞!