📚 课程目录第2章监控指标体系设计

2. 监控指标体系设计

监控体系能否真正支撑生产运维，取决于指标是否“选得准、分得清、报得对”。如果只把数据库里能查到的数值全部采集一遍，结果往往是告警泛滥、关键故障被淹没。因此，指标体系设计的第一步不是写采集脚本，而是先按运维目标把指标归类，再为每一类定义分级、阈值和告警策略。

一、六类核心指标及其运维含义

结合 Oracle 生产库的典型运维场景，可以把核心指标划分为六类，每类回答一个明确的运维问题：

可用性指标：实例是否可连接、监听是否正常、关键服务是否在线。典型对象包括实例状态（v$instance.status）、监听器注册情况、Data Guard 同步状态、RAC 节点存活状态。
性能指标：响应是否变慢、是否存在等待瓶颈。典型对象包括平均活动会话数（AAS）、DB Time、TOP 等待事件、硬解析比例、缓冲区命中率、日志切换频率。
容量指标：空间和资源是否接近上限。典型对象包括表空间使用率、ASM 磁盘组使用率、归档目录剩余空间、UNDO 表空间使用率、会话数占进程上限比例。
错误指标：是否出现异常报错。典型对象包括 ORA- 错误计数、告警日志中的错误关键字、死锁次数、坏块检测结果、备份失败次数。
安全指标：是否存在越权、异常登录或审计风险。典型对象包括失败登录次数、非工作时间高权限登录、审计记录增长量、账户锁定状态、默认口令账户。
备份指标：数据是否可恢复。典型对象包括最近一次全备/增量备份完成时间、备份集大小、归档日志应用情况、RMAN 校验结果、恢复窗口是否满足 RPO。

这六类指标并非彼此独立。例如归档目录空间不足会同时触发容量告警和备份失败，进而影响可用性。因此指标设计要保留这种关联，而不是把它们割裂成互不相关的采集项。

二、指标分级：P0 到 P3 的判定原则

分级的目的不是给指标贴标签，而是决定“谁在什么时间、以什么方式响应”。建议按业务影响程度分为四级：

级别	判定原则	典型指标示例	响应要求
P0 致命	业务已中断或即将中断，需立即介入	实例宕机、监听不可用、Data Guard 严重延迟、归档目录写满	7×24 立即告警，电话+短信
P1 严重	性能显著下降或存在明确故障风险	AAS 持续超阈值、表空间使用率>90%、备份连续失败	15 分钟内响应，短信+工单
P2 警告	趋势异常，尚未影响业务但需关注	硬解析比例升高、UNDO 使用率上升、失败登录增多	工作时间内处理，邮件/IM
P3 提示	记录性信息，用于容量规划和审计	审计记录增长、备份集大小变化、会话数缓慢上升	日报/周报汇总

分级的关键在于“同一指标在不同阈值下可属于不同级别”。例如表空间使用率 80% 是 P2，90% 是 P1，98% 且自动扩展关闭则是 P0。因此分级必须与阈值绑定，不能只给指标定级。

三、阈值设定：静态、动态与复合条件

阈值设定有三种常见方式，实际生产中往往组合使用：

静态阈值：适合边界明确的指标，如归档目录剩余空间低于 20GB、表空间使用率高于 90%。优点是简单直观，缺点是难以适应业务波动。
动态基线：适合随业务周期波动的指标，如 AAS、DB Time、会话数。可按“同一星期几、同一时段”的历史均值加标准差计算，例如 AAS 超过同时段基线 3 倍标准差触发 P1。
复合条件：适合避免误报，如“表空间使用率>90% 且近 1 小时增长>5%”才触发 P1，单纯高使用率但增长平稳只报 P2。

下面是一段可用于采集表空间使用率并计算分级结果的示例 SQL，阈值参数为示例值，实际部署时应按库的容量规划调整：

SELECT d.tablespace_name,
       ROUND((d.bytes - NVL(f.bytes,0)) / d.bytes * 100, 2) AS used_pct,
       ROUND((d.bytes - NVL(f.bytes,0)) / 1024 / 1024 / 1024, 2) AS used_gb,
       CASE
         WHEN (d.bytes - NVL(f.bytes,0)) / d.bytes >= 0.98 THEN 'P0'
         WHEN (d.bytes - NVL(f.bytes,0)) / d.bytes >= 0.90 THEN 'P1'
         WHEN (d.bytes - NVL(f.bytes,0)) / d.bytes >= 0.80 THEN 'P2'
         ELSE 'P3'
       END AS alert_level
FROM   dba_data_files d,
       (SELECT file_id, SUM(bytes) bytes
          FROM dba_free_space
         GROUP BY file_id) f
WHERE  d.file_id = f.file_id(+)
ORDER  BY used_pct DESC;

查询结果中 used_pct 是判断依据，alert_level 直接给出分级。运维人员看到 P0 行即可立即处理，P1 行进入当日工单，P2/P3 行进入容量趋势报表。

四、告警策略：从“能报”到“报得准”

告警策略要解决三个问题：什么时候报、报给谁、报几次。建议遵循以下原则：

分级路由：P0 直达值班电话，P1 进入值班 IM 群并生成工单，P2 进入日常巡检队列，P3 只进日报。
抑制与去重：同一对象同一指标在抑制窗口内只报一次，例如表空间 P1 告警 30 分钟内不重复推送；实例宕机时抑制其上的会话数、AAS 等衍生告警，避免告警风暴。
恢复通知：P0/P1 告警恢复后应发送恢复通知，便于值班人员确认闭环。
升级机制：P0 告警 10 分钟未确认自动升级到二线，P1 告警 30 分钟未处理升级到值班负责人。

阈值和分级不是一次设定就永久有效。建议每季度结合业务增长、历史告警准确率和误报率复盘一次，把长期误报的阈值调宽，把漏报的指标补上复合条件。

五、指标—分级—阈值—告警的对应关系

下图把六类核心指标、分级判定、阈值类型和告警路由放在同一张关系图中，便于在设计监控项时逐项对照，避免遗漏或重复。

使用这张图时，可以按“从左到右”的顺序逐项检查：每个指标是否归入了正确的类别，分级是否与业务影响匹配，阈值是否选用了合适的类型，告警是否路由到了正确的响应通道。任何一项缺失，都意味着监控体系存在盲区或噪声。

不要把 P3 指标直接提升为 P0 告警。级别越高，响应成本越大；如果所有指标都按最高级别告警，值班人员很快会对告警脱敏，真正致命的故障反而被忽略。

指标体系的落地不是一次性工程。建议先用本文的六类框架梳理现有采集项，标记出缺失项和重复项，再按 P0→P1→P2→P3 的顺序逐步补齐阈值和告警路由。每补齐一类，就用一次真实或模拟故障验证告警是否按预期触发、路由是否正确、恢复通知是否发出，确认闭环后再进入下一类。