Monitoring
The Monitoring domain tests how you convert OCI metrics into alarms that reach the right person, not just how to read a console chart. Metrics live in namespaces such as oci_computeagent, oci_blockstore, oci_vcn, and oci_lb. Each metric is a name plus dimensions (resourceId, instance, availability domain); a query without the right dimensions can silently aggregate away the resource you care about.
Queries and alarms
OCI Monitoring uses MQL. A query has the form metric[interval].statistic().groupBy(dimension). For example, CpuUtilization[5m].mean() > 80 evaluates the five-minute mean. The interval sets resolution; the statistic sets aggregation; groupBy makes the alarm evaluate each dimension combination separately. An alarm adds a threshold, severity (CRITICAL, WARNING, INFO), pending duration, repeat-notification setting, and an ONS topic. The alarm changes state only after the condition persists for the pending duration; notifications go to the topic's confirmed subscriptions. Metric streams summarize metrics across dimensions for dashboards and downstream use.
Worked example
You need an alarm when any compute instance exceeds 80% CPU for 10 minutes. Create an alarm in the compartment that owns the instances, use the query CpuUtilization[5m].mean() > 80, group by instance, set pending duration to 10 minutes, severity WARNING, and attach a topic with a confirmed email subscription. Reasoning: the 5-minute interval smooths spikes; the 10-minute pending duration avoids transient alerts; grouping by instance means one noisy instance fires without hiding others.
Traps
Agent metrics such as memory require the agent plugin; hypervisor metrics do not. A topic with an unconfirmed email subscription sends nothing. Alarms created in the wrong compartment do not see resources. A query that groups by a dimension the metric lacks returns nothing, and missing data is not the same as a breaching value.