OCI Observability Professional common mistakes
OCI Observability Professional · Understand the traps and how to avoid them.
Assuming every OCI resource type emits metrics to the Monitoring service automatically, then debugging an empty metric chart as if the agent were broken.
Candidates generalize from Compute to all services. In reality metrics come from three different paths: service-published metrics (many managed services publish to a namespace without any agent), the Compute agent plugins (which must be enabled per instance and can be disabled at the image or instance level), and custom metrics pushed via the Monitoring API. A missing metric is usually a wrong namespace, a wrong dimension filter, or a disabled agent plugin, not a platform failure.
What to do instead
Before troubleshooting, classify the resource: is it a managed service with a published namespace, a compute instance needing the monitoring/management agent, or a custom metric? Verify the namespace and dimensions in the metric explorer, then check agent plugin status on the instance. Practice listing metric namespaces and metric data for a known resource so you can tell 'no data' from 'wrong query'.
Confusing the Monitoring service's metrics with Logging Analytics entity metrics, or expecting Logging Analytics to appear in the same namespace as infrastructure metrics.
Both products are observability tools and both mention 'metrics', so candidates conflate them. Monitoring stores time-series metrics queried by namespace and dimensions; Logging Analytics ingests log data into log sets and sources and derives its own fields. A query written against the wrong service returns nothing, and candidates then misdiagnose ingestion.
What to do instead
Memorize the boundary: Monitoring = metrics and alarms; Logging = log groups, logs, and search; Logging Analytics = log sources, parsers, entities, and log-set-based analysis; APM = traces and spans. When a question says 'metric' ask which service owns it, and when it says 'log field' answer with Logging Analytics concepts.
Writing alarm queries without the correct statistic, interval, and dimension grouping, so a CPU alarm fires on the wrong aggregation or never fires at all.
Candidates treat alarm queries like ad hoc charts. An alarm query must specify a metric, a statistic (for example mean, max, or count), an interval aligned with the metric's frequency, and dimensions that match the actual resource. Using max instead of mean, or omitting a dimension, changes which data points are evaluated and can make the threshold meaningless.
What to do instead
For every alarm, write out the metric, statistic, interval, dimensions, threshold, and evaluation period, then sanity-check against a chart of the same query. Know that the alarm evaluates the query's aggregated result, not each individual data point, and that a missing data point is not automatically a breach unless the alarm is configured to treat it that way.
Treating Logging as a single flat bucket and ignoring log groups, log retention, and the difference between the Logging service and Logging Analytics.
The console surfaces 'Logs' in several places, and candidates assume everything lands in one searchable place. In practice logs are organized into log groups and logs, retention is configured per log, and Logging Analytics ingestion requires a source and often a service connector or agent. Searching the wrong log group or expecting Logging Analytics fields in the Logging search yields empty results.
What to do instead
Map the path: resource or agent → log group → log → search. Confirm retention and the log's lifecycle state. When a question involves parsing, field extraction, or log sets, switch to Logging Analytics concepts. Practice enabling a log on a resource and searching it, then ingesting the same data into Logging Analytics to see the difference.
Assuming enabling logging on a resource is enough for the data to be queryable, without checking the agent, the log group association, or the ingestion path.
Many OCI services require an explicit 'enable log' action that creates or attaches a log to a log group, and compute logs require the agent with the appropriate plugin. Candidates enable one layer and expect end-to-end visibility, then blame the query when nothing appears.
What to do instead
Trace the pipeline end to end: is the source emitting, is the log enabled on the resource, is it attached to the intended log group, is the agent plugin running, and is retention long enough? Verify with a recent-time search and check the log's last ingestion time before writing more queries.
Confusing APM trace concepts - spans, traces, and the APM domain - and expecting APM to collect data without an APM domain and a configured data key or agent.
APM is a distinct service with its own domain resource and ingestion credentials. Candidates assume enabling APM is a toggle on the application, then wonder why no traces appear. They also mix up span attributes with log fields or metric dimensions when writing queries.
What to do instead
Learn the APM setup sequence: create an APM domain, obtain the data upload endpoint and data key, configure the application or agent to send traces, then query spans by trace ID, service, or operation. Keep span attributes separate from log fields and metric dimensions in your mental model, and know that trace retention and sampling affect what you can see.
Diagnosing a slow application from infrastructure metrics alone, without correlating APM traces to the specific downstream call or span.
Candidates default to CPU and memory charts because those are familiar. A latency problem often lives in a specific span - a database call, an external HTTP request, or a queue wait - that infrastructure metrics cannot isolate. Without trace correlation the candidate picks the wrong root cause.
What to do instead
Start from the trace: find the slow span, note its service and operation, then correlate to logs and metrics for the same time window and resource. Use span duration breakdowns to distinguish self-time from downstream time. Practice reading a trace waterfall and identifying which span dominates total latency.
Building a Service Connector Hub connector without verifying the source-to-target compatibility, the IAM policy for the service principal, and the connector's lifecycle state.
Service Connector Hub moves data between a source (such as a log group or a stream) and a target (such as a stream, bucket, function, or Monitoring), and each pairing has its own requirements. Candidates configure the source and target but forget the policy that lets the connector read the source and write the target, or leave the connector in an inactive state, then conclude the integration is broken.
What to do instead
For each connector, confirm the source type, the target type, that the pairing is supported, the required IAM policy for the connector's service principal, and that the connector is active. Check the connector's metrics and error information to see whether it is reading or failing. Practice one connector end to end and inspect its state after creation.
Configuring an alarm without a working notification path - no topic, no subscription, or an unconfirmed subscription - and assuming the alarm is broken because nobody was notified.
The alarm, the Notifications topic, and the subscription are three separate resources. An alarm can be in firing state while the topic has no confirmed subscriber, or the subscription may be pending confirmation. Candidates check only the alarm's state and miss the downstream delivery step.
What to do instead
Verify the chain: alarm → topic → subscription → confirmed endpoint. Confirm the subscription is confirmed, the topic is in the alarm's notification target, and the alarm's severity and message are set. Test with a deliberate breach or a published message to the topic, and know that Notifications supports multiple subscription protocols with different confirmation behavior.
Ignoring the distinction between an alarm's state (OK, firing, or insufficient data) and its history, and misreading 'insufficient data' as a breach or as a healthy state.
Candidates focus on the threshold and forget that an alarm can be in a third state when the query returns no data. They either treat insufficient data as an outage or dismiss it, when in fact it usually signals a broken query, a stopped resource, or a metric that is not being published.
What to do instead
Learn the three alarm states and what each means for the query. When you see insufficient data, check the metric namespace, dimensions, interval, and whether the resource is still emitting. Use alarm history to see state transitions over time rather than only the current state, and design the alarm's missing-data behavior deliberately.