“一切正常”的监控大屏，差点让我们损失百万！
某电商大促期间，订单量突然下跌，客服接到大量投诉"支付失败"。运维团队赶紧看监控——CPU正常、内存正常、磁盘正常、数据库连接数正常...
一切指标都显示"健康"，但业务已经挂了半小时！差点损失百万
问题在哪？标准监控工具只能监控"数据库有没有挂"，但监控不了"支付成功率高不高"。等用户投诉了才知道问题，这半小时损失了多少订单？影响了多少用户？
一、你的业务是独特的，为什么监控要千篇一律？
很多企业都遇到过类似的问题：
买了监控工具，却还是用Excel + 手工巡检
- 想监控"订单积压量"、"支付成功率"——但工具只有CPU、内存这种通用指标
- Oracle的失败JOB、PostgreSQL的主备复制槽信息——标准工具覆盖不到
- 新业务上线，想加监控？等厂商排期开发吧，三个月后终于上了，业务早变了
- 不同数据库买了多套工具，DBA要在多个系统之间切换，还是漏掉关键指标
问题的根源在哪？
传统监控工具用"固定规则"监控所有用户的业务——但你的业务是独特的，为什么监控要千篇一律？
二、DBdoctor：自定义监控业务指标
DBdoctor的核心能力在于：监控数据来源、告警逻辑判断、定期巡检方式，都可以自定义，想监控什么，你就写什么。
不是让你适配工具的固定规则，而是让工具适配你的业务场景。
先理解一下三者的关系：
监控项：实时采集数据，采集方式支持shell/SQL
告警规则：基于监控项/巡检指标/自定义SQL进行实时判断，发现问题立即通知
巡检指标：基于监控项/自定义SQL/Python进行定期深度检查，生成报告。
简单3步，配置业务监控
场景1：订单积压监控
第一步：创建监控项（数据源）
1234SELECT COUNT(*) AS pending_orders
FROM orders
WHERE status = 'pending'
AND create_time < NOW() - INTERVAL 30 MINUTE;这个SQL会持续采集，每分钟执行一次，把数据存下来
第二步：配置告警规则（实时判断）
规则配置：当积压订单超过100个时，立即告警
- 判断逻辑：pending_orders > 100
- 采集频率：1分钟
- 持续时间：连续2次超过阈值才告警（避免瞬时波动）
- 通知方式：企业微信 + 邮箱
第三步：配置巡检指标（定期深度检查）
巡检配置：每天凌晨2点执行，查看过去24小时订单积压趋势
- 如果积压量持续上升，即使没达到告警阈值，也会在巡检报告中提示
- 还可以计算积压量的增长速度，预测什么时候会告警
场景2：支付成功率突降
第一步：创建监控项（数据源）
1234SELECT
ROUND(COUNT(CASE WHEN status = 'success' THEN 1 END) * 100.0 / COUNT(*), 2)
AS success_rate
FROM payment_logsWHERE create_time > NOW() - INTERVAL 10 MINUTE;第二步：配置告警规则（实时判断）
DBdoctor支持两种告警类型：
- 表达式类型：成功率低于90%时告警配置：success_rate < 90
- 值变更类型：比上个周期下跌超过10%时告警配置：与上一个值相比，下跌超过10%适用场景：即使成功率还在95%，但如果从99%跌到95%，也要关注
价值：支付问题第一时间发现，比用户投诉早半小时
三、告警与巡检：救火与体检，缺一不可
定期巡检可以帮助业务提前发现潜在风险，DBdoctor支持将自定义的业务指标添加至巡检项：
只需要一次配置，后续即可定期巡检业务关键指标，提前发现问题。
四、看看你的业务有哪些监控盲点？
监控的终极目标，不是为了证明基础设施活着，而是为了保障业务连续性。传统监控的“固定规则”无法适配千变万化的业务场景，而 DBdoctor 通过全自定义的数据采集、告警逻辑与巡检机制，填补了标准工具与真实业务之间的鸿沟。
- 更敏锐：基于业务指标的实时感知，快于用户投诉。
- 更全面：统一平台覆盖多数据库，消除切换成本与监控盲点。
- 更前瞻：定期深度巡检，将风险预警提前至故障发生之前。
诚邀您体验 DBdoctor，用自定义监控重塑您的运维体系，让每一次告警都精准指向业务核心价值。
