监控的方式有很多，常用的有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 syncmestiup 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 statussh /root/check_dm1.shsleep 10 ##因为dmctl执行需要几秒钟时间，这里sleep 10等待waitnum=$(cat /root/new.log | wc -l) ##判断是否有running# if no running mail alertif [ $num -eq 0 ] ##如果没有抓取到running 关键字则表示同步状态异常thencat /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.logfi[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 logLOG_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博客
