监控的方式有很多,常用的有zabbix和prometheus平台,理论上都可以做到对有状态服务的监控,因为我个人对这两个监控平台不是很熟悉,所以一般喜欢使用shell脚本来做监控;
纯oracle 数据库的监控推荐使用EMCC,具体见如下博文。
EMCC13.5安装配置手册(详细版)_oracle emcc安装-CSDN博客
shell 脚本监控的优势:
简单灵活:使用Shell脚本可以快速实现自定义监控逻辑,灵活性高。
低资源消耗:脚本本身资源消耗低,可以直接运行在被监控主机上。
无外部依赖:无需额外的软件或服务,依赖于操作系统自带的工具。
当然劣势也很明显
维护成本高:脚本需要手动编写和维护,随着监控需求的增加,维护成本会显著上升。
缺乏集中管理:没有统一的监控平台和界面,难以集中管理和查看监控数据。
告警和通知:需要自行实现告警和通知机制,缺乏内置的高级告警管理功能。
历史数据和图表:难以实现长期数据存储和图表展示,需要额外的工具和开发工作。
一 .监控TIDB DM数据同步状态
如何将TIDB作为Mysql的从库实现实时数据同步_tidb数据库数据同步-CSDN博客
这篇文章详细介绍了使用TIDB作为mysql备库存放历史归档数据,并作为报表库。但是在后续的使用过程中,偶尔因为同步的过滤操作造成同步失败,虽然TIDB和DM集群都有Grafana,不过不会主动推送错误,导致长时间的同步失败;既然dm同步是有状态的服务,那么就可以通过shell脚本来监控。
DM同步状态监控命令
[root@tidb01 ~]# tiup dmctl --master-addr 10.xx.xx.xx:8261 query-status syncmes
tiup is checking updates for component dmctl ...timeout(2s)!
Starting component `dmctl`: /root/.tiup/components/dmctl/v7.6.0/dmctl/dmctl --master-addr 10.250.38.37:8261 query-status syncmes
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "mysql-01",
"worker": "dm-10.xx.xx.xx-8262",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "syncmes",
"stage": "Running", ##如果状态正常 stage 是running
"unit": "Sync",
"result": null,
"unresolvedDDLLockID": "",
"sync": {
"totalEvents": "45472123",
"totalTps": "27",
"recentTps": "1",
"masterBinlog": "(mysql-bin.000386, 222374746)",
"masterBinlogGtid": "",
"syncerBinlog": "(mysql-bin.000386, 222370491)",
"syncerBinlogGtid": "00000000-0000-0000-0000-000000000000:0",
"blockingDDLs": [
],
"unresolvedGroups": [
],
"synced": false,
"binlogType": "remote",
"secondsBehindMaster": "0",
"blockDDLOwner": "",
"conflictMsg": "",
"totalRows": "45472123",
"totalRps": "27",
"recentRps": "1"
},
"validation": null
}
]
}
]
}
那么监控的逻辑就比较简单,执行dmctl命令,检查输出结果集是否有running,如果没有咋发送邮件通知,告知同步异常
root@lyspltidb01 ~]# cat check_dm1.sh ##将当前状态放入log文件暂存
/root/.tiup/bin/tiup dmctl --master-addr 10.xx.xx.xx:8261 query-status syncmes|grep "Running" >/root/new.log 2>&1
/root/.tiup/bin/tiup dmctl --master-addr 10.xx.xx.xx:8261 query-status syncmes >/root/result.log 2>&1
[root@lyspltidb01 ~]# cat check_dm.sh ##正式脚本
#!/bin/bash
#check mysql to TIDB DM status by norton
#check dm status
sh /root/check_dm1.sh
sleep 10 ##因为dmctl执行需要几秒钟时间,这里sleep 10等待
wait
num=$(cat /root/new.log | wc -l) ##判断是否有running
# if no running mail alert
if [ $num -eq 0 ] ##如果没有抓取到running 关键字则表示同步状态异常
then
cat /root/result.log | mailx -s "tidb Check DM status Log" `cat /root/dba_mail.addr|grep -v \#`
echo "**********************************************************************"
else ##如果正常情况暂存log
>/root/new.log
>/root/result.log
fi
[root@tidb01 ~]#
范例邮件通知
二. shell脚本监控DSG同步状态
DSG SuperSync是一款由迪思杰(北京)数据管理技术有限公司研发的高性能数据库复制平台,主要用于容灾备份、业务分离、数据异构、数据共享、数据迁移和数据上云等场景。它在全量数据复制和增量数据同步方面表现出色,并支持结构变更同步、数据探测、数据转换、数据脱敏和数据质量实时检测等多项功能 (modb) (blog.csdn)。简单来说DSG和OGG差不多,但是我个人认为比OGG功能更强大,( 首次全同步,信创数据库支持,对DDL的支持等都优于OGG),缺点就是技术比较封闭,很多事情都需要依赖原厂支持(毕竟是商业软件)。
DSG的同步有个mon命令可以监控数据同步状态,关键为倒数第二行的数字,正常情况下同步正常,数字一般为0-3(业务量大,备库装载慢时可能会多);shell脚本监控的逻辑就是抓取mon执行结果的倒数第二行 等号后的数字,如果这个数字高于系统负载的阈值,则报警告知DSG同步异常。
[oracle@THSMLORACLE01 jobs]$ cat check_dsg_status.sh
#!/bin/bash
##mon是个类似top的刷新命令,这里加了timeout时间
timeout 1s /oradata/dsg/dt1/scripts/mon > /home/oracle/jobs/dsg.log
# 暂存dsg status log
LOG_FILE="/home/oracle/jobs/dsg.log"
# 获取倒数第二行
SECOND_LAST_LINE=$(tail -n 2 "$LOG_FILE" | head -n 1)
# 从倒数第二行中提取 = 后的数字
NUMBER=$(echo "$SECOND_LAST_LINE" | awk -F '=' '{print $2}')
#echo $NUMBER
# 判断数字是否大于阈值
if [ "$NUMBER" -gt 20 ]; then
# 发送邮件告警
#/home/oracle/jobs/dba_mail.addr 存放需要接受告警邮件的mail地址
echo "Warning DSG status error" | mail -s "Check thsm DSG Status" `cat /home/oracle/jobs/dba_mail.addr|grep -v \#`
fi
三.AI是你的好帮手
对于这种逻辑很简单的代码AI都可以帮你来完成,哪怕稍微有些偏差,也可以在AI提供的代码,稍作修改就可以实现。所以如果有重要的服务需要监控,直接梳理出逻辑让AI给你写出脚本吧。
GPT: 这样逻辑更简洁,但是本地可以执行,放入crontab无法执行,上面的脚本多了暂存和wait可以。(有大佬知道原因吗?私信我)
文心一言:结果和GPT差不多
更多oracle常用监控脚本可以参考
oracle常用监控脚本(纯干货,没有EMCC,ZABBIX也不怕)_oracle 监控及日常处理脚本-CSDN博客