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

1. Introduction

Fleet Application Management is an Oracle Cloud (OCI) service in the Observability and Management category that helps you discover, organize, and manage applications as a fleet—instead of treating every host as a one-off snowflake.

In simple terms: you connect your servers, let OCI identify supported application installations and deployments, group them into a “fleet,” and then use one place to view inventory and perform management tasks (depending on what application types and actions are supported in your tenancy/region).

Technically, Fleet Application Management relies on OCI’s management instrumentation (commonly the OCI Management Agent, depending on your environment and the application types you manage) to collect application signals and inventory. It then models this information as OCI resources (fleets, managed entities, application instances/deployments) and applies standard OCI governance: compartments, IAM policies, tags, audit logs, and (where applicable) integrations with Logging/Monitoring/Notifications.

The problem it solves is operational sprawl: as the number of environments, hosts, and application instances grows, teams struggle with: – consistent application inventory, – visibility of “what’s running where,” – safe, repeatable operations across many instances, – governance and access control at scale.

Service status note: At the time of writing, Oracle’s product documentation lists the service as Fleet Application Management. If you encounter older blog posts or internal references using abbreviations (for example, “FAM”), confirm terminology and current capabilities in the official documentation for your region/tenancy.

2. What is Fleet Application Management?

Official purpose (high level)
Fleet Application Management is designed to provide a centralized way to manage applications across a fleet of hosts/environments in Oracle Cloud. The service focuses on fleet-level visibility and operations rather than host-by-host manual work.

Core capabilities (conceptual)
While exact capabilities can vary by supported application type and region, the typical scope of Fleet Application Management includes: – Application discovery / inventory for supported application types installed on connected hosts – Fleet grouping to represent sets of applications that should be managed together (by environment, business unit, lifecycle stage, compliance boundary, etc.) – Centralized views of application deployments/instances and their metadata – Governed operations using OCI compartments, IAM, tags, and audit logs

Major components (how to think about it in OCI terms) – Fleet: The primary resource you create to group and manage applications at scale. – Managed hosts / managed entities: Compute instances or external hosts that are connected to OCI for discovery/management. – Discovery/collection mechanism: Typically the OCI Management Agent (exact mechanism depends on the workload; verify in official docs for your app type). – OCI governance controls: Compartments, IAM policies, tags, audit logs, and (optionally) events/notifications.

Service type
A managed OCI control-plane service for application fleet operations (inventory and management workflows), integrated with standard OCI identity and governance.

Scope (regional/global/account-scoped)
Fleet Application Management is an OCI service that you use within a tenancy and typically within a region, with resources organized by compartments.
Because OCI services differ in how they store and present data regionally, verify the regional behavior and cross-region visibility in the official docs for your tenancy and the specific features you plan to use.

How it fits into the Oracle Cloud ecosystem Fleet Application Management is part of the broader Observability and Management toolset and commonly complements: – Monitoring and Alarms (service health metrics and alerting) – Logging (operational logs for troubleshooting) – Notifications (routing alerts/events) – Events (automation triggers) – OS Management Hub / patching services (host-level patching/compliance) – Resource Manager (Terraform) (infrastructure provisioning) – Vault (secrets and key management)

Official documentation entry point (start here):
– Fleet Application Management docs: https://docs.oracle.com/en-us/iaas/fleet-application-management/home.htm (verify URL if it redirects in your region)

3. Why use Fleet Application Management?

Business reasons

Reduce operational cost by managing groups of application instances with consistent processes.
Increase auditability: centralized inventory and controlled operations make it easier to answer “what’s deployed where” for audits and risk reviews.
Support environment growth: as teams scale to dozens/hundreds of servers, manual tracking breaks down.

Technical reasons

Inventory and discovery: identify application installations/deployments across many hosts in a consistent way (for supported app types).
Standardize fleet constructs: represent your architecture in a manageable model (fleets by environment or product line).
Integrate with OCI governance: use compartments and IAM rather than building your own RBAC database.

Operational reasons

Faster troubleshooting: faster identification of impacted application instances and where they run.
Repeatable workflows: less “tribal knowledge” required to manage widely distributed application estates.
Better change planning: centralized view helps plan updates and coordinate changes.

Security/compliance reasons

Least privilege access via IAM policies.
Improved accountability via OCI audit logs (who created fleets, changed configurations, initiated actions).
Stronger separation of duties using compartments and policies aligned to org structure.

Scalability/performance reasons

Fleet-first model scales better than per-host manual operations.
Central control plane reduces the need for custom tooling to aggregate inventory and metadata.

When teams should choose it

Choose Fleet Application Management when: – you have many application instances (or expect to), – you need a central inventory across environments, – you want OCI-governed operations on applications (not just hosts), – your app stack matches the supported discovery/management scope for the service (verify in docs).

When teams should not choose it

It may not be a fit when: – you only have a handful of hosts and can manage manually, – you primarily need deep application performance tracing (consider OCI APM instead), – your applications are fully managed PaaS/SaaS with no host-level footprint to discover, – you need management for an application type not supported by Fleet Application Management (verify supported types in docs).

4. Where is Fleet Application Management used?

Industries

Financial services (regulated environments needing inventory/auditability)
Healthcare (compliance and environment segmentation)
Retail/e-commerce (multiple environments, rapid change)
Manufacturing (mixed on-prem + cloud footprints)
Government/public sector (strict governance, compartmentalization)

Team types

Platform engineering teams building internal platforms on OCI
DevOps/SRE teams responsible for uptime and change management
Operations teams migrating from legacy CMDB/manual inventory
Security engineering teams supporting compliance reporting
Application operations teams managing packaged middleware stacks

Workloads

Traditional VM-based applications
Hybrid estates (OCI + on-prem) where supported by the agent and connectivity model
Enterprise application stacks where version visibility and change control matter

Architectures

Multi-compartment enterprise landing zones
Hub-and-spoke networking with centralized governance
Blue/green and multi-environment (dev/test/stage/prod) footprints

Real-world deployment contexts

Central IT managing fleets for multiple business units
Product teams that own an application but share base infrastructure
MSPs managing multiple customer compartments/tenancies (where allowed)

Production vs dev/test usage

Production: most valuable for inventory, governance, and repeatable operational workflows.
Dev/test: useful to standardize how app deployments are cataloged and managed; also helps validate discovery and access models before production rollout.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Fleet Application Management is commonly useful. Exact capabilities depend on supported application types and your setup—verify the service’s supported discovery and actions in official docs.

1) Fleet-wide application inventory for audits

Problem: Audit asks for a list of application instances, versions, and where they run.
Why this fits: Fleet model centralizes inventory across many hosts.
Example: Security team needs quarterly evidence that only approved application versions are running in the Prod compartment.

2) Environment segmentation (dev/test/prod) with separate access

Problem: Too many people have production visibility or control.
Why this fits: OCI compartments + fleet resources let you segment visibility/management.
Example: Create Payments-Prod-Fleet in the Prod compartment; grant only SREs manage access.

3) Operational readiness during migrations to OCI

Problem: During lift-and-shift, teams lose track of what moved and what’s still on-prem.
Why this fits: Discovery and centralized inventory help track migration progress.
Example: A migration factory uses Fleet Application Management to confirm all expected app instances appear in OCI.

4) Post-incident blast radius analysis

Problem: A host failure occurs; teams need to know which application instances were affected.
Why this fits: Fleet/grouping and inventory views reduce time-to-identify.
Example: A compute node reboot causes outage; operations check the fleet to identify impacted deployments.

5) Standardized tagging and ownership tracking

Problem: No consistent “owner” metadata for applications across environments.
Why this fits: OCI tags (defined/freeform) applied to fleets can enforce ownership.
Example: Enforce tags like CostCenter, AppOwner, DataClassification on fleets.

6) Operational handoffs between teams

Problem: Dev teams deploy, ops teams run—but asset inventory is incomplete.
Why this fits: Fleet provides a shared operational object and consistent visibility.
Example: New service onboarding requires adding deployments to a fleet before production go-live.

7) Multi-region operational visibility (where supported)

Problem: Teams run active-active stacks in multiple regions and need consistent inventory.
Why this fits: Fleet constructs and compartments can align operational ownership; verify multi-region behavior in docs.
Example: Regional SREs manage their own fleets; central team reviews standardized reports.

8) Compliance boundary enforcement by compartment and fleet

Problem: A regulated application must be strictly isolated and monitored.
Why this fits: Use dedicated compartment + fleet + IAM policies.
Example: HIPAA workload uses a dedicated compartment and fleet with restricted operators.

9) Change planning across many app instances

Problem: A planned change affects many instances; you need to identify scope.
Why this fits: Fleet-level inventory supports safer planning.
Example: A library update requires identifying which instances depend on a specific runtime.

10) Building a lightweight CMDB substitute for app estates

Problem: CMDB data is stale; manual spreadsheets are inaccurate.
Why this fits: Automated discovery and centralized inventory reduce drift.
Example: Replace “app server spreadsheet” with fleet inventory views and tag-driven reporting.

6. Core Features

Because Oracle Cloud services evolve, treat this section as a practical guide and confirm exact feature availability (supported application types, actions, and regions) in the official Fleet Application Management documentation.

Fleet resource model (fleet-based organization)

What it does: Lets you define a “fleet” as a logical grouping for application management.
Why it matters: You manage by group, not by host.
Practical benefit: Cleaner operations for multi-environment deployments; faster scoping for incidents and changes.
Limitations/caveats: Fleet design is only as good as your compartment/tagging strategy.

Application discovery and inventory (for supported app types)

What it does: Collects metadata about application installations/deployments from managed hosts.
Why it matters: You can’t manage what you can’t reliably inventory.
Practical benefit: Central view of “what is running where” without manual tracking.
Limitations/caveats: Discovery depends on supported application types and correct agent connectivity/permissions.

Managed host onboarding (agent-based connectivity)

What it does: Connects OCI compute instances (and potentially external hosts, depending on supported modes) to OCI so they can be inventoried/managed.
Why it matters: Fleet Application Management needs a trusted way to communicate with hosts.
Practical benefit: Standard onboarding and credentialing; reduced bespoke scripts.
Limitations/caveats: Requires network egress to OCI endpoints and correct OS prerequisites.

Compartment and IAM integration

What it does: Uses OCI IAM policies to control who can view/manage fleets and related resources.
Why it matters: Governance is essential for production operations.
Practical benefit: Least privilege; separation of duties; consistent enterprise controls.
Limitations/caveats: Mis-scoped policies can lead to over-permissioning or blocked operations.

Tagging support (cost/governance metadata)

What it does: Supports applying OCI tags to fleets/resources (where available).
Why it matters: Tagging drives cost allocation, ownership, and automation.
Practical benefit: Better reporting; easier ops automation via tag-based queries.
Limitations/caveats: Tag compliance requires organizational discipline; consider tag defaults and tag namespaces.

Auditability (OCI Audit)

What it does: Records control-plane actions in OCI Audit.
Why it matters: You need a forensics trail of who changed what.
Practical benefit: Incident response, compliance evidence, and change accountability.
Limitations/caveats: Audit logs show control-plane operations; they don’t replace workload-level logging.

Integration patterns with monitoring and notifications (where applicable)

What it does: Enables operational workflows where fleet changes or detected events can be integrated into Monitoring/Events/Notifications.
Why it matters: Operations teams rely on alerting and ticket automation.
Practical benefit: Consistent “detect → notify → remediate” loops.
Limitations/caveats: Exact event types and metrics vary—verify in docs for your region.

7. Architecture and How It Works

High-level architecture

Fleet Application Management uses a control plane in OCI that stores fleet definitions and inventory metadata. Managed hosts run an agent/collector that: 1. securely registers with OCI, 2. collects application metadata from the host (for supported app types), 3. sends inventory/telemetry to the service endpoints.

OCI then provides: – UI and APIs to view and manage fleets – governance via compartments/IAM – audit logging of actions

Request/data/control flow (conceptual)

Operator creates a Fleet in an OCI compartment.
Operator onboards hosts by installing and registering an agent.
The agent performs discovery/collection and sends metadata to OCI.
Fleet Application Management correlates hosts and application entities into the fleet model.
Operators query inventory, review status, and perform supported management actions.

Integrations with related OCI services (common patterns)

IAM: fine-grained access control to fleet resources.
Audit: records control-plane changes and operations.
Monitoring/Alarms: alert on operational signals (verify which metrics are available for Fleet Application Management).
Logging: capture agent logs and service logs if configured (often via separate logging configuration).
Events + Notifications: automation hooks (verify event types for Fleet Application Management).
Vault: store secrets needed for operational tooling around fleets (not necessarily required by the service itself).

Dependency services

OCI Identity and Access Management (IAM)
Networking (VCN/subnet for compute instances; outbound egress to OCI endpoints)
Compute (if you manage app instances on VMs)
Management Agent (commonly used for host connectivity—verify exact agent requirements in docs)

Security/authentication model (conceptual)

Users authenticate via OCI IAM.
Agents authenticate using OCI-managed mechanisms established during agent registration (commonly via install keys/certificates; verify specifics in docs).
Authorization is enforced by IAM policies at the compartment/tenancy level.

Networking model

Managed hosts typically require outbound connectivity to OCI service endpoints.
If hosts are in private subnets, you commonly need a NAT Gateway or Service Gateway (depending on endpoint support) so the agent can reach OCI.
In locked-down environments, allowlisting OCI endpoints and controlling egress is critical.

Monitoring/logging/governance considerations

Treat fleets as first-class operational assets: enforce tags, naming standards, and access boundaries.
Capture agent logs centrally (for example, via OCI Logging) to speed up troubleshooting.
Use compartments to map to environments and compliance boundaries.

Simple architecture diagram (conceptual)

flowchart LR
  U[Operator / SRE] -->|Console / API| FAM[Fleet Application Management<br/>Control Plane]
  subgraph VCN[OCI VCN]
    H1[Compute Instance(s)<br/>App + Agent]
  end
  H1 -->|Inventory/Discovery Data| FAM
  FAM --> IAM[IAM Policies / Compartments]
  FAM --> AUD[Audit Logs]

Production-style architecture diagram (multi-environment)

flowchart TB
  subgraph Tenancy[OCI Tenancy]
    IAM[IAM<br/>Groups, Policies, Dynamic Groups]
    AUD[Audit]
    NOTIF[Notifications]
    EVT[Events]
    LOG[Logging]
    MON[Monitoring & Alarms]

    subgraph ProdComp[Compartment: Prod]
      FAMProd[Fleet Application Management<br/>Prod Fleet(s)]
      subgraph ProdVCN[Prod VCN]
        NAT1[NAT Gateway]
        P1[App Hosts (Private Subnet)<br/>Agent installed]
      end
    end

    subgraph DevComp[Compartment: Dev/Test]
      FAMDev[Fleet Application Management<br/>Dev Fleet(s)]
      subgraph DevVCN[Dev VCN]
        NAT2[NAT Gateway]
        D1[App Hosts (Private Subnet)<br/>Agent installed]
      end
    end
  end

  P1 -->|Egress via NAT| FAMProd
  D1 -->|Egress via NAT| FAMDev

  FAMProd --> AUD
  FAMDev --> AUD
  FAMProd --> EVT --> NOTIF
  FAMDev --> EVT --> NOTIF
  LOG --- P1
  MON --- FAMProd
  MON --- FAMDev

8. Prerequisites

Tenancy/account requirements

An active Oracle Cloud tenancy.
Access to an OCI compartment where you can create/manage:
Fleet Application Management resources
any required agent resources/keys (depending on onboarding method)
compute/network resources for the lab

Permissions / IAM roles

For a beginner lab, the simplest approach is: – Use a user/group with broad permissions in a dedicated lab compartment (for example, permissions equivalent to “manage all-resources” in that compartment).

For production, create least-privilege policies for: – fleet creation and management – host onboarding/agent management – read-only access for auditors

IAM policy syntax and service “resource family” names can change or be service-specific. Use the official IAM policy reference in the Fleet Application Management and Management Agent documentation and verify exact policy statements.

Billing requirements

Your tenancy must have billing enabled for paid resources used in the lab (primarily Compute, Block Volume, NAT Gateway, and data egress where applicable).
Fleet Application Management pricing may be separate or may have $0 control-plane cost depending on Oracle’s pricing model—verify on the official pricing page.

Tools needed

OCI Console access
SSH client (ssh) to connect to a compute instance
A terminal on your workstation
(Optional) OCI CLI if you prefer automation. Not required for this lab.

Region availability

Fleet Application Management availability can be region-dependent. Confirm in:
OCI Console service list for your region
Official docs region notes (if provided)

Quotas/limits

Compute instance limits (per shape, cores, VNICs)
VCN/NAT Gateway limits
Any Fleet Application Management service limits (verify in official docs)

Prerequisite services

OCI Compute: to host a sample application
OCI Networking: VCN, subnet, and egress path
OCI Management Agent (commonly): to connect the host for discovery/management

Management Agent docs entry point (verify URL if it redirects):
– https://docs.oracle.com/en-us/iaas/management-agent/home.htm

9. Pricing / Cost

Pricing model (what to check)

Oracle Cloud pricing for Observability and Management services can vary by: – region – service feature/SKU – data volume (GB ingested/stored), if applicable – number of managed entities/agents, depending on service

For Fleet Application Management specifically, do not assume it is free or paid without checking current pricing. Use: – OCI/Oracle Cloud price list: https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Navigate the price list to Observability and Management and locate Fleet Application Management (if listed) or any dependency SKUs that apply.

Common pricing dimensions (practical cost drivers)

Even if Fleet Application Management control plane is low-cost or $0, you still pay for dependencies:

Compute instances – OCPU and memory pricing for the hosts you manage – Boot volumes and block volumes
Network egress – Outbound data transfer from OCI to the internet or between regions – NAT Gateway processing (and data processing) where applicable
Logging/Monitoring storage – If you forward agent logs or store additional logs/metrics, you may incur ingestion and storage costs (depending on which logging/analytics services you enable).
Operations overhead – Extra compute overhead on hosts (agent CPU/memory) – Operational time to maintain least privilege and fleet governance

Free tier considerations

Oracle Cloud has an Always Free tier for some services, but eligibility and included limits vary. Verify Always Free coverage for: – compute shapes (if using Always Free eligible VM shapes) – monitoring/logging usage – any Fleet Application Management-specific free quota (if offered)

Always Free overview (verify current limits):
– https://www.oracle.com/cloud/free/

Hidden/indirect costs to watch

NAT Gateway: In private subnet designs, NAT Gateway can become a steady monthly cost driver.
Cross-region data movement: If you centralize logging or inventory across regions, data transfer can add up.
Log retention: Long retention periods cost money—set retention based on compliance needs.

How to optimize cost

Start with one small fleet and a minimal number of hosts.
Prefer private subnets with controlled egress; design egress intentionally.
Don’t enable expensive analytics features “just in case.”
Set log retention to the minimum that meets compliance.
Use tags for cost tracking: CostCenter, Environment, App, Owner.

Example low-cost starter estimate (qualitative)

A low-cost lab typically includes: – 1 small compute VM – 1 VCN + 1 subnet – (optional) NAT Gateway if you place the VM in a private subnet – minimal log retention

Exact numbers are region- and SKU-dependent, so use the OCI Cost Estimator to model: – VM shape cost – NAT Gateway + data processing – expected data egress and logging

Example production cost considerations

In production, cost typically scales with: – number of hosts – number of environments/regions – amount of operational telemetry you ingest/store – security posture (private endpoints, centralized logging, extended retention)

10. Step-by-Step Hands-On Tutorial

This lab focuses on a safe, minimal setup: one OCI compute instance, a management agent installed on it, and a Fleet Application Management fleet that can “see” the host and run discovery (where supported).

Because application discovery depends on supported application types, your “discovered applications” results may vary. The lab is still valid if you end with: – a registered managed host/agent visible in OCI, and – a fleet created and associated with that host.

Objective

Create a Fleet in Fleet Application Management
Provision a small OCI compute instance
Install and register the required agent (commonly OCI Management Agent)
Confirm the host appears in Fleet Application Management and that discovery/inventory runs (as supported)

Lab Overview

You will: 1. Create a compartment and basic network (or reuse existing). 2. Create a compute instance. 3. Ensure outbound connectivity from the instance to OCI endpoints. 4. Install and register the Management Agent (using the console-generated install workflow). 5. Create a Fleet and associate the managed host. 6. Validate visibility and inventory. 7. Clean up resources to avoid ongoing costs.

Step 1: Prepare a compartment (recommended)

Console path: Identity & Security → Compartments

Create a compartment like: – Name: lab-fam – Description: Fleet Application Management lab
Record the compartment OCID (optional).

Expected outcome – You have an isolated place to create and delete resources safely.

Verification – In the compartment list, you can select lab-fam and it shows as Active.

Step 2: Create networking (VCN + subnet)

If you already have a VCN/subnet you can use, reuse it. Otherwise:

Console path: Networking → Virtual Cloud Networks → Start VCN Wizard

Choose either: – Public subnet (simpler for labs; fewer moving parts), or – Private subnet + NAT Gateway (closer to production patterns).

Recommended lab-simple option: Public subnet
– Create VCN with Internet Gateway and a public subnet. – Ensure the subnet has a route rule to the Internet Gateway. – Ensure the instance will get a public IP.

Expected outcome – Instance will have outbound internet access (needed to reach OCI endpoints for agent registration and updates).

Verification – Subnet route table includes a default route (0.0.0.0/0) to the Internet Gateway. – Security list allows outbound traffic (default is usually permissive egress).

Step 3: Create a small compute instance

Console path: Compute → Instances → Create instance

Suggested lab settings: – Name: fam-lab-vm1 – Image: Oracle Linux (choose a current supported Oracle Linux image) – Shape: a small VM shape suitable for labs – Network: select your lab VCN and subnet – SSH keys: add your public key – Public IP: enabled (if using public subnet)

Expected outcome – Instance is running and you can SSH into it.

Verification – Instance lifecycle state is RUNNING. – Note the public IP address (or private IP if you use bastion).

SSH to the instance:

ssh -i ~/.ssh/id_rsa opc@<PUBLIC_IP>

If you used Oracle Linux and the default user differs, follow the “Instance access” details shown in the OCI console for the image you selected.

Step 4: Install a simple sample workload (optional but useful)

This step isn’t strictly required for fleet onboarding, but it helps ensure the host looks realistic.

On the instance:

sudo dnf -y update || sudo yum -y update

Install a lightweight web server (example):

sudo dnf -y install nginx || sudo yum -y install nginx
sudo systemctl enable --now nginx

Expected outcome – A running service you can later use to sanity-check the host.

Verification Check service status:

systemctl status nginx --no-pager

If your security list allows inbound TCP/80 and you have a public IP, you can test from your laptop:

curl -I http://<PUBLIC_IP>

Note: Fleet Application Management discovery may or may not treat nginx as a “discoverable application type.” This step is for host realism and connectivity checks, not as a guaranteed discoverable application.

Step 5: Create an agent install key and download the agent installer (console-driven)

Fleet Application Management commonly relies on the OCI Management Agent to connect hosts. The typical onboarding flow is: – create an agent install key in OCI, – download an installer or script, – run it on the host to register the agent.

Console path (typical): Observability & Management → Management Agent (or equivalent entry)
From there, look for: – Install keys – Download agent – Registration instructions

Because the exact navigation and UI labels can change, follow the current official steps here: – Management Agent documentation: https://docs.oracle.com/en-us/iaas/management-agent/home.htm

Expected outcome – You obtain an install script or package and an install key tied to your compartment.

Verification – In the console, you can see the install key exists and is Active (or usable). – You have downloaded the installer bundle or copied the install command.

Step 6: Install and register the Management Agent on the compute instance

Run the install command exactly as provided by the OCI console for your install key and OS.

Typical pattern (example only — do not copy blindly): – download installer – run as root with key/parameters – start agent service

Because Oracle may change the installer format, use the console-generated command.

After installation, check the agent service. One of these patterns is common:

sudo systemctl status oracle-cloud-agent --no-pager || true
sudo systemctl status managementagent --no-pager || true
sudo systemctl list-units --type=service | egrep -i "agent|oracle" || true

Expected outcome – The agent is installed and running. – The host registers back to OCI and appears in the Management Agent list.

Verification (console) – Go to the Management Agent list in your compartment. – Confirm the agent/host shows as Active (or similar healthy state). – Confirm last heartbeat time updates.

Common error – Agent shows “Inactive” or never appears. – Fix: confirm outbound egress (DNS + HTTPS), confirm system time is correct (NTP), confirm you used the right compartment/install key.

Step 7: Create a Fleet in Fleet Application Management

Console path: Observability & Management → Fleet Application Management → Fleets → Create fleet

Provide: – Name: lab-fleet-1 – Compartment: lab-fam – Tags: optional, but recommended (for example Environment=Lab)

Expected outcome – Fleet resource is created.

Verification – Fleet appears in the Fleets list with an Active lifecycle state.

Step 8: Add the managed host to the fleet (association/onboarding)

The UI typically provides a way to associate managed hosts/entities with a fleet.

Console path (conceptual): Fleet Application Management → your fleet → Managed hosts / Targets / Entities → Add

Select the compute instance/agent you registered.

Expected outcome – Fleet now contains at least one managed host/entity.

Verification – Fleet details show the host in its inventory list.

If you do not see the host as selectable: verify compartments (fleet and agent may need to be in accessible compartments) and verify IAM permissions.

Step 9: Run discovery / refresh inventory (if available)

Fleet Application Management may provide a discovery action, scheduled discovery, or refresh.

In the fleet UI, look for: – Discover applications – Refresh inventory – Run discovery job

Expected outcome – Inventory metadata is refreshed. – If supported application types are present, you may see discovered application instances/deployments.

Verification – The fleet shows updated timestamps. – Any discovered items appear in application inventory views.

If nothing is discovered, it may mean your installed workload isn’t a supported discoverable type. The lab is still successful if the host is managed and the fleet association works.

Validation

Use this checklist:

Compute instance is reachable – SSH works and basic commands run:

bash uname -a

Agent is healthy – System service running (name varies):

bash sudo systemctl --no-pager --full status managementagent || true sudo systemctl --no-pager --full status oracle-cloud-agent || true

Agent appears in OCI – Management Agent list shows the host as Active/Healthy.
Fleet exists and includes the host – Fleet details show the managed host/entity association.
Inventory refresh/discovery runs (if available) – Fleet inventory timestamps update and/or discovered entities appear.

Troubleshooting

Issue: Agent doesn’t show up in OCI

Check outbound connectivity:
DNS resolution works:

bash nslookup oracle.com || getent hosts oracle.com
HTTPS outbound works:

bash curl -I https://www.oracle.com
Check system time (TLS failures often occur with wrong clock):
On Oracle Linux:

bash timedatectl
Review agent logs
Log locations vary by agent and version. Use:

bash sudo journalctl -u managementagent --no-pager | tail -200 || true sudo journalctl -u oracle-cloud-agent --no-pager | tail -200 || true
If logs are elsewhere, consult the agent docs for your OS.

Issue: You can’t add the host to the fleet

Ensure:
The fleet and the host/agent are in the intended compartment(s).
Your user/group has permissions in both compartments.
For production, implement explicit IAM policies (verify in docs).

Issue: Discovery finds no applications

Confirm:
Your application type is supported by Fleet Application Management discovery in your region.
Required plugins/collectors are enabled (if the agent uses plugins).
If you need guaranteed “discoverable” behavior, use an application type explicitly documented as supported.

Cleanup

To avoid ongoing charges, delete in this order:

Terminate compute instance – Compute → Instances → fam-lab-vm1 → Terminate – Choose to delete attached boot volume (if you do not need it)
Delete NAT Gateway (if created) – Networking → NAT Gateways → delete
Delete VCN (if created for the lab) – Networking → VCNs → delete (wizard typically deletes dependent resources)
Delete fleet – Fleet Application Management → Fleets → delete lab-fleet-1
Delete agent install keys (optional hygiene) – Management Agent → Install keys → delete lab keys
Delete compartment (optional, only if empty) – Remove any remaining resources first.

11. Best Practices

Architecture best practices

Design fleets around ownership and operational boundaries, not purely around technical topology.
Good fleet boundaries: environment (prod/dev), business unit, SLA tier, compliance boundary.
Use compartments to enforce environment separation and apply IAM and quotas cleanly.
Prefer private subnets for production hosts; control egress with NAT and allowlists.

IAM/security best practices

Use least privilege:
Separate roles: fleet viewers, fleet operators, fleet administrators.
Keep onboarding privileges (agent install keys, registration) restricted.
Use dynamic groups only when required by your chosen integration; prefer explicit user/group permissions for administrative actions.

Cost best practices

Avoid always-on NAT Gateways in small dev environments unless required.
Keep telemetry/log retention minimal while meeting compliance.
Tag fleets and hosts for cost allocation and chargeback.

Performance best practices

Validate agent overhead on representative hosts before large-scale rollout.
Stagger discovery/refresh jobs (if configurable) to avoid thundering herd effects.

Reliability best practices

Treat agents as part of your production runtime dependencies:
monitor agent health,
automate reinstall/repair runbooks,
standardize golden images if possible.
Use compartments and tagging to ensure correct scoping when hosts are replaced.

Operations best practices

Centralize operational logs (agent logs, key service logs) with consistent retention.
Establish a naming convention:
Fleets: <App>-<Env>-<Region> or <Domain>-<Env>
Hosts: include environment and role
Create runbooks for:
onboarding/offboarding hosts
common discovery failures
access review procedures

Governance/tagging/naming best practices

Mandatory tags (common):
Environment, Owner, CostCenter, DataClassification
Use defined tags with allowed values to prevent drift.
Align fleet design with landing zone guardrails.

12. Security Considerations

Identity and access model

Users access Fleet Application Management via OCI IAM.
Use compartments to constrain blast radius.
Prefer separate groups:
FAM-Admins: create/delete fleets, configure discovery
FAM-Ops: day-2 operations
FAM-Viewers: read-only for auditors/support

Encryption

OCI control-plane services generally encrypt data at rest and in transit as part of the platform.
Verify service-specific encryption statements in the official documentation and compliance docs.

Network exposure

Managed hosts should not require inbound internet connectivity for agent operation in many designs; outbound egress is more typical.
For production:
keep hosts private,
restrict egress destinations,
avoid broad 0.0.0.0/0 inbound rules.

Secrets handling

Do not store credentials in scripts or on hosts.
Use OCI Vault for secrets used by operational tooling around fleets.
Rotate agent-related keys/tokens per documented procedures.

Audit/logging

Use OCI Audit to track who changed fleet configuration and onboarding keys.
Export audit logs to your SIEM if required.
Collect agent logs centrally to detect tampering or repeated registration failures.

Compliance considerations

Map fleets to compliance boundaries:
PCI, HIPAA, SOC2, ISO27001
Apply compartment-level policies and tagging.
Ensure evidence collection:
inventory exports/screenshots (where accepted),
audit logs,
change records.

Common security mistakes

Over-permissioned policies (“manage all-resources in tenancy”) in production.
Public subnets for production app hosts.
Not monitoring agent health (silent visibility loss).
Long-lived onboarding keys not rotated/revoked.

Secure deployment recommendations

Start with a pilot compartment and a small set of hosts.
Lock down IAM before scaling.
Use a dedicated subnet/NSG for managed hosts and standardize egress.

13. Limitations and Gotchas

Because capabilities vary by region and supported application types, confirm details in official docs. Common gotchas include:

Supported application types: Discovery and management actions typically apply only to specific stacks. If your app type isn’t supported, you may only get host-level association (or nothing beyond agent health).
Region availability: Service may not be available in every region or may have feature differences.
Network requirements: Agent needs outbound connectivity to OCI endpoints; private subnet deployments require NAT or equivalent.
IAM scoping pitfalls:
Fleet in one compartment, agent/host in another can cause visibility/association issues.
Agent lifecycle management:
OS upgrades, firewall changes, or certificate/time drift can break registration.
Telemetry costs:
If you integrate with additional logging/analytics services, costs can rise quickly.
Operational expectation mismatch:
Fleet Application Management is not the same as deep APM tracing; use OCI APM for request traces and code-level diagnostics.

14. Comparison with Alternatives

Fleet Application Management sits in the middle ground between “host management” and “deep application observability.” Consider what you actually need: inventory, patching, runtime metrics, traces, or configuration management.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Fleet Application Management	Fleet-level application inventory/management in OCI	Fleet grouping, OCI governance (IAM/compartments), centralized inventory (supported types)	Discovery/actions depend on supported app types; region/feature variability	When you need application estate inventory and fleet operations in OCI
OCI Application Performance Monitoring (APM)	Performance tracing and diagnostics	Distributed tracing, service maps, app-centric diagnostics	Not primarily an inventory/CMDB tool; requires instrumentation	When you need deep performance visibility and traces
OCI Logging / Logging Analytics	Centralized logs and log analytics	Flexible ingestion, search, retention, dashboards (service-dependent)	Cost can scale with ingestion/retention; doesn’t inherently model “fleets”	When logs are your primary operational signal
OCI OS Management Hub	OS patching and package lifecycle	Patch compliance, scheduling, OS/package inventory	Focused on OS-level, not app-level modeling	When your main goal is OS patching/compliance at scale
Oracle Enterprise Manager (self-managed)	Deep enterprise monitoring for Oracle stacks (on-prem/hybrid)	Mature management for Oracle middleware/db in many enterprises	Requires infrastructure and admin overhead; separate platform	When you already standardize on Enterprise Manager for enterprise estates
AWS Systems Manager	Host and application operations on AWS	Mature fleet operations (Run Command, Patch Manager, Inventory)	AWS-specific; not OCI-native	When your fleet is on AWS and you want native tooling
Azure Arc + Azure Monitor	Hybrid management across clouds/on-prem	Strong hybrid story; policy integrations	Azure-centric control plane; onboarding overhead	When you’re standardized on Azure for hybrid ops
Open-source (Ansible + Prometheus + Grafana)	Customizable self-managed operations	Highly flexible; portable	More engineering/ops burden; governance and inventory are DIY	When you need portability and can run/operate the stack yourself

15. Real-World Example

Enterprise example: Regulated payments platform on OCI

Problem
A payments company runs 200+ VM-based application instances across dev/test/prod compartments. Auditors require evidence of: – where applications run, – who can operate them, – change accountability.

Proposed architecture – Use compartments per environment and compliance boundary. – Create fleets per business capability (Payments, Billing, Risk) and environment (Prod/NonProd). – Onboard hosts with the management agent. – Centralize audit logs and integrate with Notifications for operational events (where available).

Why Fleet Application Management was chosen – Fleet-first model aligns with enterprise governance. – Integrates with OCI IAM, compartments, and audit. – Provides centralized inventory without building a custom CMDB pipeline.

Expected outcomes – Faster audit evidence generation. – Reduced “unknown application instance” drift. – Clearer separation of duties and reduced over-permissioning.

Startup/small-team example: SaaS with 20 app servers scaling quickly

Problem
A SaaS startup is growing from 10 to 60 VMs across regions. They don’t want to maintain spreadsheets of which app version runs where.

Proposed architecture – One non-prod and one prod compartment. – Fleets per environment and service boundary. – Tagging for ownership and cost. – Minimal logging retention for cost control.

Why Fleet Application Management was chosen – Centralized inventory and governance with low operational overhead. – Works well with OCI-native patterns.

Expected outcomes – Cleaner operational handoffs as the team grows. – Less time spent tracking deployments manually. – A better foundation for compliance as customers demand SOC2.

16. FAQ

1) Is Fleet Application Management the same as APM?
No. APM focuses on performance telemetry like traces and spans. Fleet Application Management focuses on organizing and managing application estates as fleets (inventory/management workflows).

2) Does Fleet Application Management work for any application?
Not necessarily. Discovery and actions typically depend on supported application types. Verify supported stacks in the official docs.

3) Do I need an agent on every host?
In most fleet-style management models, yes—some kind of agent/collector is typically required to discover inventory and report health. Verify exact requirements in OCI docs.

4) Can I manage on-prem hosts?
Possibly, depending on supported onboarding modes and connectivity requirements. Verify hybrid support in official documentation.

5) How does access control work?
Through OCI IAM policies and compartments. You can restrict who can view or manage fleets and related resources.

6) Is Fleet Application Management regional?
OCI services often have region-scoped behavior. Verify whether fleet resources and inventory are region-specific in the official docs.

7) What network ports/protocols are required?
Agents commonly need outbound HTTPS to OCI endpoints. Exact endpoints and ports should be taken from official docs for your agent version and region.

8) Can I use private subnets?
Yes, commonly. Provide outbound egress (NAT Gateway or other controlled egress) so the agent can reach OCI endpoints.

9) How do I troubleshoot agent registration issues?
Check DNS, outbound HTTPS, system time, and agent logs. Confirm you used the correct install key and compartment.

10) Will it increase my OCI bill?
Potentially. Even if the service control plane is low-cost, compute, NAT, data egress, and log storage can add cost. Use the Oracle price list and cost estimator.

11) Can I automate fleet creation?
Often yes via APIs/SDKs/CLI if supported. Confirm API availability for Fleet Application Management in the official API reference.

12) Does it integrate with OCI Events and Notifications?
Many OCI services can emit events, but availability varies. Verify Fleet Application Management event types and metrics in docs.

13) How should I name fleets?
Use names that encode ownership and environment, e.g., Payments-Prod, Billing-NonProd, plus region if needed.

14) What is the best first production rollout strategy?
Start with a pilot: one compartment, one fleet, a small set of hosts, validate IAM and discovery, then expand gradually.

15) What’s the difference between host management and application fleet management?
Host management focuses on OS patching and instance lifecycle. Application fleet management models and groups application instances/deployments so you can operate at the app boundary.

17. Top Online Resources to Learn Fleet Application Management

Resource Type	Name	Why It Is Useful
Official Documentation	Fleet Application Management docs – https://docs.oracle.com/en-us/iaas/fleet-application-management/home.htm	Primary source for current features, concepts, and workflows
Official Documentation	Management Agent docs – https://docs.oracle.com/en-us/iaas/management-agent/home.htm	Required for host onboarding and troubleshooting agent issues
Official Pricing	Oracle Cloud Price List – https://www.oracle.com/cloud/price-list/	Authoritative pricing reference (region/SKU dependent)
Pricing Tool	OCI Cost Estimator – https://www.oracle.com/cloud/costestimator.html	Estimate end-to-end costs including compute/network/logging
Free Tier	Oracle Cloud Free Tier – https://www.oracle.com/cloud/free/	Understand Always Free limits and eligibility
Architecture Center	OCI Architecture Center – https://docs.oracle.com/solutions/	Reference architectures and best practices (use search for observability/management patterns)
Governance	OCI IAM docs – https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm	Policies, compartments, and least-privilege design
Observability	OCI Monitoring docs – https://docs.oracle.com/en-us/iaas/Content/Monitoring/home.htm	Alerts/alarms patterns that often complement fleet operations
Logging	OCI Logging docs – https://docs.oracle.com/en-us/iaas/Content/Logging/home.htm	Central log collection patterns for agents and workloads
Community (reputable)	Oracle Cloud customer architecture/blog resources – https://blogs.oracle.com/cloud/	Practical posts and updates; validate against official docs

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, cloud engineers	DevOps practices, automation, cloud ops foundations (verify OCI-specific coverage)	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	SCM, CI/CD, DevOps fundamentals	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud ops practitioners	Operations, monitoring, cloud management concepts	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs and reliability-focused engineers	SRE practices, incident management, observability	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and platform teams exploring 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 content (verify latest topics)	Beginners to working professionals	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training	Engineers building CI/CD and ops skills	https://www.devopstrainer.in/
devopsfreelancer.com	DevOps freelance/training services (verify offerings)	Teams needing short-term enablement	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training resources (verify offerings)	Ops teams needing troubleshooting support	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify service catalog)	Implementation support, platform engineering	Landing zone setup, observability rollout planning, governance design	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement	Training + implementation guidance	Fleet onboarding process design, IaC enablement, ops runbooks	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify service catalog)	DevOps process and tooling	CI/CD modernization, monitoring strategy, operational maturity improvements	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Fleet Application Management

OCI fundamentals:
compartments, VCNs, subnets, routing, security lists/NSGs
IAM basics:
groups, policies, dynamic groups, least privilege
Linux basics:
services (systemctl), logs (journalctl), networking
Observability basics:
metrics vs logs vs traces; alerting fundamentals

What to learn after Fleet Application Management

OCI Monitoring + Alarms: operational alerting
OCI Logging and (optionally) Logging Analytics: centralized troubleshooting
OCI Events + Functions: automation for common operational tasks
OS Management Hub: OS patch compliance at scale
IaC with Terraform/Resource Manager: standardized provisioning and drift control

Job roles that use it

Cloud Engineer / Cloud Operations Engineer
DevOps Engineer
Site Reliability Engineer (SRE)
Platform Engineer
Security Engineer (governance and auditability)
Solutions Architect (operational architecture design)

Certification path (if available)

Oracle certification offerings change over time. Check current OCI certification paths here: – https://education.oracle.com/

Look for certifications related to: – OCI Foundations – OCI Architect / Operations tracks – Observability/Management topics (if offered)

Project ideas for practice

Build a multi-compartment lab (dev/prod) and implement fleet separation with least privilege.
Onboard 5–10 hosts and standardize tags, naming, and access roles.
Create a runbook for agent failures and implement centralized agent log collection.
Integrate alarms/notifications for operational signals relevant to your fleet.

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud’s IaaS/PaaS platform.
Observability and Management: OCI category covering monitoring, logging, and operational services.
Fleet: A logical group used to manage multiple application instances/deployments together.
Compartment: An OCI governance boundary for organizing and isolating resources.
IAM Policy: A rule that grants permissions in OCI (who can do what in which compartment).
Managed host/entity: A server/instance connected to OCI for inventory/management.
Management Agent: Host-based agent used to connect workloads to OCI management services (exact usage depends on service and configuration).
NAT Gateway: Provides outbound internet connectivity for private subnet resources without exposing them to inbound internet traffic.
Audit log: OCI record of control-plane actions for governance and forensics.
Tags (defined/freeform): Metadata used for governance, search, and cost allocation.

23. Summary

Fleet Application Management in Oracle Cloud (under Observability and Management) helps you manage applications at scale using a fleet-based model: discover supported application inventory on connected hosts, group assets into fleets, and operate with OCI-native governance (compartments, IAM, tags, audit).

It matters because operational complexity grows faster than infrastructure count. Fleets give you a practical structure for inventory, change planning, and access control—especially in multi-environment, multi-team organizations.

Cost-wise, the main drivers are usually compute, network egress/NAT, and any additional logging/telemetry retention you enable. Security-wise, success depends on least privilege IAM, controlled egress for agents, and strong compartment/tag governance.

Use Fleet Application Management when you need centralized application estate visibility and fleet operations in OCI. If your priority is deep performance tracing, choose OCI APM instead, and if you mainly need OS patching, consider OS Management Hub.

Next learning step: review the official Fleet Application Management docs and validate which application types are supported in your region, then build a small pilot fleet in a dedicated compartment: – https://docs.oracle.com/en-us/iaas/fleet-application-management/home.htm

rajeshkumar

Category