OCI Observability Professional cheat sheet

A metric namespace groups related metrics (for example oci_computeagent); a metric key is the specific measurement name inside that namespace, such as CpuUtilization.

Each metric data point carries dimensions (resource identifiers and free-form key/value pairs); query results can be filtered and grouped by dimension, and high-cardinality dimensions raise query cost and latency.

The Monitoring Query Language (MQL) statement shape is: metric source, then statistic, then optional group-by and interval, for example CpuUtilization[1m].mean() grouped by resourceId.

Basic monitoring emits metrics at 1-minute resolution for the standard service metrics; agent-based custom and compute metrics are also published on a 1-minute cadence by default.

Alarm evaluation uses a rolling window: the statistic is computed over the window (for example 5 minutes) and compared with the threshold; MQL alarms can use longer windows and richer expressions.

Alarm states are OK, FIRING, and RESET; RESET means the metric returned inside the threshold after firing, and notifications are driven by state transitions, not by raw values.

The Metrics API supports summarizing metrics (list with aggregation) and querying raw data points; retention of metric data is limited, so long-horizon analysis requires exporting or aggregating.

Health checks distinguish availability from performance: a resource can be reachable (health check passing) while latency or saturation metrics are degrading.

The Logging service ingests three source categories: agent-collected logs from compute instances, service logs emitted by OCI services, and custom logs pushed through the Ingestion API.

A log group is a logical container for logs; access policies and search scoping are applied at the log group and log level, so grouping by application or environment simplifies authorization.

An agent configuration specifies the log source path, the parser (for example syslog, apache, or a regex/JSON parser), and the destination log; one agent can host multiple configurations.

The unified monitoring agent plugin for logging must be enabled and associated with a dynamic group plus IAM policy allowing the instance to write to the target log.

Search syntax supports free-text terms, field filters, and time-range scoping; saved searches can be reused, and results can be exported for retention beyond the service window.

Service logs (for example VCN flow logs, audit logs, load balancer logs) are enabled per resource or per compartment and delivered to a chosen log, not collected by an agent.

Log retention is configurable per log; archived logs move to Object Storage, and the archival policy determines how long searchable data remains before it is archived.

Connector or stream-based export of logs to Object Storage or Streaming is the standard pattern for long-term retention and for feeding third-party SIEM tooling.

Audit logs record control-plane API activity and are a distinct service log category from data-plane or application logs; both can be routed to the same log group for correlation.

APM tracks distributed traces composed of spans; a trace is the full request path and each span represents one operation with timing, attributes, and parent-child relationships.

APM domains are the top-level isolation boundary for APM data (traces, spans, and configuration); a domain is created in a compartment and referenced by the APM agent or SDK.

The data key (a public/private key pair) authenticates agents and SDKs to an APM domain; the private key is used for upload and must be protected.

Instrumentation options include the Java and .NET APM agents (auto-instrumentation), the browser agent for real user monitoring, and manual spans via the APM SDK/API.

A span has a kind (server, client, producer, consumer, internal) and a status; error spans are those flagged with an error status or matching error-detection rules.

The trace explorer aggregates by dimensions such as service name, operation, and error flag, and surfaces latency percentiles (p50, p95, p99) rather than only averages.

Synthetic monitoring runs scripted browser or REST checks from multiple vantage points; results feed availability and latency metrics and can trigger alarms like any other metric.

APM alarms and metrics integrate with Monitoring: trace-derived metrics such as error rate and response time can be alarmed on with the same alarm engine used for infrastructure metrics.

A service connector defines a source, an optional task, and a target; it moves data continuously and is scoped to a compartment with IAM policies for both source read and target write.

Common sources are Logging (log group or log), Streaming, Object Storage, Monitoring (metric data points), and Schannel; common targets are Object Storage, Streaming, Notifications, Functions, and Logging Analytics.

Tasks transform data in flight: the Logging-to-Logging filter task selects log entries by query, and Functions tasks run custom code for enrichment or routing.

The connector's service principal must be granted policies; a missing policy on the target is the most common cause of a connector that runs but delivers nothing.

An alarm rule binds a metric query to a threshold, a severity, and a destination topic; the alarm's message and severity are what downstream consumers receive.

The Notifications service delivers to email, HTTPS webhook, PagerDuty, Slack, and SMS subscriptions; a subscription must be confirmed (for example via email link) before messages are delivered.

Alarm severity is informational, warning, or critical, and the notification message can include the metric value and dimensions via message-format placeholders.

Alarm history retains state transitions for a limited period; to keep an audit trail, route alarm notifications to a topic consumed by a Function or Streaming and persist them.

Repeat notifications re-send an alarm while it stays FIRING at a configured interval; suppressing repeats reduces noise but hides prolonged incidents from on-call.