Oracle Cloud Infrastructure (OCI) continues to evolve its observability stack, and one of the most critical yet under-discussed changes is documented in MOS note KA1304.

In this post, I will try to break down the technical implications, architectural impact, and recommended actions for enterprises relying on OCI Stack Monitoring.

---

1. What is KA1304 Really About?

At its core, KA1304 is tied to the deprecation of OCI Stack Monitoring.

• OCI Stack Monitoring provides:
  • Full-stack observability across applications and infrastructure
  • Metrics collection (performance, availability, errors, usage)
  • Alarm and anomaly detection
• It supports hybrid environments (on-prem + cloud)

However, Oracle has announced that:

Stack Monitoring is being deprecated and will remain available only until January 23, 2027

---

2. Why Oracle is Deprecating Stack Monitoring

From an architectural standpoint, Stack Monitoring represents a monolithic observability model. Oracle is now shifting toward:

a) Modular Observability Services

Instead of a single “all-in-one” tool, Oracle promotes specialized services:

• OCI Monitoring → metrics + alarms
• OCI Log Analytics → log-based intelligence
• Database Management → DB-centric insights
• Oracle Enterprise Manager → full lifecycle management

These services are listed as recommended alternatives .

b) Cloud-Native Design Philosophy

Modern observability trends emphasize:

• Decoupled telemetry pipelines
• Service-specific optimization
• ML-driven analytics

---

3. Technical Impact on Existing Deployments

If you are currently using Stack Monitoring, the impact falls into three categories:

3.1 Observability Coverage Risk

Stack Monitoring provides holistic topology-based monitoring. Replacing it requires:

• Reconstructing service relationships
• Rebuilding dashboards across multiple services

3.2 Automation & Integration Breakage

Custom integrations may depend on:

• Stack Monitoring APIs
• Metric pipelines
• Alarm templates

These must be re-engineered using alternative OCI services.

3.3 Operational Fragmentation

Moving to multiple services introduces:

• Tool sprawl
• Increased configuration overhead
• Cross-service correlation challenges

---

4. Migration Strategy (Recommended Approach)

A direct replacement is not feasible. Instead, adopt a layered migration model:

Step 1: Inventory Current Usage

Identify:

• Monitored resources (DB, middleware, hosts)
• Custom metrics and alerts
• Dependencies on Stack Monitoring APIs

Step 2: Map Capabilities

Stack Monitoring Feature	Replacement
Infrastructure metrics	OCI Monitoring
Log analysis	OCI Log Analytics
DB performance	OCI Database Management
Enterprise-wide observability	Oracle Enterprise Manager

Step 3: Rebuild Observability Pipelines

• Use OCI Monitoring for metrics ingestion
• Use Log Analytics for correlation
• Integrate alerts via OCI Notifications

Step 4: Validate Coverage

Ensure parity in:

• Alert thresholds
• SLA monitoring
• Incident response workflows

---

5. Architectural Insight: What This Means Long-Term

This is a shift,

From:

• Centralized monitoring platform
• Predefined topology discovery
• Unified UI-driven operations

To:

• Distributed observability services
• API-driven integrations
• Composable monitoring architecture

This aligns OCI with industry patterns seen in:

• Kubernetes-native observability
• OpenTelemetry pipelines
• Microservices-based monitoring

OCI Observability Migration Checklist

Having said the above, if you are using Stack Monitoring, a migration checklist like the below, might prove to be useful.

OMC / Stack Monitoring → OCI Monitoring + Log Analytics + DB Management + Enterprise Manager 24ai

---

1. Discovery & Baseline Assessment

Inventory Monitoring Coverage

• List all monitored entities:
  • Databases (Oracle / non-Oracle)
  • Middleware (WebLogic, etc.)
  • Compute instances (VM, bare metal)
  • Applications (custom / packaged)
• Identify environments:
  • OCI regions
  • On-prem / hybrid connectivity
• Export current topology (if using Stack Monitoring)

Identify Data Sources

• Metrics sources (CPU, memory, app metrics)
• Log sources (app logs, audit logs, DB logs)
• Events / alerts currently configured

Capture Current State

• Dashboards in use
• Alert thresholds and escalation rules
• Integrations:
  • ITSM (ServiceNow, etc.)
  • Notification systems (email, Slack, PagerDuty)

---

2. Dependency & Risk Analysis

API & Automation Dependencies

• Identify scripts using Stack Monitoring APIs
• Identify Terraform / OCI CLI automation tied to monitoring
• Check custom exporters or agents

Feature Gap Analysis

• Topology visualization (Stack Monitoring feature)
• Cross-tier correlation (app ↔ DB ↔ infra)
• Custom KPIs not natively supported

Risk Categorization

• Critical alerts that must not break
• Compliance-related monitoring (audit logs, retention)
• SLA/SLO tracking dependencies

---

3. Target Architecture Mapping

Map each capability to OCI services:

Capability	Target Service
Infra metrics & alarms	OCI Monitoring
Log ingestion & analytics	OCI Log Analytics
DB performance & tuning	OCI Database Management
Enterprise monitoring	Oracle Enterprise Manager 24ai

Architecture Decisions

• Define metrics pipeline design
• Define log ingestion strategy
• Decide on central vs federated dashboards
• Define alert routing architecture

---

4. Environment Preparation

Enable Required Services

• Activate OCI Monitoring
• Enable Log Analytics namespace & groups
• Enable Database Management for all DBs
• Deploy / upgrade Enterprise Manager 24ai (if used)

IAM & Security

• Create policies for:
  • Metrics ingestion
  • Log access
  • Alarm management
• Validate least-privilege access

Agent Deployment

• Install/upgrade OCI agents on compute instances
• Configure log collectors
• Validate connectivity (private endpoints if needed)

---

5. Metrics Migration

Recreate Metrics

• Map existing metrics → OCI Monitoring metrics
• Recreate custom metrics (if any)
• Validate metric namespaces and dimensions

Rebuild Alarms

• Recreate thresholds
• Validate alarm triggers
• Configure notifications (OCI Notifications)

Validation

• Compare old vs new alert behavior
• Run synthetic tests (CPU spike, DB load, etc.)

---

6. Log Migration

Log Onboarding

• Identify all log sources
• Configure ingestion pipelines
• Assign log groups

Parsing & Enrichment

• Define parsers for custom logs
• Validate field extraction
• Enable indexing for key attributes

Correlation

• Build queries for:
  • Error detection
  • Performance anomalies
• Validate search latency and accuracy

---

7. Database Monitoring Migration

Enable DB Management

• Enable for all Oracle DB systems
• Configure performance hub access

Feature Mapping

• Replace:
  • AWR-based insights
  • SQL performance tracking
• Validate:
  • Wait events
  • Top SQL queries

---

8. Dashboard & Visualization Rebuild

• Recreate dashboards in OCI Monitoring
• Build log dashboards in Log Analytics
• Create cross-service views (manual correlation)
• Validate executive vs operational dashboards

---

9. Integration Rewiring

• Reconnect ITSM tools (ServiceNow, etc.)
• Configure webhook integrations
• Update notification channels
• Validate incident workflows end-to-end

---

10. Testing & Validation

Functional Testing

• Trigger test alerts
• Validate log ingestion
• Confirm DB metrics visibility

Performance Testing

• Check latency of alerts
• Validate log query performance

Coverage Validation

• Ensure no blind spots vs old system
• Validate all critical systems monitored

---

11. Cutover Strategy

Parallel Run

• Run Stack Monitoring + new stack in parallel
• Compare outputs for 2–4 weeks

Gradual Cutover

• Migrate non-critical systems first
• Move critical workloads after validation

Final Switch

• Disable Stack Monitoring alerts
• Keep fallback window (1–2 weeks)

---

12. Decommissioning

• Remove Stack Monitoring configurations
• Archive historical data if needed
• Decommission agents if obsolete
• Update documentation

---

13. Post-Migration Optimization

• Tune alert thresholds (reduce noise)
• Optimize log retention policies
• Implement cost controls
• Introduce automation (auto-remediation)

Conclusion

If your organization depends on Stack Monitoring, the time to act is now. The sooner you redesign your observability strategy around the new/ replacement options, the smoother your transition will be.