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

1. Introduction

Oracle Cloud WebLogic Management is an Observability and Management service focused on operational visibility for Oracle WebLogic Server environments. It helps you discover WebLogic domains, understand their topology, and monitor their health so operations teams can detect issues earlier and reduce mean time to resolution (MTTR).

In simple terms: install an Oracle Cloud agent on the host(s) running WebLogic, connect it to your Oracle Cloud tenancy, and then use WebLogic Management in the Oracle Cloud Console to view WebLogic domains, servers, and runtime signals in one place.

Technically, WebLogic Management uses Oracle Cloud’s management plane (including the Management Agent framework and OCI Observability services such as Monitoring and Logging, depending on how you enable data collection) to ingest telemetry from WebLogic runtime targets. You use OCI Identity and Access Management (IAM) to control who can discover domains, view metrics, and act on operational insights.

The problem it solves: WebLogic estates are often spread across many VMs, environments, and teams. Without consistent telemetry and access control, operations becomes reactive: troubleshooting relies on logging into servers, hunting for logs, and manually correlating symptoms. WebLogic Management centralizes inventory and visibility so you can standardize monitoring, reduce manual toil, and improve operational governance.

Naming note: Oracle documentation sometimes refers to this capability as WebLogic Management Service. In the OCI Console and service naming for this tutorial, WebLogic Management is treated as the primary, current service name. Verify the exact naming in your region’s console and the latest docs if you see a different label.

2. What is WebLogic Management?

Official purpose (high level): WebLogic Management in Oracle Cloud provides centralized visibility and management-oriented monitoring for Oracle WebLogic Server domains. Its primary value is to give you a consolidated view of domain topology and operational signals across environments.

Core capabilities (typical scope)

WebLogic Management commonly focuses on:

Discovery and inventory of WebLogic domains and servers
Topology views (domain → clusters → managed servers → host mapping)
Operational monitoring signals (health/availability-style views and key metrics depending on enabled collectors)
Integration with OCI Observability and Management building blocks (for example: Monitoring alarms and Logging, where configured)

Because Oracle Cloud services evolve, treat the exact metric sets and views as implementation-specific. Verify in official docs which WebLogic versions, data sources, and collectors are currently supported.

Major components (conceptual)

Most deployments involve:

WebLogic runtime targets
WebLogic Admin Server / Managed Servers running on OCI Compute instances, OCI VM clusters, or on-prem hosts.
OCI Management Agent
A host-level agent installed on the WebLogic host(s) that securely communicates outbound to OCI endpoints. It is often used across multiple Observability and Management services.
WebLogic Management service control plane
The OCI Console experience and APIs (where available) that organize discovered domains, show topology, and surface insights.
OCI Observability backends (commonly used) – OCI Monitoring (metrics, alarms) – OCI Logging (log collection and routing)
– Optional: Logging Analytics, Notifications, Events, depending on your operating model

Service type

WebLogic Management is a managed Oracle Cloud service in the Observability and Management category.

Scope (how it’s typically scoped in OCI)

Tenancy: Service is available within an OCI tenancy.
Region: OCI services are generally regional; you select a region in the OCI Console. Telemetry endpoints and resource views are typically regional.
Compartment: Configuration, discovered resources, and access control are generally compartment-scoped via OCI IAM policies.

If your organization operates multi-region WebLogic estates, plan for a per-region view and consistent compartment structure. Confirm exact scoping behavior in the latest WebLogic Management docs for your region.

How it fits into the Oracle Cloud ecosystem

WebLogic Management fits alongside other Oracle Cloud Observability and Management services such as:

Monitoring (metrics and alarms)
Logging / Logging Analytics
Notifications
Operations Insights (capacity/performance analytics—may apply depending on data sources and supported integrations)
Application Performance Monitoring (APM) (application-level tracing; complementary rather than a replacement)

WebLogic Management is especially relevant when your platform team needs WebLogic-specific topology awareness and an OCI-native operational experience.

3. Why use WebLogic Management?

Business reasons

Reduce downtime cost by improving detection time and troubleshooting speed.
Standardize operations across business units that run WebLogic differently.
Improve audit readiness by centralizing visibility and access control via OCI IAM.

Technical reasons

Topology-aware visibility: WebLogic-specific object model (domain/cluster/server) is more useful than generic host monitoring alone.
Consistent data ingestion via OCI’s agent framework and observability services.
Integrates with OCI-native alerting and routing patterns (alarms → notifications → incident workflows).

Operational reasons (SRE/Platform/DevOps)

Faster triage: identify which domain/cluster is impacted without logging into multiple servers.
Central inventory: know what is running where, at least at a WebLogic domain level.
Automation enablement: alarms and event-driven workflows can be attached to telemetry.

Security/compliance reasons

Least privilege access via OCI IAM policies (compartments, groups).
Centralized logging/monitoring can improve tamper resistance compared to logs scattered across hosts.
Separation of duties: platform ops can manage monitoring without needing OS-level access everywhere.

Scalability/performance reasons

Scales with estate size better than ad-hoc scripts and manual checks.
Lets you adopt consistent monitoring patterns across dev/test/prod.

When teams should choose it

Choose WebLogic Management when: – You run Oracle WebLogic Server and want OCI-native discovery/visibility. – You’re standardizing observability across multiple WebLogic domains and environments. – You want to integrate WebLogic visibility with OCI Monitoring/Logging/Notifications workflows.

When teams should not choose it

Avoid or deprioritize WebLogic Management when: – You do not run WebLogic Server (it is WebLogic-focused by design). – You need deep code-level tracing and service maps as the primary requirement (consider OCI APM or application instrumentation in addition). – You have a mature centralized enterprise platform (for example, Oracle Enterprise Manager) and OCI integration doesn’t add value for your operating model.

4. Where is WebLogic Management used?

Industries

Financial services (payments, fraud platforms, core banking middleware)
Telecom (ordering, billing, network orchestration middleware)
Public sector (case management and citizen services)
Retail (order management and legacy Java middleware)
Healthcare (integration hubs, claims processing middleware)
Manufacturing (ERP integrations and middleware gateways)

Team types

Platform engineering teams operating WebLogic as a shared service
SRE teams responsible for middleware reliability
DevOps teams modernizing legacy Java app platforms
Security and compliance teams needing centralized visibility signals
Operations teams managing large VM fleets

Workloads

Java EE/Jakarta EE applications hosted on WebLogic
SOA-style integration apps (where WebLogic is used as the hosting layer)
Legacy monoliths and middleware components still critical to business

Architectures

Single-domain environments for smaller teams
Multi-domain, multi-cluster estates across environments (dev/test/prod)
Hybrid deployments (on-prem WebLogic + OCI WebLogic)
Hub-and-spoke networking with centralized security controls

Real-world deployment contexts

WebLogic on OCI Compute instances in private subnets
WebLogic behind OCI Load Balancer (public or private)
WebLogic with OCI Bastion for controlled admin access
WebLogic integrated with OCI Vault for secrets (application side)

Production vs dev/test usage

Production: strongest value; operational visibility, alarms, governance, and incident response workflows.
Dev/Test: useful for standardizing telemetry early and preventing “works in dev” blind spots, but be mindful of telemetry ingestion costs (logs especially) and access control.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud WebLogic Management is commonly a fit.

1) Centralized WebLogic domain inventory

Problem: Teams don’t have an accurate list of domains/clusters/servers and where they run.
Why it fits: WebLogic Management discovery builds a consistent inventory view.
Example: A platform team consolidates 40+ domains across departments into compartment-based views.

2) WebLogic topology-aware incident triage

Problem: An outage ticket says “app is down,” but it’s unclear which cluster is failing.
Why it fits: Domain/cluster/server topology helps pinpoint scope.
Example: Ops identifies a single managed server degraded vs. an entire cluster impacted.

3) Standardized operational dashboards for middleware ops

Problem: Each team uses different scripts and tools; no standard runbook signals.
Why it fits: WebLogic Management provides a common UI and integrates with OCI observability.
Example: A shared NOC dashboard shows key WebLogic targets across regions.

4) Alarm-driven on-call notifications

Problem: Issues are discovered late because nobody is watching console logs.
Why it fits: OCI Monitoring alarms and Notifications can trigger on thresholds/health signals (where supported).
Example: A critical alarm pages on-call when a domain’s key metrics cross a threshold.

5) Hybrid visibility (on-prem WebLogic + OCI ops plane)

Problem: WebLogic is on-prem, but operations wants cloud-based monitoring and governance.
Why it fits: With outbound agent connectivity, on-prem hosts can report to OCI (subject to supported configurations).
Example: A regulated enterprise centralizes monitoring in OCI while keeping workloads on-prem.

6) Environment separation with compartment governance

Problem: Dev teams must not see prod runtime signals.
Why it fits: OCI compartments + IAM policies enforce separation.
Example: Separate compartments for dev, test, prod with different access groups.

7) Post-migration verification (OCI landing)

Problem: After moving WebLogic to OCI, you need to confirm runtime stability.
Why it fits: Centralized monitoring reduces guesswork during migration.
Example: A migration factory uses WebLogic Management to validate every moved domain.

8) Operational readiness for regulated audits

Problem: Auditors require evidence of monitoring, alerting, and access controls.
Why it fits: OCI IAM, Audit logs, and centralized observability can support evidence gathering.
Example: Security exports monitoring configuration evidence and access policy reviews.

9) Reducing OS-level access needs

Problem: Too many engineers request SSH access “just to check status.”
Why it fits: WebLogic Management provides visibility without full server access (depending on what is exposed).
Example: App support uses WebLogic Management dashboards; only SRE has SSH.

10) Consolidated view during patch windows

Problem: Hard to confirm which domains recovered properly after maintenance.
Why it fits: Topology/monitoring views help validate post-change health.
Example: After OS patching, ops checks domain/server health and key metrics.

11) Fleet-wide baseline and anomaly spotting (where supported)

Problem: Some domains degrade slowly and go unnoticed.
Why it fits: Centralized metrics make baseline comparisons easier.
Example: Ops compares request/thread utilization patterns across domains.

12) Delegated ops for shared services

Problem: A central team runs WebLogic as a shared platform for many product teams.
Why it fits: Compartment and group policies allow controlled visibility per tenant/team.
Example: Product teams can view only their domain’s health in their compartment.

6. Core Features

Because Oracle Cloud services can evolve and features may vary by region and supported WebLogic versions, treat the items below as the core feature themes. Confirm exact details in the latest official docs.

6.1 Domain discovery and inventory

What it does: Identifies WebLogic domains and their constituent parts (domain/cluster/servers) and organizes them in OCI.
Why it matters: You cannot operate what you cannot confidently enumerate.
Practical benefit: Faster onboarding, standardized naming, fewer “unknown” runtime assets.
Limitations/caveats: Discovery typically requires correct agent deployment and permissions; supported domain configurations may be constrained—verify supported WebLogic versions and setups.

6.2 Topology visualization

What it does: Provides a topology-style view (logical relationships) rather than only host-level signals.
Why it matters: WebLogic incidents often depend on cluster membership, server roles, and traffic routing.
Practical benefit: Speeds up impact analysis and routing incidents to the correct team.
Limitations/caveats: Topology depth depends on what the agent can observe and what the service surfaces.

6.3 Metrics collection and monitoring integration

What it does: Collects WebLogic-related metrics and makes them available for monitoring workflows (dashboards/alarms) depending on your configuration.
Why it matters: Metrics enable proactive alerting and SLO-driven operations.
Practical benefit: Move from reactive log-grepping to quantified operations.
Limitations/caveats: Metric names, dimensions, and availability can vary—verify metric namespaces and supported alarms.

6.4 Logging integration (collection and routing)

What it does: Helps bring WebLogic logs into OCI Logging pipelines (where configured), enabling centralized retention and routing.
Why it matters: Logs are essential for forensic troubleshooting and audit trails.
Practical benefit: Central search, consistent retention policies, and easier SIEM export.
Limitations/caveats: Log ingestion volume can be a major cost driver; sensitive logs require careful handling and access control.

6.5 Compartment-based governance

What it does: Uses OCI compartments to scope resources and access.
Why it matters: Segregation of duties and environment isolation are foundational for enterprise operations.
Practical benefit: Clear boundary between prod and non-prod; easier chargeback and policy reviews.
Limitations/caveats: Poor compartment design leads to permission sprawl and operational confusion.

6.6 IAM policy control (least privilege)

What it does: Uses OCI IAM to control who can administer the service, view targets, and access telemetry.
Why it matters: Observability data can contain sensitive operational details.
Practical benefit: Auditable access patterns aligned with security requirements.
Limitations/caveats: IAM complexity can cause onboarding friction; plan roles carefully.

6.7 Integration with alarms and notifications

What it does: Uses OCI Monitoring alarms (and OCI Notifications) to deliver alerts to email, PagerDuty-like systems (via HTTPS), chatops, or ticketing integrations.
Why it matters: On-call needs deterministic triggers and routing.
Practical benefit: Consistent alert policy across domains/environments.
Limitations/caveats: Alarm configurations must be tuned to avoid alert fatigue.

6.8 Auditability (via OCI Audit)

What it does: OCI Audit records control-plane actions taken in the tenancy.
Why it matters: Compliance and incident investigation require knowing “who changed what.”
Practical benefit: Supports operational governance and security reviews.
Limitations/caveats: Audit logs don’t automatically include all runtime events; they capture API/control-plane actions.

7. Architecture and How It Works

High-level service architecture

At a high level:

You deploy WebLogic domains on hosts (OCI Compute or on-prem).
You install the OCI Management Agent on each host that should report telemetry.
The agent securely communicates outbound (typically HTTPS) to OCI endpoints in a region.
WebLogic Management uses that data to: – populate inventory/topology – surface operational views – integrate with Monitoring/Logging for alarms and retention (depending on configuration)

Request/data/control flow (conceptual)

Control plane actions: Admin config in OCI Console (IAM-controlled).
Data plane telemetry: Agent → OCI service endpoints.
Alerting: OCI Monitoring evaluates rules → Notifications delivers messages.
Logging: Logs are ingested to OCI Logging (optionally routed onwards).

Integrations with related services

Common integrations in Oracle Cloud Observability and Management:

OCI Monitoring: metrics, alarms, alarm history
OCI Notifications: email/HTTPS endpoints for alert delivery
OCI Logging: log ingestion, retention, routing
OCI Events: trigger automation when certain resource changes occur (where supported)
OCI Vault: recommended for secrets used by tooling around automation workflows
OCI IAM / Audit: governance, access control, auditing

Exact integration depth can vary. Use official WebLogic Management docs to confirm which telemetry sources map to which OCI observability features in your environment.

Dependency services

Typically required: – OCI IAM (users, groups, policies) – OCI compartments – Management Agent framework (agent install keys, agent resources)

Often used: – OCI Monitoring – OCI Logging – Notifications

Security/authentication model

Human access: OCI IAM users/groups; policies grant access to WebLogic Management resources and related observability resources.
Agent access: The Management Agent authenticates to OCI using an agent registration/installation mechanism (for example, install keys). Exact mechanics can differ—follow the install workflow in official docs.

Networking model

Agents generally require outbound connectivity from the host to OCI endpoints for the region.
In private subnet architectures, common patterns include:
NAT Gateway for outbound internet egress
Service Gateway for private access to supported OCI services (availability depends on service)
Corporate HTTP proxy if required by policy (verify agent support)

Monitoring/logging/governance considerations

Define what telemetry is collected in each environment (dev/test/prod).
Set retention policies for logs and metrics appropriate to compliance.
Use tags and naming standards to enable cost allocation and incident routing.
Apply IAM least privilege to restrict who can view prod telemetry.

Simple architecture diagram (Mermaid)

flowchart LR
  U[Ops / SRE Users] -->|OCI Console / IAM| WLM[WebLogic Management]
  subgraph Targets[WebLogic Targets]
    WLHost[Compute VM / On-Prem Host]
    WLS[WebLogic Domain\n(Admin + Managed Servers)]
    WLHost --> WLS
    Agent[OCI Management Agent] --> WLHost
  end
  Agent -->|HTTPS outbound| OCIObs[OCI Observability Endpoints]
  OCIObs --> WLM
  OCIObs --> Mon[OCI Monitoring]
  OCIObs --> Log[OCI Logging]
  Mon --> Alarm[Alarms]
  Alarm --> Notif[OCI Notifications]
  Notif --> OnCall[Email / HTTPS / Ticketing]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Tenancy[OCI Tenancy]
    subgraph IAM[IAM + Governance]
      Groups[Groups/Roles]
      Policies[Policies]
      Audit[OCI Audit]
      Tags[Tagging/Compartments]
    end

    subgraph RegionA[Region A]
      subgraph NetA[VCN - Private Subnets]
        LB[OCI Load Balancer]
        VM1[WebLogic Host 1]
        VM2[WebLogic Host 2]
        VM3[WebLogic Host 3]
        VM1 --- VM2 --- VM3
      end

      Agent1[Mgmt Agent] --> VM1
      Agent2[Mgmt Agent] --> VM2
      Agent3[Mgmt Agent] --> VM3

      WLM_A[WebLogic Management]
      MonA[Monitoring + Alarms]
      LogA[Logging]
      NotifA[Notifications]
      Vault[OCI Vault]
      SIEM[External SIEM / SOC]

      Agent1 -->|Outbound HTTPS| WLM_A
      Agent2 -->|Outbound HTTPS| WLM_A
      Agent3 -->|Outbound HTTPS| WLM_A

      WLM_A --> MonA
      WLM_A --> LogA
      MonA --> NotifA
      LogA -->|Log routing (optional)| SIEM
    end

    subgraph RegionB[Region B - DR (optional)]
      WLM_B[WebLogic Management]
      MonB[Monitoring]
      LogB[Logging]
    end
  end

  Users[Ops/SRE/Dev Teams] -->|Console/SDK| WLM_A
  Users -->|Least privilege| IAM

8. Prerequisites

Tenancy/account requirements

An Oracle Cloud (OCI) tenancy with permission to use Observability and Management services.
A compartment strategy (at minimum: one compartment for the lab).

Permissions / IAM roles

You typically need: – Permission to manage/read Management Agents (or the relevant agent resources). – Permission to use WebLogic Management resources in the target compartment. – Permission to read/write supporting services such as Monitoring and Logging if you enable them.

Because OCI policy verbs/resources can be specific, use the official docs for exact policy statements: – https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm
– WebLogic Management docs home (verify latest): https://docs.oracle.com/en-us/iaas/wls-management/home.htm

Billing requirements

WebLogic Management itself may be priced separately or may be included at no additional charge, depending on Oracle’s current model. Verify on official pricing.
You will almost certainly incur costs for:
Compute instances running WebLogic
Log ingestion/retention (if enabled)
Optional services (Logging Analytics, Notifications usage patterns, etc.)

CLI/SDK/tools needed

For the hands-on lab below, you can do everything in the OCI Console plus SSH into a host.

Recommended: – SSH client (OpenSSH) – Ability to install packages on the WebLogic host (sudo/root) – (Optional) OCI CLI for scripting: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm

Region availability

OCI services are region-specific. Ensure: – WebLogic Management is available in your chosen region – Your targets can reach that region’s endpoints

Verify in official docs/console for region availability.

Quotas/limits

Check tenancy limits for: – Compute instances (if you’ll create a VM for the lab) – Logging ingestion/retention – Any agent limits in your tenancy

View limits in OCI Console: Governance & Administration → Limits, Quotas and Usage.

Prerequisite services

A running WebLogic Server domain you can access on a host (OCI Compute or on-prem).
Network connectivity from that host to OCI endpoints required by the Management Agent.

If you do not already have a WebLogic domain, you can deploy one using “WebLogic Server for OCI” from Oracle Marketplace or existing enterprise automation. Licensing and cost varies (BYOL vs license-included). Verify current marketplace offerings and licensing terms.

9. Pricing / Cost

Pricing model (what to verify)

Oracle Cloud pricing changes over time and can be region-dependent. For WebLogic Management, confirm:

Whether WebLogic Management has a standalone hourly/monthly charge or is included as part of OCI Observability features.
Whether you are charged for:
Number of managed targets/domains
Metrics ingested / stored
Logs ingested / retained
Agent usage

Start with official sources: – OCI pricing list: https://www.oracle.com/cloud/price-list.html – OCI cost estimator: https://www.oracle.com/cloud/costestimator.html – WebLogic Management documentation: https://docs.oracle.com/en-us/iaas/wls-management/home.htm

If the pricing page does not explicitly list WebLogic Management, treat it as “pricing is bundled/implicit” and focus cost planning on the dependent observability and infrastructure services.

Pricing dimensions to consider

Even when the service control plane is low-cost, total cost is driven by:

Compute cost for WebLogic hosts – Shapes, OCPU count, memory, boot volume size – HA designs (more nodes) increase cost
Logging cost – Ingestion volume (GB/day) is often the biggest variable – Retention duration – Routing to external systems or archiving
Monitoring cost – Number of metrics/time-series – Resolution and retention (depends on OCI Monitoring pricing model—verify)
Network egress – Data leaving OCI to external systems (SIEM, ticketing) may incur egress charges – Cross-region traffic can be a cost driver
Operational overhead – People cost for managing alert noise, tuning thresholds, and maintaining agents

Free tier considerations

OCI has an Always Free tier for certain compute shapes and services, but: – WebLogic domains often require resources beyond micro instances. – WebLogic licensing is not automatically “free” (unless you use a license-included marketplace image, which is usage-charged).
Verify Always Free eligibility and marketplace licensing carefully.

Hidden/indirect costs

Log verbosity during incidents can spike ingestion cost.
High-cardinality dimensions in metrics can create many time-series.
Multiple environments (dev/test/prod) multiplied telemetry.

Cost optimization strategies

Collect only the logs you need (start with error logs, not full debug).
Use environment-based telemetry policies (lighter in dev).
Set retention based on compliance and incident patterns (shorter hot retention; archive to Object Storage if appropriate).
Tag resources to enable chargeback (domain/app/env/cost-center).
Tune alarms to reduce alert storms (hysteresis, sustain duration, severity routing).

Example low-cost starter estimate (conceptual)

A small non-production setup might include: – 1 small compute VM running a simple WebLogic domain – Management Agent sending a modest set of metrics – Minimal log ingestion (only server log at INFO level, short retention)

Costs will primarily be compute + any logging ingestion. Use the OCI Cost Estimator and compare: – “no logs” vs “logs enabled” – short vs long retention

Example production cost considerations

A production multi-domain HA setup might include: – Multiple nodes per domain (admin + managed servers) – Load balancers – High log volumes – Longer retention and SIEM export – Multiple regions (DR)

In production, the biggest levers are: – telemetry volume – node count – retention policies – cross-region and external data transfer

10. Step-by-Step Hands-On Tutorial

Objective

Connect an existing WebLogic host to Oracle Cloud WebLogic Management using the OCI Management Agent, discover the domain, and validate that you can see domain topology and basic operational signals in the OCI Console—then clean up safely.

Lab Overview

You will:

Prepare an OCI compartment and IAM access (minimum required).
Create an agent installation key (or equivalent registration method).
Install the Management Agent on a WebLogic host.
Enable WebLogic discovery/collection as documented for WebLogic Management.
Validate discovery in the WebLogic Management console.
(Optional) Set up a simple alarm/notification workflow if metrics are available.
Clean up agent/keys and (optionally) the lab compute host.

This lab assumes you already have a WebLogic domain running on a Linux host you can SSH into. If you do not, deploy WebLogic using your organization’s standard approach or Oracle Marketplace (“WebLogic Server for OCI”). Licensing and costs vary—verify before deploying.

Step 1: Create a compartment for the lab

Goal: Isolate lab resources for clean governance and cleanup.

In the OCI Console, open Identity & Security → Compartments.
Click Create Compartment.
Name it, for example: wls-mgmt-lab
(Optional) Add tags like: – env=lab – owner=<yourname>
Create the compartment.

Expected outcome: A dedicated compartment exists for WebLogic Management lab resources.

Verification: – Confirm the compartment appears in the compartment list and you can select it in the console.

Step 2: Ensure you have the required IAM permissions

Goal: Make sure you can manage agents and view WebLogic Management resources.

OCI IAM policies are specific. Rather than guessing exact statements, do this:

Identify your OCI group (or create one) for the lab, e.g., WLSMgmtLabAdmins.
In Identity & Security → Policies, create or update a policy in the root compartment (or appropriate parent) to allow: – managing/reading Management Agents – using WebLogic Management features in the wls-mgmt-lab compartment – interacting with Monitoring/Logging if you will enable those

Use the official documentation to build the correct policy statements: – WebLogic Management docs: https://docs.oracle.com/en-us/iaas/wls-management/home.htm
– IAM policy reference: https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/iampolicyreference.htm

Expected outcome: Your user can access WebLogic Management pages and agent management pages without authorization errors.

Verification: – Navigate to WebLogic Management in the OCI Console (menu path varies by console updates; typically under Observability & Management). – If you can open the service without permission errors, IAM is likely sufficient.

Common error: – NotAuthorizedOrNotFound when opening service pages. – Fix: confirm correct compartment selection and policy scope; allow required verbs for the agent and WebLogic Management resource types per docs.

Step 3: Create a Management Agent installation key (or registration token)

Goal: Obtain the official, tenancy-bound registration method.

In OCI Console, go to the Management Agent area (commonly under Observability & Management).
Find Install Keys (or similarly named registration key feature).
Create a new key: – Name: wls-mgmt-lab-key – Compartment: wls-mgmt-lab – Expiration: choose a short window for security (for example, 24–72 hours) if supported.
Download the installation package/instructions shown by OCI.

Expected outcome: You have an OCI-provided install key and official install command/package.

Verification: – The key is listed as Active (until expiry). – OCI provides an install script/command for Linux targets.

Do not reuse long-lived keys in production. Prefer short-lived keys and controlled distribution.

Step 4: Prepare the WebLogic host (network + OS access)

Goal: Ensure agent installation and outbound connectivity will work.

On the host running WebLogic:

SSH to the host.
Ensure you have sudo privileges.
Confirm outbound connectivity to OCI endpoints (high-level check): – If you use NAT/proxy, confirm it allows outbound HTTPS (443).

Basic Linux checks:

# Check OS and kernel
uname -a
cat /etc/os-release

# Confirm you can resolve DNS
getent hosts oracle.com || nslookup oracle.com

# Confirm outbound HTTPS works (simple check)
curl -I https://www.oracle.com/ 2>/dev/null | head

Expected outcome: Host can resolve DNS and make outbound HTTPS connections.

Verification: – curl -I returns HTTP headers (200/301/302 are fine).

Common errors: – DNS fails in private subnet: – Fix: check VCN DNS resolver settings and security rules. – HTTPS blocked: – Fix: configure NAT Gateway/service gateway/proxy as required.

Step 5: Install the OCI Management Agent on the WebLogic host

Goal: Install the agent using OCI’s official command/package for your install key.

Because Oracle may update agent installers and commands, do not use hardcoded commands from blogs. Use the exact command provided by OCI Console for your install key.

Typical flow is:

Copy the downloaded agent installer bundle to the host (SCP).
Run the installer command shown in the OCI Console.
Confirm the agent is running.

Example (structure only — replace with your official command):

# Example structure only. Use the exact command from OCI Console.
chmod +x ./agent_install.sh
sudo ./agent_install.sh

Then check agent status (command name may differ by version—verify in docs/host):

# Common patterns (verify actual paths/commands)
sudo systemctl status mgmt_agent || true
ps -ef | grep -i mgmt_agent | grep -v grep || true

Expected outcome: The agent is installed and running on the WebLogic host.

Verification (console): – In OCI Console → Management Agents, you should see the host appear as a registered agent (often within a few minutes). – Agent status should be “Active/Healthy” (exact wording varies).

Common errors: – Agent registers but shows inactive: – Fix: check host time sync (NTP), outbound connectivity, and local firewall rules. – Installation fails due to missing dependencies: – Fix: install required OS packages as per agent prerequisites in official docs.

Step 6: Enable WebLogic Management collection/discovery

Goal: Configure the agent and WebLogic Management to discover your domain.

The exact method varies by product version and supported configurations. Follow the official WebLogic Management workflow for:

Enabling WebLogic discovery on the agent host
Pointing the collector to the WebLogic domain / Admin Server
Providing required credentials securely (avoid plaintext; prefer OCI Vault or secure local methods where supported)

Start here: – WebLogic Management docs: https://docs.oracle.com/en-us/iaas/wls-management/home.htm

Common high-level steps you may see in Oracle’s workflow: 1. Select the registered Management Agent in OCI. 2. Deploy/enable the WebLogic Management plugin or collector (if applicable). 3. Provide connection details to the WebLogic domain (Admin Server URL, domain home, etc.) as required. 4. Run discovery. 5. Wait for inventory/topology to populate.

Expected outcome: A WebLogic domain appears in WebLogic Management, associated with the host/agent.

Verification: – In OCI Console → WebLogic Management: – Domain is listed. – Topology view shows clusters/managed servers (depending on your domain). – Basic health indicators/telemetry (as supported) are visible.

Common errors: – Discovery fails with authentication errors: – Fix: verify admin credentials, SSL settings, and the admin endpoint reachability from the agent host. – Discovery finds host but not domain: – Fix: confirm the domain is running and supported; verify required ports and local permissions.

Step 7 (Optional): Configure a basic alert workflow

Goal: Turn visibility into actionable operations.

If WebLogic Management exposes metrics through OCI Monitoring in your setup:

Go to Observability & Management → Monitoring → Alarms.
Create an alarm scoped to your compartment and relevant metric namespace.
Create a Notifications topic and subscription (email or HTTPS endpoint).
Link the alarm to the topic.

Expected outcome: You receive an email/HTTP notification when the alarm triggers.

Verification: – Use a safe test threshold (or temporarily lower threshold) to trigger. – Confirm notification delivery.

If you cannot find WebLogic-specific metrics in Monitoring, don’t force it—feature availability can vary. Validate what telemetry is exposed in your current region and configuration.

Validation

Use this checklist to confirm success:

[ ] Management Agent is registered and “Active” in OCI Console.
[ ] WebLogic domain appears in WebLogic Management.
[ ] Topology view matches expected domain structure.
[ ] (Optional) Metrics/logs are visible in Monitoring/Logging as configured.
[ ] IAM policies restrict access appropriately (test with a non-admin user if possible).

Troubleshooting

Issue: Agent not appearing in console – Confirm install key not expired. – Confirm outbound HTTPS from host. – Confirm correct region selected in OCI Console. – Check local logs for the agent (location varies; verify in docs).

Issue: Discovery fails – Confirm WebLogic Admin Server is reachable from the agent host. – Verify admin credentials and SSL requirements. – Ensure WebLogic version/configuration is supported—verify in docs.

Issue: No metrics/logs – Confirm the collector/plugin is enabled (if applicable). – Confirm Monitoring/Logging configuration is enabled for your target. – Confirm IAM policies allow writing telemetry to required services.

Issue: Permission errors in console – Check compartment selection (most common issue). – Re-evaluate IAM policy scope and group membership.

Cleanup

To avoid ongoing costs and reduce security risk:

Remove/disconnect the Management Agent – Stop the service on the host (systemctl) and uninstall if required. – Remove any local credentials/config created for discovery.
Delete/expire install keys – In OCI Console → Management Agent → Install Keys:
- Delete the key or let it expire.
Delete alarms and notification topics – Remove lab alarms. – Delete notification subscriptions/topics created for the lab.
Delete lab resources – If you created compute instances for the lab, terminate them. – Delete the wls-mgmt-lab compartment when fully empty.

11. Best Practices

Architecture best practices

Design for compartments first: align compartments to environments and ownership (prod, nonprod, per app team).
Standardize target naming: ensure domains/hosts have consistent names and tags so topology is searchable.
Hybrid planning: if monitoring on-prem, plan outbound connectivity, proxies, and certificate strategy upfront.

IAM/security best practices

Least privilege: separate roles:
View-only (read dashboards/topology)
Operations (manage alarms, manage discovery)
Admin (manage agents, policies)
No shared accounts: use OCI groups and audited user identities.
Short-lived install keys: rotate and restrict distribution.

Cost best practices

Start with minimal log ingestion; expand only when required.
Use routing and retention policies to manage storage cost.
Avoid collecting high-volume debug logs by default.
Tag everything for cost allocation:
app, env, cost-center, owner, domain

Performance best practices

Keep WebLogic hosts sized for application needs; observability should not starve the JVM.
Prefer dedicated admin channels and secure admin endpoints (WebLogic best practice) and ensure collectors use appropriate endpoints.

Reliability best practices

Use multiple managed servers/clusters for HA where required—observability should reflect the design.
Build runbooks that link from an alarm to a topology view and known remediation steps.

Operations best practices

Tune alarms: use sustain periods, severity mapping, and maintenance windows to reduce false positives.
Document ownership: every domain should have an on-call group and escalation.
Treat observability config as code where possible (Terraform/CLI) for repeatability—verify service support for IaC in your environment.

Governance/tagging/naming best practices

Enforce tag namespaces for production.
Use consistent compartment patterns:
Shared-Observability
App-Prod
App-NonProd
Review IAM policies quarterly; remove stale access.

12. Security Considerations

Identity and access model

OCI IAM controls access to WebLogic Management and related telemetry services.
Use separate groups for:
read-only observers
operators
administrators

Encryption

OCI services generally encrypt data at rest using Oracle-managed keys; for customer-managed keys, use OCI Vault where supported by the dependent service (for example, Logging/Storage).
Verify encryption/key options per service in official docs.

Network exposure

Management Agent typically needs outbound connectivity; avoid inbound openings for observability wherever possible.
Keep WebLogic Admin endpoints private (VCN private subnets) and use OCI Bastion for controlled admin access.

Secrets handling

Avoid putting WebLogic admin credentials in plaintext files/scripts.
Prefer:
OCI Vault (where integration is supported), or
OS-level protected secrets with strict file permissions and rotation policies (if required by the collector)

Audit/logging

Enable and review OCI Audit for:
policy changes
agent key creation/deletion
observability configuration changes
Centralize logs with strict access controls.

Compliance considerations

Treat telemetry as sensitive:
logs can contain PII, tokens, internal URLs
topology reveals architecture details
Apply retention policies aligned with regulatory requirements.

Common security mistakes

Leaving install keys active indefinitely.
Granting broad tenancy-wide permissions instead of compartment-scoped policies.
Exporting logs to external endpoints without encryption or egress controls.
Allowing overly broad access to production telemetry.

Secure deployment recommendations

Use private networking and controlled egress (NAT + allowlists).
Rotate keys and credentials.
Implement least privilege access with periodic reviews.
Redact sensitive application logs where possible before ingestion.

13. Limitations and Gotchas

Because capabilities and supported configurations can change, confirm specifics in official docs. Common gotchas include:

Supported WebLogic versions/configs: not every domain layout or version may be supported. Always confirm compatibility.
Regional availability: WebLogic Management may not be in every OCI region.
Telemetry gaps: you may see topology but limited metrics/logs unless additional configuration is enabled.
High log cost: log ingestion and retention can become expensive quickly.
IAM complexity: mis-scoped compartment policies are a frequent source of “not authorized” errors.
Network constraints: private subnet hosts need outbound paths (NAT/service gateway/proxy).
Certificate/SSL issues: if discovery requires SSL connections to Admin Server, mismatched certs or strict TLS policies can block collection.
Multi-domain hosts: mapping telemetry cleanly to the correct domain requires consistent configuration and tagging.
Change management: domain renames and rebuilds can cause duplicate or stale inventory entries; plan cleanup processes.

14. Comparison with Alternatives

WebLogic Management is part of a broader toolbox. Here’s how it compares to common alternatives.

Option	Best For	Strengths	Weaknesses	When to Choose
OCI WebLogic Management	OCI-native visibility for WebLogic domains	Topology-aware view; integrates with OCI Monitoring/Logging/IAM	Feature scope depends on supported configs; may not replace deep APM	You run WebLogic and want OCI-native operations and governance
OCI Monitoring + Logging (generic)	Broad infra observability	Works for any workload; strong alarm routing and log pipelines	Not WebLogic-topology aware by default	You want foundational observability and will build WebLogic dashboards manually
OCI APM (Application Performance Monitoring)	Code-level tracing and app performance	Distributed tracing, service maps, transaction views (where instrumented)	Requires instrumentation; not a domain inventory tool	You need deep application performance insights in addition to platform monitoring
Oracle Enterprise Manager (self-managed)	Enterprise-wide Oracle middleware management	Mature middleware management; deep Oracle stack integration	Requires infrastructure and admin; not OCI-native SaaS by default	You already standardize on OEM and need deep control across hybrid estates
Prometheus + Grafana (self-managed/managed)	Open metrics ecosystem	Flexible, extensible, strong dashboards	You must integrate WebLogic metrics/exporters yourself	You want open tooling and have SRE maturity to manage it
Elastic / OpenSearch logging stacks	Centralized log search and analytics	Powerful log search and dashboards	Can be costly/complex; requires ingestion pipelines	You already run a logging platform and need to integrate WebLogic logs there
Third-party APM (Dynatrace, New Relic, etc.)	Full-stack observability across heterogeneous apps	Mature agents, strong analytics	Licensing costs; integration complexity	You need cross-cloud, cross-platform standardization

15. Real-World Example

Enterprise example (regulated, multi-team)

Problem: A financial services organization runs dozens of WebLogic domains across dev/test/prod. Troubleshooting requires SSH access to hosts, and production telemetry access is inconsistently controlled.

Proposed architecture: – WebLogic domains run on OCI Compute in private subnets. – Management Agents installed on each WebLogic host. – WebLogic Management used for inventory/topology. – OCI Monitoring alarms integrated with OCI Notifications to route to the on-call system. – OCI Logging used for centralized log retention; logs routed to a SOC SIEM. – Compartments separate prod/non-prod, with strict IAM policies.

Why WebLogic Management was chosen: – WebLogic-specific topology visibility reduces triage time. – OCI IAM and compartments provide environment isolation and auditability. – Integrates naturally with OCI Monitoring/Logging.

Expected outcomes: – Reduced MTTR for cluster/server incidents. – Lower SSH access footprint and improved governance. – Better audit evidence for monitoring and operational controls.

Startup/small-team example (small ops team, legacy app)

Problem: A small team runs one critical WebLogic-based app but lacks dedicated middleware specialists. Failures are noticed only after user reports.

Proposed architecture: – One or two OCI compute instances (depending on HA needs). – Management Agent installed. – WebLogic Management for basic visibility. – A few targeted alarms (CPU saturation, critical WebLogic metric thresholds if available) routed to email and a webhook.

Why WebLogic Management was chosen: – Reduces need for specialized internal tooling. – Gives quick topology context without building everything from scratch.

Expected outcomes: – Faster awareness of incidents. – More predictable operations with minimal engineering overhead.

16. FAQ

1) Is WebLogic Management the same as the WebLogic Admin Console?

No. The WebLogic Admin Console is a WebLogic Server administration UI for configuring a domain. WebLogic Management (OCI) is an Oracle Cloud service for centralized discovery/observability across domains using OCI governance and integrations.

2) Do I need to run WebLogic on OCI to use WebLogic Management?

Not necessarily. Many OCI observability patterns support hybrid/on-prem targets via agents, but WebLogic Management support depends on current compatibility. Verify in official docs for supported on-prem/hybrid configurations.

3) Does WebLogic Management require installing an agent?

Typically yes. WebLogic Management usually relies on the OCI Management Agent on the host to collect/discover telemetry and domain information.

4) Does it collect application traces like APM?

WebLogic Management is primarily domain/topology/operations focused. For code-level tracing, use OCI APM (or another APM tool) in addition.

5) What WebLogic versions are supported?

Support varies. Always check the WebLogic Management documentation for the supported versions and domain types: https://docs.oracle.com/en-us/iaas/wls-management/home.htm

6) Is there a separate cost for WebLogic Management?

It depends on Oracle’s current pricing model. Even if the service itself is low-cost or included, you will pay for compute, and often for log ingestion/retention and other dependent services. Verify using: – https://www.oracle.com/cloud/price-list.html – https://www.oracle.com/cloud/costestimator.html

7) Can I use compartments to separate environments?

Yes. Compartments are a best practice to separate prod/non-prod and enforce different IAM policies.

8) Can WebLogic Management send alerts to my ticketing system?

Indirectly, yes—typically through OCI Monitoring alarms and OCI Notifications (email/HTTPS). The exact path depends on which metrics are available and your integration approach.

9) What networking is required for the Management Agent?

Generally outbound HTTPS connectivity to OCI endpoints in the region. In private subnets, you commonly use NAT Gateway, service gateway (if supported for the endpoint), or proxy. Verify exact endpoint requirements in agent documentation.

10) Is telemetry encrypted in transit?

OCI service endpoints use TLS for HTTPS. Ensure your host trusts required certificates and your TLS policies allow connectivity.

11) Can I limit who can view production WebLogic topology?

Yes, via OCI IAM policies scoped to the production compartment. Use least privilege and separate viewer/operator/admin roles.

12) How do I avoid excessive logging costs?

Start with minimal logs, reduce verbosity, set short retention for high-volume logs, and route/archive strategically. Monitor ingestion volume and adjust.

13) What happens if my install key expires?

Agents installed with a key typically remain registered, but you won’t be able to use that key to install new agents. The exact behavior can vary—verify in agent docs.

14) Can I monitor multiple domains on the same host?

Often yes, but configuration complexity increases. Use consistent naming/tagging and validate discovery behavior to prevent confusion.

15) Is WebLogic Management a replacement for Oracle Enterprise Manager?

Not necessarily. OEM is a mature enterprise management platform; WebLogic Management is OCI-native and may be lighter-weight and more cloud-governed. Many enterprises use both depending on needs.

17. Top Online Resources to Learn WebLogic Management

Resource Type	Name	Why It Is Useful
Official documentation	WebLogic Management documentation (OCI) — https://docs.oracle.com/en-us/iaas/wls-management/home.htm	Primary source for setup steps, supported versions, and workflows
Official documentation	OCI Observability & Management overview — https://docs.oracle.com/en-us/iaas/Content/monitoring/home.htm (Monitoring) and https://docs.oracle.com/en-us/iaas/Content/Logging/home.htm (Logging)	Understand the underlying services commonly used with WebLogic Management
Official documentation	OCI IAM overview — https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm	Required for designing least-privilege access to observability data
Official pricing	Oracle Cloud Price List — https://www.oracle.com/cloud/price-list.html	Verify current pricing for dependent services (compute/logging/monitoring)
Official calculator	OCI Cost Estimator — https://www.oracle.com/cloud/costestimator.html	Build a region-specific cost estimate without guessing
Official tutorials/labs	Oracle Cloud tutorials (catalog) — https://docs.oracle.com/en/learn/	Find current OCI labs; search within for WebLogic/observability
Official architecture	OCI Architecture Center — https://docs.oracle.com/en/solutions/	Reference architectures for OCI networking, governance, and operations patterns
Official CLI	OCI CLI install docs — https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm	Helpful for scripting alarm/logging/IAM setup around observability
Community (reputable)	Oracle blogs (WebLogic/OCI categories) — https://blogs.oracle.com/	Often contains practical operational patterns; validate against docs
Community (reputable)	Oracle Cloud Infrastructure YouTube — https://www.youtube.com/@OracleCloudInfrastructure	Webinars and demos; verify steps with latest docs

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	OCI DevOps/operations practices, observability foundations, automation	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	DevOps fundamentals, tooling, CI/CD and operations concepts	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud ops practitioners	Cloud operations, monitoring/management patterns, practical labs	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability engineers, platform engineers	SRE practices, alerting, incident response, reliability engineering	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams adopting AIOps	AIOps concepts, event correlation, operational analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/Cloud training and mentoring (verify exact offerings)	Individuals and teams seeking practical coaching	https://rajeshkumar.xyz/
devopstrainer.in	DevOps tooling and implementation training (verify exact offerings)	Beginners to intermediate DevOps practitioners	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps help/training platform (verify exact offerings)	Teams needing short-term support or coaching	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and guidance platform (verify exact offerings)	Ops teams needing troubleshooting support and knowledge transfer	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact catalog)	Architecture, migrations, CI/CD, operations enablement	Designing OCI landing zone; setting up observability pipelines; runbook creation	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	DevOps transformation, tooling implementation, operations practices	Implement monitoring strategy; standardize alerting; platform enablement workshops	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services (verify exact catalog)	DevOps process/tooling, automation, operations improvement	Build CI/CD; implement logging/monitoring; incident response process improvement	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before WebLogic Management

OCI foundations: compartments, VCNs, subnets, routing, NAT/service gateways
OCI IAM: users, groups, policies, dynamic groups (where applicable)
Observability basics: metrics vs logs vs traces; alerting design
WebLogic fundamentals:
domain structure (Admin Server, Managed Servers, clusters)
logs and JVM basics (heap, GC, thread behavior)

What to learn after WebLogic Management

OCI Monitoring deep dive: alarms, notification routing, incident management
OCI Logging and Logging Analytics (if used): parsing, search, dashboards
OCI APM for application-level observability
Infrastructure as Code (Terraform) for repeatable ops configuration (verify supported resource types for WebLogic Management)
Incident response and SRE practices: SLOs, error budgets, alert tuning

Job roles that use it

Cloud engineer (OCI)
DevOps engineer
Site Reliability Engineer (SRE)
Middleware administrator transitioning to cloud ops
Platform engineer operating enterprise Java platforms
Security engineer supporting monitoring governance

Certification path (if available)

Oracle certifications change frequently. A practical path is: – OCI Foundations (entry-level) – OCI Architect / Operations certifications (as applicable) – WebLogic administration skills (Oracle training tracks)

Verify current Oracle certification tracks on Oracle University: – https://education.oracle.com/

Project ideas for practice

Build a compartment strategy for multi-env WebLogic estates.
Implement agent-based telemetry for dev and prod with different retention policies.
Create alarm-to-notification workflows with severity routing.
Build a runbook that maps common WebLogic incidents to topology/telemetry evidence.
Set up log redaction and secure retention aligned with compliance.

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud’s IaaS/PaaS platform.
Observability: The ability to understand system behavior from outputs (metrics, logs, traces).
WebLogic Server: Oracle’s Java application server for enterprise workloads.
Domain: The primary administrative unit in WebLogic, containing servers, clusters, and resources.
Admin Server: Central management server for a WebLogic domain.
Managed Server: A server instance in a domain that runs applications and resources.
Cluster: A group of managed servers that work together for scalability and high availability.
Compartment (OCI): A logical container for organizing and isolating OCI resources and IAM policies.
IAM Policy (OCI): A statement that defines who can do what on which resources in OCI.
Management Agent: An OCI agent installed on hosts to collect telemetry and integrate targets with OCI management services.
Metrics: Numeric time-series measurements (CPU, memory, JVM stats, request counts, etc.).
Logs: Textual/event records emitted by applications and systems.
Alarm: A rule that evaluates a metric and triggers notifications when conditions are met.
Notification Topic: A channel in OCI Notifications used to deliver messages to subscribers.
Retention: How long telemetry data (logs/metrics) is kept before deletion/archival.
Least Privilege: Security principle of granting only the minimum permissions required.

23. Summary

WebLogic Management in Oracle Cloud (within Observability and Management) is a practical way to centralize visibility into WebLogic Server domains—especially when you need topology-aware views, consistent governance through compartments, and integration with OCI monitoring and logging workflows.

It matters because WebLogic estates are often business-critical and operationally complex. WebLogic Management helps reduce MTTR, standardize operational practices, and improve auditability through OCI IAM and OCI Audit.

From a cost perspective, focus less on the control plane and more on the real drivers: compute, log ingestion/retention, and any external data transfer. From a security perspective, prioritize least privilege IAM, short-lived agent install keys, and safe handling of credentials and logs.

Use WebLogic Management when you run WebLogic and want OCI-native operational visibility; complement it with OCI Monitoring/Logging and OCI APM when you need deeper telemetry and application tracing.

Next step: Follow the official WebLogic Management documentation to confirm supported versions and complete the agent-based discovery workflow for your environment: https://docs.oracle.com/en-us/iaas/wls-management/home.htm

rajeshkumar

Category