Independent multicloud observability field guide
Start with where telemetry originates. Follow its vendor-neutral contract, egress path, and control-plane handoff into the L0 to L4 maturity path.
Independent and community-built. Not an Oracle product. Architecture guidance is separated from documented service capability.
Each environment is a structural peer. The route changes to show collection, contract, egress, handoff, and destination.
Choose one goal first. We will recommend a default route and explain its operational consequence. Role and industry are optional refinements, not prerequisites.
IAM controls who can see and manage each destination. O&M is the OCI service family used throughout this guide.
Choose the pattern that looks most like your estate. We show where to start, explain the consequence, and highlight the relevant L0 to L4 route.
· select any service to inspect it
Each level answers a sharper operating question, from governance through classic observability to AI systems. Service health is expressed through an SLO; metric logic uses MQL. Select a capability to open the inspector, then switch between executive, architect, and practitioner lenses.
Is the platform ready to be observed safely?
Before a single metric flows, give observability a governed home: a dedicated compartment, least-privilege IAM, consistent tags, secrets in Vault, and tenancy-wide Audit.
Is it healthy, and what just happened?
Turn on the three native pillars: Monitoring, Logging, and Audit. Add Notifications and Events as the routing layer. Keep alarms actionable, assign severity by business impact, and send each alert to the accountable channel.
Why did it happen, and are we running out of room?
Make databases a first-class domain: Database Management for live diagnosis, Ops Insights for capacity and forecasting, Log Analytics for root-cause work, and the Management Agent for hybrid reach.
What is the business impact, and what can the platform handle on its own?
Stitch traces, logs, metrics, and database signals together with APM and OpenTelemetry, move data with Connector Hub, automate through Events, and layer on AI-assisted operations and forecasting.
Is the agent correct, grounded, safe, and improving? What is it allowed to do?
Agents are non-deterministic and drift silently, so they need more than the three pillars. Trace every reasoning step, judge output quality with a governed model, detect anomalies the SOC can read, and evolve under gated control: paired with Zero Trust enforcement and the OCI Secure AI Framework. See the deep dive below.
Most telemetry reaches OCI through an agent. Three types cover the cases: pick by where the target runs and what it emits. Use the Oracle Cloud Agent whenever it fits; reach for the others for hybrid targets and custom logs.
Preinstalled on OCI compute instances and the recommended default whenever it fits.
Low-latency interactive collection between OCI and IT targets, including external and on-premises.
Open-source, fluentd-based ingestion of custom logs into OCI Logging.
Source: "Demystifying logging and monitoring agent types in OCI Observability and Management": Royce Fu, OCI Observability blog.
Autonomous agents fail in non-obvious ways: a confident but wrong answer returns a normal status code. OCI answers this with three connected disciplines across the AI adoption lifecycle.
"Zero Trust decides what an agent is allowed to do. Observability tells you what it actually did and whether it is getting better or worse. You need both."
The umbrella secures three surfaces: models, data, and agents. Six principles span the adoption lifecycle and ship through the Enterprise Landing Zone as policy-as-code.
Defines what is securedThe agent execution trust boundary. A policy gate and broker scope identity, allow-list tools, and authorize each action at the moment it happens: producing a decision ledger.
Decides what an agent may doThe detective and evaluative half. Trace agent behaviour, judge it with LLM-as-a-judge, detect drift, and evolve under gated control. The decision ledger becomes a primary data source.
Tells you what it actually didOne OpenTelemetry instrumentation feeds OCI Observability and Management and an open-source stack, then evaluation and action. Select any service to inspect it.
OpenTelemetry GenAI conventions
Agent, tools, and broker Zero Trust decision ledgerRedact and route
OpenTelemetry CollectorOCI O&M + open source
Grafana · Prometheus · Tempo · LokiLLM-as-a-judge
Gate, govern, alert
Tighten Zero Trust policyThe pipeline ends in action, not a dashboard: evaluation results and detected drift flow into the controlled-evolution loop and back into Zero Trust policy. Based on the OCI AI Observability for Agents whitepaper.
The same observability estate looks different to each role. Here is what each persona recognises, what they do with it, and the levels they live in.
These views and rights are not ad hoc: each persona maps to an OCI Group with policies scoped to the right compartments. The pattern is two levels per scope: an admin group that manages the services, and a reader group with read-only access for monitoring and reporting. The groups live in the Landing Zone Common Identity Domain. See the scoping model below.
OCI Security tells you something is wrong; observability tells you what, where, and why. The Security portfolio: Cloud Guard and Cloud Guard Instance Security, IAM & Identity Domains, Data Safe, Access Governance, Audit, and Zero Trust Packet Routing: detects and enforces. Observability turns those signals into correlated, explainable visibility, and forwards them to whatever security tooling you already run.
Cloud Guard + Instance Security, IAM & Identity Domains, Data Safe, Access Governance, Audit, and ZPR find misconfigurations, threats, risky access, and policy drift.
Route findings through Service Connector into Log Analytics for ML clustering and MITRE-mapped detections; correlate with APM traces, metrics, and dashboards for the full picture.
SOC and operations share one correlated view to reduce MTTR. The same Service Connector → Streaming / REST API paths can fan out to third-party SIEMs such as Splunk, Microsoft Sentinel, Elastic, and Datadog.
The multitenant approach goes beyond access scoping. The operating pattern uses centralized aggregation: forward log and event records from every tenant and cloud into Oracle Log Analytics (Logan), then correlate them by a common key while each tenant remains isolated by compartment and IAM. Keep Prometheus exporter metrics in the metric backend and link APM traces through shared trace context. Cross-tenancy collection is not automatic; it relies on per-source forwarding and IAM cross-tenancy policies. This is a custom build for operators running OCI Alloy, Dedicated Region (DRCC), or a multitenant ISV / SaaS platform.
Documented Oracle Log Analytics ingestion paths include the Management Agent, on-demand or REST upload, Object Storage, OpenTelemetry logs, and Connector Hub. Connector Hub can also bring in custom and cross-tenancy logs from OCI Streaming. Logan adds curated sources, active and archive storage, clustering, link analysis, detections, and dashboards. Use shared entity, workload, and trace identifiers to correlate those records with metrics and APM traces. The same routing paths can fan out to third-party SIEM and observability tools through approved shippers or OCI Functions.
Each collection and export path maps to a working repository. Mix and match them to ingest multicloud records into Oracle Log Analytics or fan OCI telemetry out to a third-party SIEM.
Stream Google Cloud logs into OCI Log Analytics: serverless, no VMs to run.
adibirzu/gcplogs2oci ↗ Azure → OCIForward Azure platform and resource logs into OCI Log Analytics.
adibirzu/azurelogs2oci ↗ Kubernetes → OCIFluentD (logs) + Management Agent (metrics), deployed by Helm. OKE and AWS EKS documented.
oracle-quickstart/oci-kubernetes-monitoring ↗ OCI → SplunkKafka Connect streaming from OCI into Splunk indexes for SIEM correlation.
adibirzu/oci-splunk ↗ OCI → SentinelTimer-triggered Azure Function reads OCI Streaming, enriches, and ships to Sentinel: E2E tested.
adibirzu/oci2azurelogs ↗ LA contentReusable Logging Analytics sources and parsers for security and operations use cases.
adibirzu/LoggingAnalyticsFiles ↗ ZPR → LACollect and correlate ZPR flows into Log Analytics detection dashboards.
adibirzu/oci-zpr-visibility ↗ ReferenceShop + CRM + Java sidecar with APM, Monitoring and Log Analytics assets, load and autoscaling.
adibirzu/octo-observability-demo ↗Within each tenancy, access is scoped by compartment and IAM: Tenancy, Platform, and Environment / Project observability teams, each an admin and a reader OCI group. Adding a tenant, environment, or project is repetition: clone the compartment, group, and policy.
Pick a host tenancy and source tenancies; route via Service Connector Hub, Streaming, or Object Storage; and grant the IAM cross-tenancy Define / Endorse / Admit policies. It is not automatic.
A log group and compartment per tenant: access control rides on compartment-scoped log groups, not on a shared tenant_id field alone.
Management Agent install keys per target tenancy and namespace, secrets in Vault, key rotation, and Management Gateway or private egress for hybrid sources.
Private endpoints and Service Gateway where applicable, Zero Trust Packet Routing and segmentation, and an audit trail of operator access.
Log Analytics is regional. Cross-tenancy sharing requires source and target tenancies subscribed to the same regions; honour residency boundaries.
Plan ingest volume, active and archive retention, recall cost, Connector Hub delivery semantics, duplicate handling, and service limits.
The ladder maps cleanly onto an observability maturity model. Find your current state, and the next column is your next move.
Tenancy and Landing Zone exist, with little to no governed telemetry. Monitoring is ad hoc or absent.
maps to · pre-Level 1Infrastructure metrics, central logging, basic alarms, and notification standards. Troubleshooting is manual.
maps to · Level 1 to 2Database performance monitoring, SQL diagnostics, capacity forecasting, and log analytics are in play.
maps to · Level 3Distributed tracing, telemetry correlation, anomaly detection, automated remediation, and service SLOs.
maps to · Level 4 to 5Curated from the Oracle DevRel technology-engineering observability library, the OCI Observability blog, and team publications. Open any service in the ladder to see the relevant links inline.
The OCI AI Observability for Agents whitepaper cites this as its worked example. In this multi-service drone-retail stack, every browser click, FastAPI request, Spring Boot span, and Oracle ATP query shares one trace context. A GenAI multi-agent workflow is traced end to end into OCI APM and Langfuse. Deploy in 5–10 minutes with OCI Resource Manager.
