📚 课程目录第2章 OCI监控服务基础

2. OCI监控服务基础

OCI 的可观测性并不是一个单一产品，而是由一组职责清晰、彼此衔接的服务组成。理解它们之间的分工，是后续做生产故障诊断的前提。本节聚焦其中最基础、也最常被一起使用的三个服务：Metrics（指标）负责“记录发生了什么”，Alarms（告警）负责“判断是否越界”，Notifications（通知）负责“把判断结果送达人”。三者串起来，才构成一条从数据到行动的完整链路。

一、三个服务的核心概念与资源模型

Metrics 是 OCI 的时序数据服务。它持续采集资源产生的数值型观测数据，例如 CPU 使用率、内存占用、磁盘读写字节数、网络丢包数等。每条指标数据点由四要素确定：命名空间（namespace）、指标名（metric name）、维度（dimensions）和时间戳。命名空间是最高层的分类，OCI 原生服务通常使用 oci_computeagent、oci_blockstore、oci_lbaas 这类命名空间；自定义指标则使用用户自己声明的命名空间，例如 myapp_prod。

Alarms 是建立在 Metrics 之上的规则引擎。它不产生数据，而是周期性地对某个指标查询结果做阈值判断。一个告警资源包含：查询语句（MQL）、触发阈值、评估窗口、触发条件（如连续 3 个数据点超过阈值）、告警严重级别（Critical / Warning / Info），以及触发后要执行的动作。Alarms 的状态机只有三种：OK、Firing、Reset，理解这个状态流转对排障非常重要。

Notifications 是消息分发服务。它本身不判断任何条件，只负责把消息按“主题（Topic）+ 订阅（Subscription）”模型投递出去。订阅协议支持 Email、HTTPS、PagerDuty、Slack、Oracle Functions、SMS 等。Alarms 触发时，会把消息发布到指定 Topic，Topic 再分发给所有订阅者。

三者的关系可以概括为：Metrics 是数据源，Alarms 是判断器，Notifications 是投递通道。Alarms 通过 Topic 与 Notifications 解耦，因此同一个 Topic 可以被多个告警复用，同一条告警也可以同时通知多个渠道。

二、指标命名空间与维度：定位数据的坐标

在 OCI 中查询指标，必须同时给出命名空间、指标名和维度，缺一不可。维度是键值对，用来区分同一指标下的不同实体。例如计算实例的 CPU 使用率指标，其维度通常包含 resourceId（实例 OCID）、resourceDisplayName、availabilityDomain 等。如果不指定维度，查询会返回该命名空间下所有匹配实体的聚合结果，这在排障时容易造成误判。

下面是一段典型的 MQL 查询示例，用于查询某台实例最近 5 分钟的 CPU 使用率：

CpuUtilization[5m].mean()
  .grouping()
  .namespace("oci_computeagent")
  .dimension("resourceId", "ocid1.instance.oc1..example")

其中 [5m] 是时间窗口，.mean() 是聚合函数，.grouping() 表示按维度分组。MQL 还支持 .max()、.min()、.sum()、.rate() 等统计函数，以及 .groupBy() 做多维度聚合。写告警查询时，务必确认维度是否精确到目标资源，否则告警可能因为聚合了多台实例而永远不触发，或者频繁误报。

三、快速创建第一个告警

下面以“某台计算实例 CPU 使用率连续 5 分钟超过 80% 时发送邮件”为例，走一遍完整流程。示例中的 OCID、邮箱均为占位值，实际使用时替换为真实值。

确认指标存在：进入 Observability & Management → Metrics Explorer，选择命名空间 oci_computeagent，指标 CpuUtilization，维度选择目标实例的 resourceId，确认能看到数据点。若看不到数据，先检查 Compute Instance Monitoring 插件是否已启用。
创建通知主题：进入 Notifications → Topics → Create Topic，名称填 topic-prod-alerts。创建后在 Topic 下新增 Subscription，协议选 Email，地址填 ops@example.com，并到邮箱中点击确认链接完成订阅验证。
创建告警：进入 Alarms → Create Alarm。查询部分填入上文的 MQL，或使用界面选择器：命名空间 oci_computeagent、指标 CpuUtilization、统计 Mean、区间 5 minutes、维度 resourceId = ocid1.instance...。
设置触发条件：Trigger Rule 选择 greater than，阈值填 80，触发延迟（Trigger Delay）设为 5 minutes，表示连续 5 分钟满足条件才触发。严重级别选 Critical。
绑定通知：在 Alarm 的 Notification 部分选择刚创建的 topic-prod-alerts，并填写告警消息正文，例如“实例 {resourceId} CPU 使用率超过 80%，请立即排查”。
验证：创建后可在 Alarm 详情页看到当前状态为 OK。若想快速验证链路，可临时把阈值改为 1，等待一个评估周期后观察状态是否变为 Firing，并确认邮箱收到通知，验证完成后改回 80。

告警的评估周期与触发延迟共同决定“多久才会响”。评估周期越短、触发延迟越小，响应越快，但噪声也越大。生产环境建议对 CPU、内存这类波动指标设置 5～10 分钟的触发延迟，对可用性类指标可以更短。

四、状态流转与排障要点

Alarms 的状态机是排障的核心线索。OK 表示当前未满足触发条件；Firing 表示条件已满足并已发出通知；Reset 表示曾经触发过、现在已恢复但尚未回到 OK。如果告警一直不触发，优先检查三件事：MQL 的维度是否精确、评估窗口内是否真的有数据点、触发延迟是否设置过长。如果告警频繁误报，则考虑提高阈值、拉长触发延迟，或改用 .max() 替代 .mean() 以过滤瞬时尖峰。