VCF Operations Cloud Operations 8.x Professional (2V0-32.24)

Aria Operations Architecture#

Aria Operations 8.x uses a distributed architecture optimized for multi-cloud environments. The platform separates collection, analytics, and presentation tiers for scalability and resilience.

Key Architectural Components:

Collector nodes ingest data via adapters → Analytics cluster (master/replica/data nodes) performs time-series analysis → Remote collectors for branch offices and edge environments → Cloud Proxies for public cloud agentless monitoring → Adapter instances run on collectors or Analytics cluster nodes.

┌─────────────────────────────────────────────────────────────────┐
│                    Analytics Cluster (Master/Replica/Data)      │
│  ┌──────────────┬──────────────┬──────────────────────────────┐ │
│  │   Master     │   Replica    │   Data Nodes (N+2)           │ │
│  │   (Active)   │   (Standby)  │   (Time-series DB)           │ │
│  └──────────────┴──────────────┴──────────────────────────────┘ │
└─────────────────┬──────────────────────────────────────────────┘
                  │ Ingestion Pipeline
        ┌─────────┴──────────┬──────────────────┐
        │                    │                  │
   ┌────▼────┐  ┌──────▼──────┐  ┌─────▼────────────┐
   │Collectors│  │Remote       │  │ Cloud Proxies    │
   │(Local)   │  │Collectors   │  │ (AWS/Azure/GCP)  │
   └────┬────┘  └──────┬──────┘  └─────┬────────────┘
        │               │               │
   ┌────▼───────┐ ┌────▼────┐ ┌────────▼──────┐
   │vSAN        │ │ Branch  │ │ Public Cloud   │
   │vSphere     │ │ Office  │ │ Resources      │
   │NSX Adapter │ │ Remote  │ │ (Agentless)    │
   └────────────┘ └────────┘ └───────────────┘

Sizing & HA Architecture

• Deployment
• Master Nodes
• Data Nodes
• Collectors
• Objects
• Small
• 1 (8vCPU, 32GB RAM)
• 2 (8vCPU, 32GB RAM ea)
• 1-2 (4vCPU, 16GB RAM)
• 0-500
• Medium
• 1 (16vCPU, 64GB RAM)
• 4 (16vCPU, 64GB RAM ea)
• 3-4 (8vCPU, 32GB RAM)
• 500-5000
• Large
• 3 HA (20vCPU, 128GB RAM)
• 6+ (20vCPU, 128GB RAM ea)
• 6+ (12vCPU, 48GB RAM)
• 5000+

Exam Focus:

Understand object count sizing. Each vSphere host = 1 object; storage array = 1 object; VMs counted towards object limit. Use the Aria Sizing utility to validate infrastructure. For large deployments (5000+ objects), master node HA with 3-node cluster is mandatory.

HA Architecture:

Master nodes use Raft consensus. With 3-node master cluster, failure of one node does not impact operations. Replica nodes stand by but do not participate in consensus. Data nodes are strictly read-only and replicate from master. All writes go through master node first.
Collector failure does not cause data loss (collectors are stateless), but monitoring blind spots occur until collector returns. Remote collectors must maintain connectivity to Analytics cluster master node; if connectivity is lost, they buffer locally (up to 48 hours depending on collector specs) and replay data upon reconnection.

Adapter Architecture & Data Collection

Adapters are the extension mechanism for Aria Operations. Each adapter connects to a target system (vSphere, NSX, storage array, public cloud service) and collects data.

Adapter Execution Model:

• Collector-side adapters: Run on Collector VM, pull data from targets
  • vSphere Adapter Instance pulls metrics from vCenter API
  • NSX Adapter Instance queries NSX Manager via REST API
  • Cloud adapters (AWS, Azure) authenticate and pull CloudWatch/Azure Monitor metrics
  • Storage vendor adapters (Pure, NetApp, Dell) connect via management IP

• Analytics cluster adapters: Run on Analytics cluster nodes
  • Typically compute-intensive: Forecast adapters, Custom Group calculations
  • Health Score Adapter aggregates metrics into health scores

• Adapter instances per collector/cluster: Configured via Adapter Management UI
  • Default: 1 instance per collector
  • Scaling: Add instances for high-volume data sources (large vSphere estates)
  • Each instance consumes ~4vCPU, 8GB RAM minimum

Collection Intervals:

Standard interval = 5 minutes. Custom interval down to 1 minute possible but increases Analytics cluster load. High-frequency metrics (10-30sec) reserved for troubleshooting via Log Insight integration, not core collection.

Key Takeaways

• Exam Focus:Understand object count sizing. Each vSphere host = 1 object; storage array = 1 object; VMs counted towards object limit. Use the Aria Sizing utility to validate infrastructure. For large deployments (5000+ objects), master node HA with 3-node cluster is mandatory.

Monitoring & Alerting#

Aria Operations monitoring is built on an extensible object model with metrics, properties, symptoms, and alerts as the primary abstractions.

Object Model & Metric Types

Resource Kinds (Objects):

├── vSphere Resources
│   ├── Virtual Machine
│   ├── Host
│   ├── Cluster
│   ├── Datastore
│   └── vSAN
├── NSX Resources
│   ├── Logical Switch
│   ├── Logical Router
│   └── DFW Rule
├── Cloud Resources
│   ├── EC2 Instance
│   ├── RDS Database
│   └── EBS Volume
└── Custom Resources
    └── Application (via Custom Group)

Metrics → Time-series numerical data
Properties → Static/semi-static attributes
Super Metrics → Calculated from base metrics

Examples:

• cpu|usage_percent (base metric)
• config|memory (property)
• cpuDemand = cpu|demand / numvCPUs (super metric)

Metric Components:

Each metric has a counter name (cpu|usage_percent), collection interval (5min default), aggregation method (average, max, min, sum), and retention policy (365 days for hourly, 90 days for 5-min by default).

Super Metrics:

Calculated metrics that combine base metrics. Syntax: Function(Metric1, Metric2). Examples: cpu|utilization = cpu|usage_average / cpuDemand; memory|efficiency = memory|swapusage / memory|totalCapacity. Super metrics have 10-60sec calculation latency.

Example Super Metric Definition:

Name: VM Power Efficiency

• Expression: (power|energy_consumed) / (cpu|demand + memory|demand)
• Resource Kind: Virtual Machine
• Metric Type: Gauge
• Unit: Joules/Watt
• Aggregation: Average

// Used for VM consolidation scoring and cost analysis

Dashboards, Symptoms & Alerts

Dashboard Architecture:

Dashboards are collections of widgets. Each widget queries the Analytics cluster and renders metrics or custom data. Dashboards support:

Metric widgets:

Line/area/bar charts, heatmaps, gauges

Table widgets:

Sorted/filtered lists of objects with metric values

Custom HTML/JS:

Embedded visualizations via custom widgets

Interaction:

Drill-down from dashboard to detail views (object relationships)

Permissions:

Dashboard visibility can be restricted by resource groups or user roles

Symptom Definitions:

Symptoms are conditions (thresholds, anomalies, patterns) that trigger alerts. Symptoms are object-scoped (apply to specific resource kind) and reusable across alert definitions.
Symptom Example: CPU Over-provisioned

Type: Threshold

• Condition: (cpu|demand_percent > 80) AND (cpu|usage_percent < 20) for 30 minutes
• Severity: Warning
• Resource Kind: Virtual Machine
• Wait Cycle: 1 (fire after first evaluation)
• Cancel Cycle: 3 (resolve after 3 cycles without trigger)
• Recommendation: "Consider right-sizing VM vCPU allocation"

Alert Definitions:

Alerts combine symptoms with notification rules. An alert fires when all symptom conditions are met.

Alert Definition: CPU Over-provisioned Alert

Active: Yes

Symptom: CPU Over-provisioned

Action: Email to ops-team@company.com

REST POST to https://slack-webhook/alerts

SNMP Trap to 192.168.1.100 (public community)

Custom Action: Invoke vRO Workflow (VM Right-size)

Notification Preference: Once per change (deduplicate repeated alerts)

Adaptive Threshold: Baseline learned from 7-day history

Alert Automation Best Practice:

Use alert definitions with REST actions to integrate with ServiceNow. Structure payload with Incident table fields: short_description, description, cmdb_ci (config item), impact (high/medium/low). Use custom groups as affected CI to auto-populate the affected_applications table. This enables closed-loop remediation via ITSM ticketing.

Custom Groups:

Create logical groupings of resources for scoping alerts and dashboards. Custom groups support:

Static membership:

Manually select objects

Dynamic membership:

Query-based (objects matching metric criteria)

Nested groups:

Groups can contain other groups

Tag-based membership:

Objects with matching tags (e.g., environment:prod)

Custom group definitions are re-evaluated every 5 minutes. High-cardinality queries (e.g., all VMs with cpu|usage_average > 0) can impact Analytics cluster performance. Use property-based or tag-based membership when possible instead of metric-based queries.

Key Takeaways

• Alert Automation Best Practice:Use alert definitions with REST actions to integrate with ServiceNow. Structure payload with Incident table fields: short_description, description, cmdb_ci (config item), impact (high/medium/low). Use custom groups as affected CI to auto-populate the affected_applications table.
• Capacity Planning Methodology: Demand = actual workload need (peak historical + trend). Allocation = vCPU/GB assigned to VM. Utilization = actual usage. Key pattern: VM with 8vCPU allocation but 1vCPU demand is over-provisioned 7 vCPU (design problem, NOT utilization problem). Time remaining = (Allocation - Current_Usage) / Growth_Rate.
• Custom Dashboards for VCF Health: Create org-level dashboard showing fleet capacity, compliance posture, cost trends. Drill-down to SDDC-level dashboards. Include alerts, anomalies, and trending. Update weekly with stakeholder visibility. Recommendation: embed dashboard in landing page for ops team.
• Alert Tuning to Reduce Noise: Threshold-based alerts prone to false positives. Strategy: (1) Adaptive threshold (learned from 7-day baseline), (2) confirmation rules (alert only if symptom repeated 3x), (3) exclusion lists (known benign events), (4) business hours filters (suppress alerts outside ops hours). Tune iteratively; noisy alerts get ignored.
• Integration with SDDC Manager Lifecycle: VCF Operations 9.0 monitors bundle updates, patch status, firmware compliance across fleet. Set policies for 'patch within 30 days of release', 'firmware version within N builds'. Auto-alert on drift. Enable closed-loop remediation via SDDC Manager APIs.

Capacity Management#

Capacity analytics predict when resource exhaustion will occur and recommend allocation adjustments. The model separates demand (what workloads need) from allocation (what they're assigned) from utilization (what they actually use).

Demand Model & Time Remaining Analysis

Capacity Model Definitions:

Demand = Actual workload requirement

• Calculated from peak historical usage + growth trend
• CPU demand = peak cpu|usage + forecast growth
• Memory demand = max(rss) from workload monitoring

Allocation = Resource assigned to VM

• CPU allocation = vCPU count (= vCPU_sockets * cores_per_socket)
• Memory allocation = GB assigned (shown in VM config)

Utilization = What workload actually uses

• CPU utilization = cpu|usage_average / numvCPUs
• Memory utilization = memory|used / memory|total

Time Remaining:

• Calculated per cluster or datastore
• Formula: (Allocation - Current_Usage) / Average_Growth_Rate
• Example: 500GB free, 50GB/week growth = 10 weeks until full
• Growth rate uses 30-day trend; adjusts during seasonal patterns

Reclaimable Capacity Analysis:

Identifies unused allocated resources that can be freed. Types: (1) VMs with allocation > demand (over-provisioned), (2) Powered-off VMs (zero demand), (3) Orphaned disks (unattached snapshots), (4) Datastores with zero VMs. Recommended action: Reclaim to increase utilization ratio.

Allocation Model Components:

Contention detection:

When demand exceeds allocation, workload experiences performance degradation (balloon driver active, page fault rate > 0, ready time > 5%)

Efficiency factor:

Ratio of utilization to allocation. Target: 60-70% for production (headroom for spikes), 80%+ for test/dev

Growth trends:

Linear (constant rate), exponential (accelerating), or seasonal (predictable cycles like month-end batch jobs)

Exam Focus:

Understand the difference between demand and allocation. A VM with 8vCPU allocation but only 2vCPU demand is over-provisioned by 6vCPU (regardless of current utilization). This is independent of current cpu|usage_percent. The demand model enables right-sizing recommendations.

What-If Scenarios:

Capacity analytics supports predictive modeling. You can simulate hardware additions, workload changes, or policy adjustments and see projected time remaining.

What-If Scenario Example:

Current: Cluster has 300GB memory, 50GB free, 5GB/week growth → 6 weeks remaining
Scenario 1: Add 2 new hosts (200GB memory)
  → 450GB total, 250GB free, 5GB/week growth → 50 weeks remaining
Scenario 2: Consolidate VMs (reduce 30GB demand through right-sizing)
  → 300GB total, 80GB free, 2GB/week growth → 40 weeks remaining

Capacity Policies & Rightsizing

Capacity Policies:

Policies define targets and trigger recommendations when violated. Policy types:

Headroom policy:

Keep cluster minimum X% free capacity (e.g., 20% headroom)

Utilization policy:

Keep resource utilization between Y% and Z% (e.g., 50-80%)

Efficiency policy:

VM allocation should not exceed demand by more than W% (e.g., 20% max over-provisioning)

Time Remaining policy:

Keep at least V weeks of capacity before exhaustion (e.g., 4 weeks planning horizon)

Rightsizing Recommendations:

Generated automatically when policies are violated. Recommendations include:

Recommendation Types:

1. VM CPU Right-size (reduce vCPU count)

Example: "VM demo-prod has 8 vCPU allocated, peak demand 1.2 vCPU.

Reduce to 2 vCPU to save 6 vCPU allocation."

Confidence: 95% (based on 30-day historical peak)
Impact: +4.8 GHz available in cluster

2. VM Memory Right-size (reduce memory allocation)

Example: "demo-web-01 has 32GB allocated, peak usage 8.5GB.
Reduce to 12GB to save 20GB."

3. VM Consolidation (move VMs to smaller cluster)

Example: "Consolidate 4 test VMs from prod-cluster to test-cluster,
saving 80GB memory allocation."

4. Storage Deprovisioning (delete snapshots/orphaned disks)

Example: "Delete 15 orphaned snapshots (no parent VM), freeing 250GB."

Confidence: Ranges from 70% (nascent workload, <7 days data) to 99%
(mature workload, >90 days history)

Implementation Pattern:

Use Aria custom groups to stage consolidation projects. Create custom group "Candidate for Consolidation" with dynamic membership based on demand metrics. Generate rightsizing reports for exec leadership to approve migrations, then use change management workflow to execute.

Key Takeaways

• Exam Focus:Understand the difference between demand and allocation. A VM with 8vCPU allocation but only 2vCPU demand is over-provisioned by 6vCPU (regardless of current utilization). This is independent of current cpu|usage_percent. The demand model enables right-sizing recommendations.
• Implementation Pattern:Use Aria custom groups to stage consolidation projects. Create custom group "Candidate for Consolidation" with dynamic membership based on demand metrics. Generate rightsizing reports for exec leadership to approve migrations, then use change management workflow to execute.

Performance Optimization & Cost Analysis#

Workload Optimization Architecture:

Aria integrates with vSphere DRS (Distributed Resource Scheduler) to optimize VM placement. The optimization workflow:

• Collect performance metrics for all VMs (CPU, memory, storage I/O latency)
• Identify contention (demand > allocation) and imbalance (hosts at 20% vs 90% utilization)
• Recommend VM migrations to balance load
• Invoke DRS via REST API to execute migrations
• Monitor post-migration metrics to validate optimization

Automated Actions:

Aria can trigger vRealize Orchestrator (vRO) workflows when performance thresholds are crossed. Example: When cluster memory utilization exceeds 85% for 15 minutes, trigger workflow to (1) consolidate idle VMs, (2) increase cluster capacity via API call to IaaS team, (3) notify ops team with 30-min Slack message.

Showback & Chargeback

Showback:

Display-only cost reporting to departments/business units. No actual financial transaction. Used for cost transparency and optimization driver.

Chargeback:

Billing departments based on resource consumption. Real financial impact. Requires precise cost allocation rules and approval workflows.

Showback/Chargeback Configuration:

1. Define Cost Model:

• Compute cost: $/vCPU/month (e.g., $150)
• Memory cost: $/GB/month (e.g., $10)
• Storage cost: $/GB/month (tiered: SSD=$0.20, SAS=$0.05, NL-SAS=$0.01)
• Networking cost: $/GB transferred/month (e.g., $0.08)

2. Apply Tagging Strategy for Allocation:

• Tag VM: costcenter:engineering, environment:production, application:crm
• Tags drive allocation rules in report

3. Calculate Monthly Cost per Business Unit:

Example Report:

Department: Engineering

   ├── Production VMs: 50 VMs × (8 vCPU × $150) + (32GB × $10) = $60,000/month
   ├── Development VMs: 20 VMs × (2 vCPU × $150) + (8GB × $10) = $6,000/month
   └── Test VMs: 10 VMs × (1 vCPU × $150) + (4GB × $10) = $2,500/month

Total: $68,500/month

4. Trend Analysis:

• Compare month-to-month consumption
• Identify cost drivers (e.g., 3 new prod VMs added this month)
• Show-back report: "Engineering spent $68.5K this month, up 8% from last month"
• Chargeback bill: Finance dept sends invoice to Engineering for $68.5K

5. Tagging Strategy Considerations:

• costcenter: Billing department code (required for chargeback)
• environment: prod/staging/dev (impacts cost tier)
• application: Business application name (cost allocation granularity)
• owner: VM owner email (notification for high cost)
• confidentiality: public/internal/confidential (for compliance cost tracking)

Exam Focus:

Understand tagging as the mechanism for cost allocation. Without consistent tagging, showback/chargeback reports are unreliable. Design tagging strategy BEFORE implementing chargeback (retroactive tagging is manual and error-prone).

Cost Optimization Workflows:

Use Aria insights to drive cost reduction:

• Identify over-provisioned VMs (allocation >> demand) and schedule right-sizing
• Find idle VMs (utilization < 5% for 30 days) and archive/delete
• Recommend reserved instances for AWS/Azure for stable baseline workloads
• Highlight candidates for consolidation to reduce compute node count
• Analyze network egress costs and identify optimization opportunities (multicast, caching)

Key Takeaways

• Exam Focus:Understand tagging as the mechanism for cost allocation. Without consistent tagging, showback/chargeback reports are unreliable. Design tagging strategy BEFORE implementing chargeback (retroactive tagging is manual and error-prone).

Compliance & Configuration#

Aria Compliance module monitors infrastructure against regulatory frameworks and organizational policies. Drift detection identifies when configuration diverges from desired state.

Compliance Frameworks & Remediation

Supported Compliance Frameworks:

HIPAA (Healthcare):

• Enforce disk encryption on all VMs (FIPS 140-2 required)
• Require 2FA on vCenter admin accounts
• Audit logging (6-month retention minimum)
• Approved patching schedule (monthly)

Scored: Number of non-compliant VMs / total VMs

PCI-DSS v3.2 (Payment Card Industry):

• Enforce TLS 1.2+ for all management connections
• Vulnerability scanning on ESXi (quarterly minimum)
• Firewall rules documenting data flow
• Patch level requirements (no ESXi > 30 days old)
• Admin access logging and review (quarterly)

Scored: Compliance controls passed / total required controls

DISA STIG (DoD):

• Kernel hardening (DKMS, SELinux enforcing)
• SSH key-only authentication
• Anti-malware deployment
• Privileged account management
• Configuration vulnerability scanning

Scored: Severity 1/2 findings vs. acceptable risk

CIS Benchmarks (vSphere Hardening):

• vCenter SSL certificate validation
• NTP configuration (not relying on DHCP)
• syslog forwarding to remote server
• vSAN encryption (if applicable)
• NSX DFW enabled for north-south and east-west

Scored: Percentage of CIS recommendations implemented

Compliance Scorecard:

Dashboard showing compliance posture across all frameworks. Compliance score = (Number of controls passing / Total controls) × 100%. Drill-down by framework, resource, or control category to identify remediation priorities.

Drift Detection:

Monitors configuration changes that violate compliance baseline. Example:

Drift Detection Example:

Baseline (from HIPAA policy):

• All prod VMs must have encryption enabled
• Encryption algorithm: AES-256
• Boot options: UEFI with Secure Boot

Actual State Detection:

• VM prod-web-01: Encryption ON ✓
• VM prod-db-01: Encryption OFF ✗ (drift detected)

Cause: Recently expanded disk, encryption not re-enabled

• VM prod-app-01: Encryption ON, algorithm: AES-128 ✗ (algorithm mismatch)

Alert: "3 VMs in drift from HIPAA encryption baseline"

Remediation Options:

  1. Manual: Admin logs into Aria, clicks "Remediate" → re-applies baseline config
  2. Automated: Aria invokes vRO workflow → re-enables encryption, triggers restart

3. Compliance report: Audit trail documents drift incident and remediation

Architectural Consideration:

Compliance baselines must be version-controlled. When vSphere/NSX version upgrades occur, compliance baseline may change (e.g., new TLS ciphers available). Use Aria configuration management API to version and audit baseline changes.

Desired State Configuration:

Define target configuration for resources. Aria continuously monitors and can auto-remediate drift.
vSphere desired state:

CPU reservation, memory reservation, vNIC settings, boot options

NSX desired state:

DFW rule sets, logical network topology, security policies

Storage desired state:

Volume provisioning, snapshot schedules, replication settings

Remediation automation:

Auto-remediate low-risk drift (e.g., NTP server), require approval for high-risk drift (e.g., firewall rule changes)

Key Takeaways

• Architectural Consideration:Compliance baselines must be version-controlled. When vSphere/NSX version upgrades occur, compliance baseline may change (e.g., new TLS ciphers available). Use Aria configuration management API to version and audit baseline changes.

Integration & Extensibility#

Aria Operations integrates with VMware and third-party platforms via adapters, management packs, REST APIs, and agent-based collectors.

Management Packs & Vendor Adapters

VMware-Native Management Packs:

vSAN Management Pack:

• Metrics: Disk group health, cluster capacity, rebuild time remaining
• Health score: Composite of disk health, network health, controller health
• Alerts: Disk degradation, capacity headroom < 10%, disk rebuild >1 hour
• Remediation: Trigger disk replacement, capacity expansion workflows
• Integration: Feeds into cluster capacity recommendations

NSX Management Pack:

• Monitor: DFW rules, logical networks, edge services
• Metrics: Rule hit counts, denied packet counts, latency through logical routers
• Health: Segment connectivity, gateway availability, NAT pool exhaustion
• Alerts: Failed DFW rules, logical router failover, IP pool exhaustion
• Extensibility: Custom rules for business logic (e.g., all prod VMs blocked = alert)

HCX Management Pack:

• Monitor: Cloud Connector health, replication status, vMotion latency
• Metrics: Replication lag, bandwidth utilization, active migrations
• Health: Connector uptime, network circuit saturation
• Alerts: Migration failure, high latency, cloud endpoint unreachable

vSphere Management Pack (Core):

• VM metrics: CPU, memory, disk I/O, network latency, application performance
• Host metrics: Physical CPU/memory, I/O wait, network stats
• Cluster metrics: Aggregated health, DRS action count
• Datastore metrics: Space consumed, I/O latency, snapshot overhead

Third-Party Adapters:

Integration with storage vendors and hyperscalers.

Storage Vendor Adapters:

Pure Storage FlashArray:

• Collector-side adapter pulls metrics via REST API
• Metrics: Array utilization %, IOPS, latency, cache hit rate
• Health: Controller redundancy, battery backup status
• Correlation: Relates array performance to VM I/O latency (root cause analysis)

NetApp ONTAP:

• Metrics: Volume utilization, qtree usage, SnapShot count
• Health: WAFL inefficiency, snapshot reservation exhaustion
• Alerts: LUN overprovisioning, snapshot space runout

Dell EMC PowerVault:

• Metrics: Aggregate health, disk state, battery backup status
• Health: RAID status, hot spare usage

AWS CloudWatch Adapter (via Cloud Proxy):

• Metrics: EC2 CPU, network in/out, EBS latency, RDS connections
• Enables hybrid capacity planning (on-prem + cloud)
• Cost integration: CloudWatch cost data + on-prem chargeback model

Azure Monitor Adapter:

• Metrics: VM CPU/memory, storage transaction latency
• Health: Availability set redundancy, managed disk performance

Exam Focus:

Understand adapter licensing. Each management pack (vSAN, NSX, HCX, vendor-specific) may require separate licensing. VCF Operations Suite includes base Aria Operations license + optional management pack licenses. Budget for both Aria Operations and relevant management packs.

REST API & Custom Metrics

Aria REST API - Query Metrics Example:

GET /api/v3/metrics?resourceKind=VirtualMachine&metricName=cpu|usage_average
    &begin=1514764800000&end=1514851200000&limit=1000
    &_include=latest

Response (JSON):

• {
• "totalRecords": 500,
• "pageSize": 1000,
• "page": 1,
• "resourceMetrics": [
• {
• "resource": {
• "resourceId": "vm-123",
• "resourceName": "prod-web-01",
• "resourceKind": "VirtualMachine",
• "resourceHealthy": true
• },
• "metricValues": [
• {
• "metricId": {
• "metricName": "cpu|usage_average",
• "aggregationType": "average",
• "resourceCounterId": 1
• },
• "dataPoints": [
• { "timestamp": 1514764800000, "value": 45.2 },
• { "timestamp": 1514764920000, "value": 48.5 }
• ]
• }
• ]
• }
• ]
• }

Usage: Export custom reports, integrate with ELK stack for advanced analytics,
feed data to ML platforms for anomaly detection

Custom Metrics via Telegraf Agent:

Aria includes Telegraf agent for collecting custom application metrics.

Telegraf Configuration Example:

• [[inputs.http]]
• urls = ["http://app-server:8080/metrics"]
• headers = {"Authorization" = "Bearer token123"}
• tagpass = {"job" = ["web-app"]}

• [[processors.rename]]
• [[processors.rename.replace]]
• dest = "business|order_count"
• src = "orders_total"

• [[outputs.aria]]
• server = "analytics-cluster-master"
• interval = "30s"

// Telegraf sends custom metric "business|order_count" to Aria every 30 seconds
// This metric can then be used in super metrics and alerts

Custom Metrics Use Case:

Application team wants to alert on "critical business metric" (e.g., order processing latency > 2 seconds). Application exposes /metrics endpoint with order_processing_latency_ms. Configure Telegraf → Aria receives custom metric → Create super metric aggregating latency by region → Alert when latency > 2000ms.

Log Insight & Aria Automation Integration

vRealize Log Insight Integration:
Aria can ingest log data from Log Insight for correlation with metrics. Use case: When cpu|usage_percent spikes, automatically query Log Insight for error/exception logs during same time window to identify root cause.

Integration Pattern:

1. Alert fires in Aria: "CPU usage > 80% for 5 minutes" on prod-db-01
2. Aria queries Log Insight API:

   GET /api/v1/search?query=hostname:prod-db-01 AND (ERROR OR exception)
       &start_time=(now - 10 minutes)&limit=50
3. Log Insight returns top 10 errors: "Connection pool exhausted", "Lock timeout"

4. Aria enriches alert payload with log context
5. Notification to ops: "CPU spike on prod-db-01. Recent errors: 'Connection pool exhausted' (423 occurrences)"
6. Ops team can immediately identify app-layer issue vs. infrastructure issue

vRealize Automation Integration:
Aria can trigger Aria Automation workflows based on operational decisions.

Remediation workflows:

When disk space low, trigger workflow to increase volume size, take snapshots, or migrate VM

Provisioning workflows:

When cluster capacity < 10%, trigger workflow to provision new hosts or enable overcommit policies

Scaling workflows:

When application demand increases, trigger workflow to scale-out VMs (if stateless) or provision additional cluster resources

Key Takeaways

• Exam Focus:Understand adapter licensing. Each management pack (vSAN, NSX, HCX, vendor-specific) may require separate licensing. VCF Operations Suite includes base Aria Operations license + optional management pack licenses. Budget for both Aria Operations and relevant management packs.

Transition to VCF Operations 9.0#

VMware VCF 9.0 consolidates standalone Aria Operations into VCF Operations Manager, offering unified management across multi-cloud infrastructure.

Key Changes from Aria Operations 8.x to VCF Operations 9.0:

Unified interface:

Single pane of glass for vSphere, NSX, vSAN, VCF lifecycle, cloud infrastructure

Fleet-level operations:

Manage multiple SDDC instances (clusters) as single fleet; compare metrics across SDDCs

VCF lifecycle integration:

Monitor bundle updates, patch status, firmware compliance across fleet

Enhanced dashboards:

Fleet-level capacity, compliance, cost dashboards built into VCF Operations

Aria Automation integration:

Tighter coupling with service provisioning; auto-remediate via VCF APIs

Licensing model:

Subscription-based (per SDDC, per capacity tier); includes management packs in base license

Migration Path:

Aria Operations 8.x users should plan transition by VCF 9.0 launch. Aria Operations will enter maintenance support phase; no new features after 9.0 GA.

Custom adapters, super metrics, and alert definitions developed for Aria Operations 8.x require testing on VCF Operations 9.0. API compatibility is maintained but payload structures may change. Plan 2-4 week testing phase before production migration.

• 📄 Aria Operations 8.x Release Notes
• 📄 Aria Operations Administrator Guide
• 📄 VCF Operations 9.0 Release Notes
• 📄 Capacity Analytics & Planning

Adapter Framework and Management Packs#

Adapter-Kinds Taxonomy and Management Pack Installation

VCF Operations (evolved from Aria Operations 8.x) uses adapters to collect telemetry from heterogeneous infrastructure. Each adapter speaks the native API of its target system (vSphere API, NSX API, vSAN API, Kubernetes API, AWS CloudWatch, etc.) and translates metrics to Aria format.

Advanced Symptoms and Alert Engineering#

Hard Threshold vs Soft Threshold vs Dynamic Threshold

Aria Operations supports three threshold modes for detecting anomalies:

Composite Alerts (All-Of / Any-Of Boolean Logic)

Composite alert combines symptoms with AND/OR logic. Example: alert = (CPU > 80 AND Memory > 75) OR (Disk IO > 1000 IOPS). All-of: all conditions true = alert fires (strict, fewer false positives). Any-of: any condition true = alert fires (sensitive, catches issues early). Most alerts use OR (any symptom = issue) for fast detection.

Super Metrics Cookbook: Common Recipes#

Super Metric Formula Examples

Super metrics are calculated from base metrics (CPU, memory, I/O). Formulas use Aria DSL (define variables, apply functions, return result).

Super Metric 1: Cluster Free CPU (GHz)

name: cluster_free_cpu_ghz
formula:
  cpuCapacity = sum(resource|cpu_capacity_MHz, cluster) / 1000  # in GHz

• cpuUsed = sum(metric|cpu_usagemhz_average, cluster) / 1000 # in GHz
• cpuFree = cpuCapacity - cpuUsed
• return cpuFree

Super Metric 2: Datastore ROI Cost per IOPS

name: datastore_cost_per_iops
formula:
  iops = metric|datastore_iops  # total IOPS in past hour

• capexPerGB = 5 # assumption: datastore costs 5 USD per GB capacity
• datastoreCapacityGB = resource|datastore_capacity_gb
• annualCost = datastoreCapacityGB * capexPerGB / 3 # 3-year amortization
• costPerIops = annualCost / 365 / 24 / (iops + 1) # avoid div by zero
• return costPerIops

Super Metric 3: Host NIC Utilization Weighted by vNIC Count

name: host_nic_util_weighted
formula:
  nicUtil = metric|nic_throughput_kilobytespersec  # KBps on NIC

• vnicCount = sum(resource|vnic_count, host) # total vNICs on host
• utilizationPerVnic = nicUtil / (vnicCount + 1) # per-vNIC utilization
• return utilizationPerVnic

Super Metric 4: VM Right-Sizing Score (Demand vs Entitled)

name: vm_rightsizing_score
formula:
  cpuDemand = metric|cpu_demandmhz_average  # actual CPU needed

cpuEntitled = resource|cpu_entitlements_mhz # allocated CPU
cpuUtilization = cpuDemand / (cpuEntitled + 1) # avoid div by zero

• memDemand = metric|memory_guest_mb # actual memory used
• memEntitled = resource|memory_entitlements_mb # allocated memory
• memUtilization = memDemand / (memEntitled + 1)

Score: 100 = perfectly sized, < 25 = over-provisioned, > 90 = under-provisioned

• avgUtil = (cpuUtilization + memUtilization) / 2
• if (avgUtil > 0.9) { return 25 } # under-provisioned, needs upgrade
• else if (avgUtil < 0.25) { return 75 } # over-provisioned, can downsize
• else { return 50 } # well-sized

Super Metric 5: Stretched Cluster Site Balance (pod count bias)

name: stretched_cluster_site_balance
formula:
  podsSite1 = sum(resource|pod_count, cluster, zone=site-1)
  podsSite2 = sum(resource|pod_count, cluster, zone=site-2)
  totalPods = podsSite1 + podsSite2

balanceFactor = podsSite1 / (totalPods + 1)

return 0-1: 0.5 = perfectly balanced, 0.1 = heavily biased to site2

return balanceFactor

Policy and Profile Assignment Best Practices

Policies determine which symptoms/alerts/capacity thresholds apply to which objects. Hierarchy: Base Policy (default) + Environment-specific overlay + App-specific overlay.

Default Policy vs Custom Policy

Default Policy: applied to all objects of kind (e.g., all VMs). Custom Policy: applied to subset (e.g., only prod VMs). Override: custom policy overrides default for matching objects. Example: prod VMs get stricter threshold (CPU > 70 percent alert), dev VMs get relaxed threshold (CPU > 90 percent alert).

Policy Inheritance and Hierarchies

Base Policy (cluster level) + Environment overlay (prod/dev) + App overlay (tier-1/tier-2). Symptom matches: tier-2 policy overrides app policy, app overrides environment, environment overrides base. Order matters: more specific policies override general. Test inheritance: apply policy, verify symptoms on test VM (matches expected policy).

Policy Drift Detection

Aria tracking: audit log shows policy changes (who modified, when, old vs new). Alert: if policy drifted from expected version (e.g., someone accidentally set CPU threshold to 99 percent), trigger "policy drift" alert. Remediation: approve drift or revert to standard. Quarterly policy audit: verify all policies align with standards.

Policy Versioning

Maintain policy version (v1.0 = baseline, v1.1 = added CPU monitoring, v2.0 = new company standards). On update, create new version, don't modify existing (immutability). Existing objects on v1.0 continue running v1.0 until explicitly migrated to v2.0. Gradual migration reduces risk (test v2.0 on canary group first).