Oracle Cloud Resource Analytics Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Observability and Management

1. Introduction

What this service is

Resource Analytics in Oracle Cloud (OCI) is the analytics experience used to understand how your infrastructure resources are behaving over time—especially utilization and capacity signals that answer questions like “Are we sized correctly?” and “Where are we wasting spend or risking saturation?”

Simple explanation (one paragraph)

If you run workloads on Oracle Cloud (and often also across hybrid environments), Resource Analytics helps you look beyond point-in-time metrics and instead analyze trends—so you can spot underutilized resources, capacity risks, and growth patterns before they become incidents or unnecessary costs.

Technical explanation (one paragraph)

In OCI, Resource Analytics is commonly surfaced as part of OCI’s Observability and Management portfolio—most often associated with Operations Insights-style workflows (for example, analyzing host and database resource usage trends). It relies on telemetry collected from your environments (OCI Compute and, depending on setup, other hosts/databases), then provides filtering, aggregation, and drill-down analysis to support capacity planning and operational decision-making. Verify the exact product placement and current console navigation in official docs, because Oracle updates naming and navigation periodically.

What problem it solves

Resource Analytics helps solve: – Capacity planning: knowing when CPU, memory, or storage will become a bottleneck. – Rightsizing: identifying overprovisioned resources (cost waste) and underprovisioned resources (performance risk). – Operational visibility: giving engineering and operations teams a consistent view of utilization trends across fleets, compartments, and environments. – Decision support: providing data-driven evidence for scaling, migration, and architecture changes.

2. What is Resource Analytics?

Official purpose

In Oracle Cloud’s Observability and Management context, Resource Analytics is intended to help you analyze resource utilization and capacity trends so you can plan, optimize, and operate cloud resources more effectively.

Because Oracle documentation and console experiences can evolve, treat the following as the practical, commonly implemented scope: – Resource Analytics is typically a console-driven analytics capability built on top of collected resource telemetry. – It is often encountered alongside (or within) Operations Insights capabilities that focus on utilization and capacity planning.
Verify in official docs whether Oracle currently presents Resource Analytics as a standalone service entry, a sub-feature, or a set of pages under another service.

Core capabilities

Resource Analytics commonly focuses on: – Trend analysis (not just real-time monitoring) – Fleet-level views across groups of resources – Filtering and segmentation (for example by compartment, tags, or resource type—availability depends on your setup) – Drill-down from aggregated views into individual resources – Operational reporting for capacity and utilization

Major components (conceptual)

Depending on your exact OCI configuration, Resource Analytics usually involves:

Component	What it does	Notes
Data sources (OCI resources)	Produce raw utilization signals (CPU, memory, storage, etc.)	Signals can come from native OCI telemetry and/or agents
Data collection mechanism	Collects/ships telemetry for analysis	Often involves agents for non-native targets; verify supported methods
Analytics layer / dashboards	Aggregates, trends, and visualizes utilization	This is what users typically call “Resource Analytics”
IAM / Policies	Controls who can view or administer analytics	OCI IAM policies determine access
Audit and governance	Records relevant API/console actions	OCI Audit is commonly used for governance

Service type

Resource Analytics is best understood as a managed analytics capability within OCI’s Observability and Management ecosystem. It is not “just charts”; it is designed for planning and optimization using historical and trend-based views.

Scope: regional vs global

OCI observability services are typically regional (you select a region in the OCI Console). Resource Analytics generally follows that model: – You view and operate Resource Analytics in a specific region – Data residency and visibility may be region-scoped – Cross-region aggregation may require separate setup or external tooling
Verify region/tenancy scoping in the official Resource Analytics / Operations Insights docs for your OCI tenancy.

How it fits into the Oracle Cloud ecosystem

Resource Analytics complements: – Monitoring: for real-time metrics, alarms, and operational alerting – Logging / Logging Analytics: for log search, parsing, and log-derived insights – APM: for application-level tracing and performance – Operations Insights (commonly adjacent): for capacity planning, performance trends, and utilization analysis across hosts and databases
In many organizations, Resource Analytics becomes the “capacity planning lens” while Monitoring is the “real-time alerting lens.”

3. Why use Resource Analytics?

Business reasons

Reduce cloud waste by identifying idle/overprovisioned resources.
Avoid outages by detecting utilization trajectories that predict saturation.
Improve forecasting for budgeting and procurement planning.
Support FinOps by providing utilization evidence for rightsizing decisions.

Technical reasons

Trend-based analysis for CPU/memory/storage vs. relying on point-in-time metrics.
Fleet perspectives: see patterns across many resources rather than one-by-one inspection.
Data-driven scaling: choose vertical/horizontal scaling based on historical evidence.

Operational reasons

Helps SRE/Operations teams answer:
“Which hosts are trending toward CPU exhaustion?”
“Which environments are overallocated?”
“What changed after a release window?”
Supports runbook improvements and proactive maintenance.

Security / compliance reasons

Better governance when teams can prove resources are sized appropriately and monitored.
When paired with OCI IAM and Audit, you can enforce:
separation of duties
least privilege access to analytics views
traceability of administrative actions

Scalability / performance reasons

Prevents “silent” performance degradation caused by sustained high utilization.
Enables planning for growth (seasonality, campaigns, end-of-quarter spikes).

When teams should choose it

Choose Resource Analytics when you need: – Capacity planning and rightsizing based on historical utilization – A standardized utilization analytics workflow for OCI resources – A complement to Monitoring that focuses on optimization and planning

When teams should not choose it

Resource Analytics may not be the best fit when: – You only need basic real-time metrics and alarms (Monitoring may be sufficient) – You need deep application tracing (APM is the correct tool) – You need complex cross-cloud analytics and custom KPIs (you may prefer a centralized observability data lake and BI tooling) – You cannot deploy required collectors/agents for your environment (if applicable)

4. Where is Resource Analytics used?

Industries

SaaS and technology platforms (capacity planning for multi-tenant systems)
Financial services (predictable performance and compliance reporting)
Healthcare (availability and performance planning for regulated systems)
Retail/e-commerce (seasonality and event-driven scaling)
Media and gaming (spiky demand and performance-sensitive infrastructure)

Team types

Cloud platform teams (standardization and governance)
SRE and operations teams (proactive capacity planning)
DevOps teams (release impact analysis and scaling validation)
FinOps teams (rightsizing and spend optimization)
Security teams (operational governance and audit readiness)

Workloads

Compute fleets (web tiers, batch workers, CI runners)
Stateful workloads (databases, caching layers) — scope depends on what telemetry you onboard
Hybrid workloads (OCI + on-prem) — if supported by your telemetry collection approach

Architectures

Single-region apps needing capacity forecasting
Multi-environment setups (dev/test/prod) with compartment segmentation
Hub-and-spoke network models where teams manage separate compartments
Shared services platforms where central Ops monitors many app teams

Real-world deployment contexts

Production: proactive planning, monthly capacity reviews, incident prevention
Dev/test: identify underutilization, shut down or downsize, validate performance baselines after changes

5. Top Use Cases and Scenarios

Below are realistic scenarios for Resource Analytics in Oracle Cloud.

1) Rightsizing compute instances

Problem: Instances run at <10% CPU most days but remain expensive.
Why Resource Analytics fits: Trend views show sustained low utilization and variability.
Example: A dev fleet of 80 instances shows <5% CPU after business hours; downsize shapes or schedule stop/start.

2) Forecasting CPU saturation for a service tier

Problem: CPU steadily increases week over week; risk of latency spikes.
Why it fits: Trend analysis supports growth projections and planning.
Example: API tier average CPU climbs from 35% to 65% over 6 weeks; scale out before next release.

3) Detecting memory pressure trends

Problem: Frequent OOM events but unclear whether it’s transient or sustained.
Why it fits: Historical memory trends reveal whether memory pressure is chronic.
Example: Batch workers show sustained 90% memory during nightly jobs; increase memory shape or optimize workload.

4) Identifying noisy neighbors or uneven fleet load

Problem: Some hosts are hot while others are idle.
Why it fits: Fleet-level analytics highlight distribution and outliers.
Example: 10% of hosts consume 70% of CPU; rebalance workloads or adjust autoscaling policies.

5) Validating post-migration performance

Problem: After moving to OCI, performance is “okay” but not measured.
Why it fits: Before/after comparisons using consistent metrics.
Example: Compare 30-day utilization trends pre- and post-migration to validate sizing.

6) Capacity planning for seasonal spikes

Problem: End-of-quarter spikes cause resource contention.
Why it fits: Trend + seasonality patterns inform reserved capacity planning.
Example: Retail traffic peaks monthly; plan shape changes or scaling rules ahead of peak windows.

7) Budget-driven optimization (FinOps)

Problem: Cloud bill rising; need evidence-based cuts.
Why it fits: Utilization evidence supports rightsizing without risking SLOs.
Example: Identify persistent underutilized instances in non-prod and enforce resizing policy.

8) Incident prevention through trend thresholds

Problem: Alerts fire only when resources are already maxed.
Why it fits: Trend-based review finds “approaching saturation” resources.
Example: Weekly review flags resources with upward CPU trend; fix before incidents.

9) Executive reporting and KPI tracking

Problem: Leadership asks, “Are we using what we pay for?”
Why it fits: Aggregated analytics can support utilization KPIs and reports.
Example: Monthly report: percent of fleet within target utilization band.

10) Environment hygiene (dev/test)

Problem: Dev/test resources left running idle.
Why it fits: Trend analytics expose idle periods.
Example: Identify instances idle for 14 days; automatically terminate or stop.

11) Planning storage growth

Problem: Storage usage is creeping up; uncertain runway.
Why it fits: Growth curves help plan expansions and cleanup.
Example: Log volume growth predicts full capacity in 45 days; implement retention and archive.

12) Consolidation and platform standardization

Problem: Too many custom shapes and inconsistent provisioning.
Why it fits: Shows utilization by shape/class to guide standards.
Example: Standardize to fewer shapes that better match utilization profiles.

6. Core Features

Note: Oracle’s exact feature list and naming can change. The items below reflect the common Resource Analytics capability set in OCI’s Observability and Management ecosystem. Verify in official docs for the exact availability in your tenancy/region and the service that hosts the Resource Analytics pages.

1) Historical utilization analysis

What it does: Provides time-windowed views (days/weeks/months) of utilization.
Why it matters: Point-in-time metrics can hide chronic issues.
Practical benefit: Confident rightsizing and capacity planning.
Caveats: Retention windows and granularity depend on service configuration and pricing.

2) Aggregation across fleets

What it does: Summarizes utilization across many resources (for example, a group of hosts).
Why it matters: Operations teams manage fleets, not one server.
Practical benefit: Faster identification of systemic inefficiency.
Caveats: Requires consistent onboarding and tagging/compartment hygiene to be meaningful.

3) Filtering and segmentation

What it does: Filter by dimensions (commonly compartment, resource type, time range; sometimes tags).
Why it matters: Enables “show me prod only” or “only this application’s resources”.
Practical benefit: Reduced noise; better ownership.
Caveats: Tag-based filtering depends on consistent tag usage.

4) Drill-down into individual resources

What it does: Move from summary to individual charts and details.
Why it matters: You need both macro and micro views.
Practical benefit: Quickly isolate a problematic host from a fleet.
Caveats: Some signals may be unavailable if a resource wasn’t onboarded during that period.

5) Consistent utilization KPIs (CPU, memory, storage, I/O depending on target)

What it does: Presents common KPIs for resource planning.
Why it matters: Standard KPIs improve cross-team alignment.
Practical benefit: Shared language for planning (e.g., CPU headroom).
Caveats: Exact metrics vary by resource type and collection method.

6) Integration with OCI IAM (governance)

What it does: Access controlled via OCI IAM policies.
Why it matters: Prevents unauthorized access to operational data.
Practical benefit: Separation of duties between viewers and administrators.
Caveats: Overly broad policies (“manage all-resources”) create risk.

7) Auditability (via OCI Audit)

What it does: Administrative actions can be audited through OCI’s audit trail.
Why it matters: Compliance and incident investigations.
Practical benefit: Trace “who changed onboarding / settings”.
Caveats: Audit coverage depends on which APIs are invoked; validate in OCI Audit.

8) Works alongside Monitoring/Alarms

What it does: Resource Analytics supports planning; Monitoring supports alerting.
Why it matters: You need both proactive planning and reactive detection.
Practical benefit: Use Resource Analytics trends to tune Monitoring alarm thresholds.
Caveats: Not all analytics signals automatically translate into alarms; you may need custom metrics/alarms.

7. Architecture and How It Works

High-level architecture

At a high level, Resource Analytics relies on: 1. Resources producing telemetry (OCI Compute and other supported targets) 2. Collection/ingestion into an OCI-managed analytics backend (exact mechanism depends on your configuration) 3. Analytics views (dashboards, tables, trend charts) in the OCI Console 4. Access controls through OCI IAM 5. Governance via Audit, compartments, and tagging

Request/data/control flow (conceptual)

Data path: resource → telemetry collection → analytics backend → console visualizations
Control path: admin enables onboarding and access policies → users query views and drill down
Security: IAM authorizes access; data is encrypted in transit/at rest (per OCI platform standards)

Integrations with related services (typical)

Resource Analytics commonly coexists with: – OCI Monitoring for metrics and alarms – OCI Logging for logs (and troubleshooting) – OCI Notifications for alert delivery (if you implement alarms) – OCI Audit for governance and traceability – OCI Vault if secrets/credentials are required for onboarding certain targets (depends on what you onboard)

If you intend to export analytics or create cross-domain reports, you may integrate with: – Object Storage (for report exports or archives) – OCI Data Integration / Oracle Analytics (enterprise reporting)
These export/report patterns vary. Verify in official docs for supported export mechanisms.

Dependency services

Common dependencies in a real deployment: – IAM (Identity Domains / OCI IAM): users, groups, policies – Compartments: logical isolation and ownership boundaries – Network access: outbound connectivity from collectors/agents if used – Agents / collectors (when required): installed on hosts or configured for targets

Security/authentication model

End users authenticate via OCI Console (SSO / IAM).
Access is granted via policies.
Service-to-service interactions (if any) typically use OCI service principals and tenancy-scoped authorization.

Networking model

Console access is via HTTPS.
If agent-based telemetry is used, the agent requires:
outbound connectivity to OCI endpoints (public internet or private endpoints depending on your network design)
proper DNS resolution and time sync
Verify required endpoints and ports for your region and collector type.

Monitoring/logging/governance considerations

Use Audit to track administrative actions.
Use Logging for agent/collector logs where available.
Use consistent tagging to make analytics segmentation meaningful.
Consider quotas and limits for the underlying service.

Simple architecture diagram (Mermaid)

flowchart LR
  U[Engineer / SRE] -->|OCI Console| RA[Resource Analytics]
  R1[OCI Compute Instance(s)] -->|Telemetry| RA
  IAM[OCI IAM Policies] --> RA
  AUD[OCI Audit] --> RA

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Tenancy[OCI Tenancy]
    subgraph Compartments[Compartments]
      PROD[Prod Compartment]
      NONPROD[Non-Prod Compartment]
      SHARED[Shared Services Compartment]
    end

    subgraph Sources[Telemetry Sources]
      C1[OCI Compute Fleet]
      C2[Autoscaled Worker Fleet]
      DB1[Database Targets\n(if onboarded)]
      HYB[On-prem / Hybrid Hosts\n(if supported)]
    end

    subgraph Collect[Collection Layer]
      AG[Collectors / Agents\n(if required)]
      NET[VCN / Routing / NAT\nor Private Connectivity]
    end

    subgraph Obs[Observability and Management]
      RA[Resource Analytics\n(Analytics Views)]
      MON[Monitoring / Alarms]
      LOG[Logging / Logging Analytics]
      NOTIF[Notifications]
      AUD[Audit]
    end

    IAM[IAM: Users, Groups, Policies]
  end

  C1 --> AG --> RA
  C2 --> AG --> RA
  DB1 --> AG --> RA
  HYB --> AG --> RA

  RA --> MON
  MON --> NOTIF
  IAM --> RA
  AUD --> RA
  LOG --> RA
  NET --- AG

8. Prerequisites

Tenancy requirements

An active Oracle Cloud tenancy.
Access to the OCI region where you will use Resource Analytics.
Compartment strategy (at least one compartment for the lab).

Permissions / IAM roles

You need permissions to: – create/manage required resources in a compartment (compute/network for lab) – access Resource Analytics views – onboard telemetry sources (if required)

For a lab, the simplest (but overly broad) policy is:

Allow group <YourGroupName> to manage all-resources in compartment <YourCompartmentName>

This is not least privilege.
Use only for short-lived labs.
For production, use service-specific policies from official documentation. Verify in official docs the exact policy “verbs” and “resource-types/service families” required for Resource Analytics and any associated onboarding service.

Billing requirements

You need a billing-enabled tenancy.
Some Resource Analytics capabilities may incur charges depending on:
retention
number of monitored resources
module enablement
Verify pricing for your exact configuration (see Pricing section).

Tools

OCI Console access
SSH client (for compute instance access in the lab)
Optional: OCI CLI (not required for this tutorial)

Region availability

Availability varies by service and region.
Verify your region supports the Resource Analytics workflow you plan to use.

Quotas/limits

Expect limits around: – number of onboarded resources/targets – data retention/granularity – API rate limits
Check Service Limits in the OCI Console and the official docs for the underlying service exposing Resource Analytics.

Prerequisite services (lab)

To keep the lab practical, we’ll use: – OCI Compute – VCN networking – A telemetry onboarding path (commonly agent-based) if your Resource Analytics workflow requires it
If your tenancy already has the necessary telemetry for Resource Analytics without additional onboarding, you can skip the agent portion.

9. Pricing / Cost

Important: Oracle pricing can be region-dependent and can change. Resource Analytics is often part of a larger Observability and Management service (commonly associated with Operations Insights-style capabilities). Do not rely on fixed numbers from third parties. Always validate in official Oracle pricing pages and the OCI cost estimator.

Current pricing model (how to think about it)

Because Resource Analytics is typically a capability layered on top of OCI’s observability/insights services, pricing commonly depends on: – Which module/service actually provides Resource Analytics in your tenancy – How many resources/targets you onboard (hosts, databases, etc.) – Data retention and granularity – Any required collectors/agents and their supporting infrastructure (compute/networking)

In many observability platforms, cost dimensions often include: – number of monitored entities – data ingestion volume – retention duration – advanced analytics features
Verify in official docs/pricing which of these apply specifically to Resource Analytics in OCI today.

Free tier

OCI offers an Always Free tier for some core infrastructure services. Whether Resource Analytics (or the associated insights module) has an always-free allowance can vary.
Verify free tier eligibility in official Oracle documentation and pricing pages.

Cost drivers

Direct drivers: – enabling a paid insights/analytics module (if applicable) – number of onboarded resources and retention settings

Indirect drivers: – compute instances used as telemetry collectors (if you deploy them) – outbound network traffic from hybrid sources (if applicable) – storage for exported reports (Object Storage) – additional observability services you pair with Resource Analytics (Logging Analytics, APM, etc.)

Network/data transfer implications

OCI generally charges for some types of data egress (especially internet egress).
If you onboard hybrid sources sending telemetry to OCI, consider:
private connectivity (FastConnect / VPN) vs public internet
data volume and compression
region selection to reduce cross-region traffic

How to optimize cost

Start with a small scope: onboard only critical compartments/resources.
Use shorter retention for high-granularity data if supported.
Enforce tagging so you can identify and decommission waste.
Build a monthly cadence: rightsizing and cleanup based on trend insights.
Use budgets and cost tracking tags to allocate costs.

Example low-cost starter estimate (model, not numbers)

A low-cost start typically means: – 1 Always Free compute instance (where eligible) – minimal telemetry onboarding – default retention
Your costs then come mostly from any paid analytics module if required. The best practice is to model your environment in the OCI Cost Estimator.

Example production cost considerations (what to plan for)

In production, cost planning should include: – total number of resources onboarded across all compartments – staging vs production separation – retention policy aligned to compliance and operational needs – additional observability pipelines (alarms/notifications/logging)

Official pricing and calculators

OCI Pricing overview: https://www.oracle.com/cloud/pricing/
OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html
OCI price list (SKUs): https://www.oracle.com/cloud/price-list/

For the most accurate view, locate the Observability and Management section in the official price list and confirm where Resource Analytics is billed (standalone vs part of another service).

10. Step-by-Step Hands-On Tutorial

This lab is designed to be beginner-friendly, safe, and low-cost where possible. It focuses on getting a small environment in place and then using Resource Analytics to examine utilization trends.

Because Oracle can present Resource Analytics within another service’s console experience (often aligned with Operations Insights), the exact page names may differ by tenancy/region. The workflow below sticks to OCI-native patterns and calls out places where you must follow the current console prompts.

Objective

Deploy a small OCI Compute instance and view its resource utilization trends using Resource Analytics (as exposed in your OCI tenancy), validating that telemetry is being collected and that you can drill into host-level analytics.

Lab Overview

You will: 1. Create a compartment and minimal lab network. 2. Launch a small compute instance. 3. Configure permissions for your user/group (lab-safe approach). 4. Onboard the instance into the Resource Analytics data pipeline (often via an OCI agent/collector workflow). 5. Explore Resource Analytics views and validate data. 6. Clean up resources to avoid ongoing charges.

Step 1: Create a compartment for the lab

In the OCI Console, open the navigation menu.
Go to Identity & Security → Compartments.
Click Create Compartment.
Name it: ra-lab
(Optional) Add a description: Resource Analytics lab compartment
Click Create Compartment

Expected outcome – You have a dedicated compartment ra-lab to isolate lab resources.

Verification – In the Compartments list, open ra-lab and confirm it shows as Active.

Step 2: Create a group and add your user (if needed)

If you already have appropriate admin permissions, you can skip this step.

Go to Identity & Security → Groups
Click Create Group
Name: ra-lab-admins
Create the group
Go to Users, open your user, and add it to ra-lab-admins

Expected outcome – Your user is in a group that you can assign policies to.

Verification – In your user details, confirm ra-lab-admins is listed under groups.

Step 3: Create a lab policy (broad permissions for short-lived lab)

In production you should write least-privilege policies. For a short lab, use a broad policy to reduce friction.

Go to Identity & Security → Policies
Ensure you are in the root compartment (policies are usually created there to reference child compartments).
Click Create Policy
Name: ra-lab-policy
In the policy statements, add:

Allow group ra-lab-admins to manage all-resources in compartment ra-lab

Create the policy

Expected outcome – Your group can create/manage resources in ra-lab.

Verification – Open the policy and confirm it is Active.

Common error – You still cannot create resources in ra-lab.
Fix: Confirm the policy is in the correct parent scope and references the correct compartment name.

Step 4: Create a VCN (network) for the compute instance

Switch to compartment: ra-lab
Go to Networking → Virtual Cloud Networks
Click Create VCN
Choose VCN with Internet Connectivity (wizard name may vary)
Accept defaults for a simple lab (VCN + public subnet + internet gateway + route table)
Create

Expected outcome – A VCN with a public subnet capable of outbound internet access.

Verification – In the VCN details: – Internet Gateway exists – Route table has a default route 0.0.0.0/0 to the Internet Gateway – Public subnet exists

Step 5: Launch a small compute instance

Go to Compute → Instances
Click Create Instance
Name: ra-lab-vm1
Place it in: – Compartment: ra-lab – VCN/subnet: your lab VCN public subnet
Choose an image (for example, an Oracle Linux image).
Choose a small shape (Always Free eligible if available in your tenancy/region).
Add an SSH public key (or use an existing one).
Create the instance.

Expected outcome – Instance ra-lab-vm1 is running with a public IP.

Verification – Instance state: Running – You can see a Public IPv4 address (if using a public subnet)

Step 6: SSH into the instance

From your local machine:

ssh -i /path/to/private_key opc@<PUBLIC_IP>

Expected outcome – You have a shell on the VM.

Verification – Run:

uname -a

You should see Linux kernel information.

Common errors – Permission denied (publickey): wrong username (opc for Oracle Linux images is common), wrong key, or SSH key mismatch. – Connection timed out: security list/NSG doesn’t allow ingress on port 22 from your IP.

Step 7: Onboard telemetry for Resource Analytics (agent/collector workflow)

This is the step where environments differ most.

In many OCI setups, Resource Analytics (especially if tied to Operations Insights-style features) requires an OCI agent/collector to send host telemetry.

7A) Locate the onboarding flow in the OCI Console

In OCI Console, go to Observability & Management.
Look for the service that contains Resource Analytics in your tenancy (commonly adjacent to Operations Insights).
Find an Onboarding / Add Host / Enable workflow.

Expected outcome – You find a guided onboarding page that provides: – prerequisites – any required agent download/install steps – a way to register the host into analytics

Verification – The console provides a “host registered / agent active” style status indicator after onboarding.

7B) Install the required agent (follow the console-provided command)

If the onboarding page provides a Linux install command, copy it exactly and run it on ra-lab-vm1 via SSH.

Example pattern (do not copy blindly; use the exact command from your console):

# Example pattern only — VERIFY in OCI Console instructions
# curl -L <oracle-provided-installer-url> | sudo bash

Expected outcome – The host is registered and begins sending telemetry.

Verification – In the relevant agent/collector page (often under Observability & Management), the agent status becomes Active (wording may vary). – In Resource Analytics, the host appears in the resource list (may take several minutes).

Common errors and fixes – Agent shows “Inactive”: – Confirm VM has outbound internet access (or required private endpoints) – Confirm system time is correct (NTP) – Confirm policies allow the service/agent to register in the compartment – No data in charts: – Wait 10–30 minutes depending on collection intervals and aggregation windows – Confirm the correct time range is selected in the UI

Step 8: Explore Resource Analytics and review utilization trends

Go to Observability & Management → Resource Analytics (or the product area where Resource Analytics appears).
Select your compartment ra-lab.
Locate ra-lab-vm1 in the resource list.
Open the resource details and review charts for: – CPU utilization trend – Memory utilization trend (if available) – Storage / filesystem trend (if available)

Expected outcome – You can see time-series charts and at least one utilization metric for the instance.

Verification – Change the time window (last hour, last day) and confirm the charts update. – If you generate activity on the VM, you should see a corresponding change after data refresh.

Step 9: Generate a small workload to see utilization changes (optional)

On the VM, run a short CPU load (safe, short-lived). If stress is not installed, you can use a simple loop:

# Simple CPU burn for ~60 seconds (adjust as needed)
end=$((SECONDS+60))
while [ $SECONDS -lt $end ]; do
  : $((2**20))
done

Expected outcome – CPU utilization increases briefly.

Verification – In Resource Analytics, check the CPU trend around that time window (may take time to appear depending on aggregation).

Validation

Use this checklist: – [ ] Instance ra-lab-vm1 is running – [ ] Telemetry onboarding shows agent/collector is active (if required) – [ ] ra-lab-vm1 appears in Resource Analytics – [ ] At least one utilization trend chart shows data – [ ] You can change time range and filter by compartment

If one item fails, use the Troubleshooting section below.

Troubleshooting

Symptom	Likely cause	Fix
VM not reachable via SSH	Security list/NSG ingress missing	Allow TCP/22 from your public IP; confirm public IP
Agent/collector won’t activate	No outbound access / DNS / time drift	Confirm route to IGW/NAT, DNS, NTP
Resource not visible in analytics	Wrong compartment/region	Confirm region selector and compartment filter
Charts are empty	Data not yet aggregated	Wait; widen time range (24h); confirm onboarding succeeded
Access denied in console	Missing IAM permission	For lab, use the broad policy; for production, follow official least-privilege policies

Cleanup

To avoid ongoing charges:

Terminate the compute instance: – Compute → Instances → ra-lab-vm1 → Terminate
Delete VCN resources (or delete the VCN created by wizard).
Delete any agents/collector registrations created for the lab (where applicable).
Remove the policy ra-lab-policy if you don’t need it.
(Optional) Delete the compartment ra-lab after all resources are removed.

Expected outcome – No billable resources remain from the lab.

11. Best Practices

Architecture best practices

Design Resource Analytics usage around ownership boundaries:
compartments per application/team/environment
tags for app, cost center, environment
Use Resource Analytics for planning and Monitoring for alerting—don’t conflate the two.
Standardize resource shapes and deployment patterns so utilization comparisons are meaningful.

IAM/security best practices

Avoid manage all-resources outside of labs.
Create separate groups:
resource-analytics-viewers (read-only)
resource-analytics-admins (onboarding/config)
Restrict access to sensitive compartments (prod) and enforce least privilege.
Use MFA and identity governance processes for privileged roles.

Cost best practices

Onboard only what you need first (prod critical paths), then expand.
Right-size based on multi-week data, not a single day.
Review utilization monthly; decommission idle resources.
Coordinate with FinOps to track savings from rightsizing actions.

Performance best practices

Validate time windows and aggregation granularity when interpreting trends.
Ensure telemetry sources are stable:
good network connectivity
stable agent versions (if used)
Correlate utilization with workload patterns (deploy windows, batch schedules).

Reliability best practices

Treat onboarding/telemetry as a dependency:
document it in runbooks
monitor agent health (if supported)
Use compartments and tagging to reduce accidental misconfiguration.

Operations best practices

Establish a recurring cadence:
weekly: review top outliers and hot spots
monthly: rightsizing and capacity forecast review
Record decisions and outcomes (e.g., “downsized from shape X to Y based on 30-day data”).

Governance/tagging/naming best practices

Use consistent tags:
Environment = prod/dev/test
Application = app name
Owner = team/email
CostCenter = finance code
Naming:
include env + app + function: prod-orders-api-01
Use tag defaults (where appropriate) at the compartment level to enforce consistency.

12. Security Considerations

Identity and access model

OCI IAM controls who can:
view analytics
onboard resources
change configurations
Prefer group-based access and avoid user-specific policies.
Separate duties between onboarding/admin and viewers/auditors.

Encryption

OCI services typically provide: – encryption in transit (TLS) – encryption at rest for managed services
For any data retention and telemetry storage specifics, verify in official docs for the service that underpins Resource Analytics in your tenancy.

Network exposure

Keep telemetry traffic private where possible:
private subnets + NAT for outbound
private connectivity for hybrid (VPN/FastConnect)
Restrict SSH access:
limit inbound CIDR to your corporate IP
prefer bastion patterns for production

Secrets handling

If onboarding requires credentials (for example, database credentials in some setups): – Store secrets in OCI Vault – Rotate credentials – Use least privilege DB accounts – Avoid embedding secrets in scripts or instance metadata

Audit/logging

Use OCI Audit to track changes:
policy changes
onboarding actions
Centralize logs where possible and enforce retention policies.

Compliance considerations

Define retention consistent with compliance requirements.
Ensure compartment and IAM boundaries align with regulatory scopes (prod vs dev/test).
Maintain evidence: reports of utilization and rightsizing decisions can help demonstrate operational governance.

Common security mistakes

Granting broad permissions permanently (e.g., manage all-resources)
Onboarding production resources without validating data access boundaries
Leaving SSH open to the internet (0.0.0.0/0)
Not tagging resources, making it hard to detect shadow IT or abandoned infrastructure

Secure deployment recommendations

Use least privilege policies and dedicated admin groups.
Use private subnets and controlled egress where feasible.
Enable auditing and review logs regularly.
Adopt standardized onboarding procedures with peer review.

13. Limitations and Gotchas

The exact limitations depend on the OCI service exposing Resource Analytics in your tenancy. Validate these points in official docs.

Known limitations (typical)

Region scoping: analytics views are often region-specific.
Data latency: analytics are not always real-time; aggregation can take minutes to hours.
Retention constraints: longer retention or finer granularity may cost more or require configuration.
Coverage gaps: if a host/target isn’t onboarded, it won’t appear in analytics.

Quotas and limits

Limits on number of onboarded entities/targets (hosts, databases, etc.)
API throttling limits
Service limits per region/tenancy
Check in OCI Console: Governance & Administration → Limits, Quotas and Usage (navigation may vary).

Regional constraints

Some advanced insights modules may not be available in all regions.
Cross-region comparisons may require external aggregation.

Pricing surprises

Costs can scale with:
number of onboarded resources
retention duration
additional modules enabled
Hybrid telemetry can increase network costs (egress or private connectivity).

Compatibility issues

If agents/collectors are required, support may vary by:
OS versions
host types
network restrictions (proxy requirements)
Verify supported platforms in official docs.

Operational gotchas

Misleading conclusions from short time windows (use at least 2–4 weeks for rightsizing).
Missing tags/compartment hygiene reduces the value of segmentation.
Over-alerting if you convert trend insights into aggressive Monitoring alarms.

Migration challenges

When migrating workloads into OCI, you may have incomplete history; plan a baseline period before making aggressive rightsizing decisions.

Vendor-specific nuances

OCI compartment and policy model is powerful but can be complex—incorrect scoping is a common root cause of access issues.

14. Comparison with Alternatives

Resource Analytics overlaps with—but is not identical to—monitoring dashboards, recommendation engines, and capacity planning tools.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Resource Analytics (Oracle Cloud)	Capacity planning and utilization trend analysis inside OCI	OCI-native governance (IAM/compartments), operational planning workflows	Exact capabilities depend on underlying OCI module; may require onboarding/agents	When you want OCI-aligned resource utilization analytics and planning
OCI Monitoring	Real-time metrics + alarms	Native metrics, alarms, integrations with Notifications	Not primarily designed for long-horizon capacity planning	When you need alerting and near real-time visibility
OCI Logging Analytics	Log-derived analytics and troubleshooting	Powerful log search/parse and analytics	Focused on logs, not utilization planning	When the problem is log insight and incident triage
OCI APM	Application tracing and performance	Traces, spans, app-level latency breakdowns	Doesn’t replace infra capacity analytics	When you need application-level observability
AWS Compute Optimizer	Rightsizing recommendations in AWS	Recommendations with AWS context	AWS-only; different governance model	When your workloads are primarily on AWS
Azure Advisor / Azure Monitor Insights	Recommendations + monitoring in Azure	Integrated recommendations	Azure-only	When your workloads are primarily on Azure
Google Cloud Recommender + Cloud Monitoring	GCP recommendations and monitoring	Good GCP-native tools	GCP-only	When your workloads are primarily on GCP
Prometheus + Grafana (self-managed)	Custom metrics/analytics anywhere	Flexible, portable, highly customizable	Ops overhead, scaling, retention cost complexity	When you need cross-cloud/hybrid custom observability and can run it reliably
Commercial AIOps platforms (various)	Cross-domain analytics and automation	Correlation across metrics/logs/traces	Can be expensive and complex	When you need enterprise-wide observability across multiple clouds

15. Real-World Example

Enterprise example (regulated industry)

Problem: A financial services company runs core APIs and batch processing on OCI. They face periodic performance issues during month-end close and struggle to justify capacity increases.
Proposed architecture:
Compartments: prod, nonprod, shared
Standard tagging across all resources (CostCenter, Application, Environment)
Resource Analytics used for monthly capacity review and rightsizing proposals
OCI Monitoring alarms for near real-time saturation signals
OCI Audit enabled and reviewed for governance
Why Resource Analytics was chosen:
Need long-horizon utilization trends for evidence-based capacity planning
Need governance aligned with OCI IAM and compartment model
Expected outcomes:
Reduced unplanned scaling events during month-end
Clear audit trail for changes and capacity decisions
Improved utilization efficiency without breaching SLOs

Startup/small-team example

Problem: A startup runs a small OCI footprint but sees costs creeping up as features ship. They suspect dev/test is wasteful.
Proposed architecture:
Simple compartments: prod, dev
Scheduled monthly Resource Analytics review:
- identify idle instances
- downsize non-prod shapes
Lightweight Monitoring alarms for critical prod signals
Why Resource Analytics was chosen:
Need quick, visual trend insight without building custom tooling
Expected outcomes:
Lower spend by removing idle resources
More predictable performance due to proactive resizing
Better operational discipline as the team grows

16. FAQ

1) Is Resource Analytics a standalone OCI service?

In many tenancies, Resource Analytics is presented as an analytics experience within OCI’s Observability and Management portfolio, often associated with Operations Insights-style workflows. Verify the current Oracle Cloud console navigation and docs for how it is surfaced in your region.

2) Do I need to install an agent to use Resource Analytics?

Sometimes. Some analytics require agent/collector onboarding for host or database telemetry—especially for hybrid targets. For OCI-native resources, some signals may already exist. Follow the onboarding workflow in your console and verify in official docs.

3) How is Resource Analytics different from OCI Monitoring?

Monitoring focuses on real-time metrics and alarms. Resource Analytics focuses on historical trends and planning. Many teams use both.

4) Can Resource Analytics help reduce cloud costs?

Yes—indirectly—by providing utilization evidence for rightsizing and decommissioning. Cost savings still require you to take action (resize/terminate/scale policies).

5) Does it support compartments and tagging?

OCI governance is built around compartments, and many analytics workflows support compartment scoping. Tag-based segmentation depends on the feature set you have enabled. Verify tag filtering support in your console.

6) How long does it take for data to appear?

Often minutes to tens of minutes depending on collection and aggregation. For some trend views, you may need hours/days to see meaningful patterns.

7) Is Resource Analytics real-time?

Typically it is not “real-time” in the alerting sense. Use OCI Monitoring alarms for near real-time alerting.

8) What’s a good time window for rightsizing decisions?

Use at least 2–4 weeks of data, and include peak periods (month-end, batch windows, campaigns).

9) Can I use Resource Analytics for on-prem resources?

Potentially, depending on supported onboarding/collectors. This is common in hybrid capacity planning tools. Verify supported targets in official docs.

10) Can I export Resource Analytics reports?

Some OCI services provide export/reporting mechanisms; others do not, or they vary by module. Verify export/report capabilities in official docs.

11) What IAM pattern should I use?

Use separate roles: – viewers (read-only analytics) – admins (onboarding/config) Avoid broad “manage all-resources” outside of short-lived labs.

12) How do I troubleshoot missing resources?

Check: – region selector – compartment filter – onboarding/agent health (if required) – IAM permissions

13) How does Resource Analytics affect performance on the host?

If an agent is used, it typically has some overhead. In production, validate overhead in a staging environment and follow Oracle’s sizing guidance. Verify agent resource requirements in official docs.

14) Is Resource Analytics suitable for Kubernetes workloads?

It can be useful at the node/compute layer or via whatever telemetry targets are onboarded. For pod-level metrics, Kubernetes-native monitoring stacks may be needed.

15) What’s the best way to operationalize Resource Analytics?

Create a cadence: – weekly outlier review – monthly rightsizing/capacity planning review Track actions and outcomes to prove value.

16) How do I avoid “analysis without action”?

Tie insights to runbooks: – If CPU < 10% for 30 days → downsize candidate – If CPU > 75% sustained → scale candidate – If storage growth predicts <30 days runway → cleanup/expand plan

17. Top Online Resources to Learn Resource Analytics

Because Resource Analytics may be surfaced within another OCI Observability and Management service, the most reliable learning path is through official OCI documentation for the related insights/analytics modules.

Resource Type	Name	Why It Is Useful
Official documentation	OCI Documentation main hub: https://docs.oracle.com/en-us/iaas/	Entry point to all OCI service docs and updated navigation
Official documentation	Observability & Management docs (browse services from OCI docs hub)	Helps locate the current service that exposes Resource Analytics in your tenancy
Official pricing	OCI Pricing overview: https://www.oracle.com/cloud/pricing/	Official pricing entry point
Official pricing	OCI Price List: https://www.oracle.com/cloud/price-list/	SKU-level detail for Observability and Management services
Official calculator	OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html	Model costs without guessing
Official architecture	OCI Architecture Center: https://docs.oracle.com/en/solutions/	Reference architectures and best practices
Official governance docs	OCI IAM Overview: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm	Authoritative guide to IAM, policies, compartments
Official governance docs	OCI Audit Overview: https://docs.oracle.com/en-us/iaas/Content/Audit/Concepts/auditoverview.htm	How to track actions for compliance and investigations
Official learning	Oracle Cloud Infrastructure Learning on Oracle University: https://education.oracle.com/	Structured training paths (availability varies)
Official videos	Oracle Cloud Infrastructure YouTube channel: https://www.youtube.com/@OracleCloudInfrastructure	Product updates and demos (verify current playlists for insights/analytics)

18. Training and Certification Providers

The following training providers may offer DevOps/Cloud/SRE training that can complement learning Resource Analytics in Oracle Cloud. Details vary—check each website for current course outlines and delivery modes.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams, beginners to advanced	DevOps tooling, cloud operations, monitoring fundamentals	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Students, engineers learning SDLC/DevOps	SCM, CI/CD, DevOps foundations	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations, monitoring/observability practices	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations engineers	SRE practices, reliability, incident management	Check website	https://www.sreschool.com/
AiOpsSchool.com	SREs, ops leaders, engineers	AIOps concepts, automation for operations	Check website	https://www.aiopsschool.com/

19. Top Trainers

These sites may provide trainer-led support, materials, or services related to DevOps/Cloud/SRE learning. Verify offerings directly on each site.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/Cloud training and guidance	Beginners to intermediate engineers	https://www.rajeshkumar.xyz/
devopstrainer.in	DevOps training content	DevOps engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps support/training	Teams needing short-term help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support services	Ops/DevOps teams needing troubleshooting help	https://www.devopssupport.in/

20. Top Consulting Companies

These organizations may provide consulting services that can help design, implement, or operationalize Oracle Cloud observability practices (including Resource Analytics-aligned workflows). Confirm scope and references directly with the provider.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting	Architecture, automation, operational processes	Observability rollout planning; compartment/tag governance; onboarding strategy	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	Tooling selection, implementation, team enablement	Build an observability operating model; create dashboards and runbooks	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting	CI/CD + operations improvements	Standardize monitoring/alerting; implement capacity review cadence	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Resource Analytics

OCI fundamentals:
compartments, VCNs, instances
IAM policies and groups
Observability fundamentals:
metrics vs logs vs traces
SLI/SLO basics
Basic capacity concepts:
CPU utilization vs CPU saturation
memory pressure and swapping
storage growth and IOPS

What to learn after Resource Analytics

OCI Monitoring deep dive:
custom metrics
alarms and notifications
Logging/Logging Analytics for incident triage
APM for application-layer performance
FinOps practices:
tagging strategy
budgets and chargeback/showback
rightsizing automation

Job roles that use it

Cloud Engineer / Cloud Ops Engineer
SRE / Reliability Engineer
DevOps Engineer
Platform Engineer
Cloud Architect
FinOps Analyst / Cloud Cost Engineer (in collaboration with engineering)

Certification path (if available)

Oracle’s certification offerings evolve. Check Oracle University for current OCI certifications and learning paths: – https://education.oracle.com/
Resource Analytics is usually learned as part of broader OCI Observability/Operations competencies rather than as a standalone certification topic.

Project ideas for practice

Build a monthly rightsizing report for non-prod compartments.
Create a capacity runway tracker (CPU and storage) for a critical service tier.
Implement a governance policy requiring tags (Owner, Environment, Application) and measure improvement in analytics segmentation.
Correlate release windows with utilization trends and document performance regressions.
Build a “top 10 hot hosts” and “top 10 idle hosts” operational dashboard (where supported).

22. Glossary

Compartment (OCI): A logical container for organizing and isolating OCI resources for access control and billing.
IAM Policy (OCI): A rule that grants a group (or dynamic group) permission to perform actions on resources in a scope (tenancy or compartment).
Telemetry: Operational data emitted by systems, commonly metrics, logs, and traces.
Utilization: How much of a resource is used (CPU %, memory used, disk used).
Saturation: A state where demand approaches or exceeds capacity (e.g., CPU pegged, I/O queueing).
Rightsizing: Adjusting resource size to better match demand to reduce cost and/or improve performance.
Retention: How long historical telemetry data is kept for analysis.
Granularity: The resolution of data points (e.g., 1-minute vs 1-hour averages).
SRE: Site Reliability Engineering; discipline focused on reliability using engineering practices.
SLI/SLO: Service Level Indicator / Objective; quantitative reliability/performance targets.
Fleet view: An aggregated view across many resources (hosts, instances, targets).
Drill-down: Navigating from summary analytics into details for a specific resource.

23. Summary

Resource Analytics (Oracle Cloud) is a utilization and capacity-focused analytics capability within OCI’s Observability and Management ecosystem. It helps teams move from reactive monitoring to proactive planning, using historical trends to rightsize resources, forecast capacity needs, and reduce operational risk.

Key takeaways: – Use Resource Analytics for trend analysis and capacity planning; use OCI Monitoring for real-time alerting. – Cost depends on which underlying OCI insights/analytics module is used, how many resources you onboard, and retention—verify pricing in official OCI pricing pages. – Secure it with least privilege IAM, compartment boundaries, strong tagging, and Audit governance. – Start small (one compartment, a few critical resources), validate data quality, then scale out with operational cadence and documented runbooks.

Next step: validate where Resource Analytics is surfaced in your OCI Console for your region, then expand the lab into a production-ready onboarding plan with least-privilege policies and a monthly capacity review process.

rajeshkumar

Category