Orchestrator Health Monitoring

Monitoring Orchestrator health involves both Orchestrator KPIs exposed via the API and OS-level resource monitoring of the VM running Orchestrator. This page outlines both approaches and when to use each.

When to Use What

Orchestrator APIs (recommended for app health):
Use /gms/rest/gmsserver/ping for reachability health and /gms/rest/stats/timeseries/metrics for heap/memory stats and trend analysis.
OS/Hypervisor Monitoring (for VM resources):
- Monitor CPU, memory, swap, and disk from your hypervisor or your standard Linux monitoring stack. Orchestrator also raises disk-usage alarms at 70% (Warning) and >90% (Major).
SNMP on the Orchestrator VM (optional):
- if your NMS standardizes on SNMP for OS metrics, you can enable snmpd in the Orchestrator's underlying Linux to poll CPU/memory/disk. Read the supportability notes below first.

Supportability & Security Notes

Aruba docs primarily recommend API-based monitoring for Orchestrator and Linux/hypervisor tools for VM resources; enabling extra OS packages is outside the standard product configuration and may be overwritten by upgrades or conflict with hardening baselines. Validate with your Ops/Security policy before enabling.
If you enable SNMP, use SNMPv3 wherever possible. Appliance-side SNMP features (for ECOS gateways) are documented separately and are the same as enabling snmpd on the Orchestrator VM.

Orchestrator Health & Reachability (API)

Reachability & DB health: GET /gms/rest/gmsserver/ping
1. 200 --> Orchestrator OK; watch latency trends (hundreds of ms typical)
2. Fields include dbHealth (database link) and uptime.
Reboot history (last 12 months): GET /gms/rest/gms/rebootHistory
Heap/memory trends (hour/minute granularity): GET /gms/rest/stats/timeseries/metrics?startTime=&endTime= --> monitor totalHeapMemory and usedHeapMemory.

Orchestrator VM Disk Space & Linux Tools

Orchestrator raises disk alarms: 70% Warning and >90% Major.
For CPU/mem/swap/disk, standard Linux tools (e.g., top, free, df) or your hypervisor monitoring are recommended.
For VM deployments, reserve CPU & memory for the VM.

SNMP on the Orchestrator OS (optional)

This section describes how to enable the Linux snmpd service on on-prem Orchestrator hosts for OS-level polling (CPU, memory, disk). This does not configure SNMP for EdgeConnect appliances (that is done in the Orchestrator UI/templates and is documented separately).

Prerequisites

Outbound access to fetch packages (or local repo).
Firewall allowance for UDP/161 from your NMS to the Orchestrator VM.
Security approval to install and run snmpd on the host OS.

SNMPv2C - Example enable script

Use in isolated/lab environments; prefer SNMPv3 in production,

#
# Setup Web Proxy for DNF Install of SNMPd (optional)
#
echo "proxy=<WEB_PROXY>:80" >> /etc/dnf/dnf.conf

#
# Install SNMPd
#
dnf install -y net-snmp net-snmp-libs net-snmp-utils

#
# Basic SNMPd Configuration (SNMPv2c - read-only)
#
cp -p /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.$(date +"%Y%m%d_%H%M%S")
cat >/etc/snmp/snmpd.conf <<'EOF'
rocommunity  <SNMPV2C_RO_COMMUNITY>  <NMS_SOURCE_SUBNET/CIDR>
syslocation  <DC/Cloud/Room-Rack>
syscontact   <[email protected]>
# Expose standard system and host resources MIBs
view   systemview  included   .1.3.6.1.2.1.1
view   systemview  included   .1.3.6.1.2.1.25
# (optional) Limit to specific OIDs to reduce exposure.
EOF

#
# Start and Enable SNMPd
#
systemctl enable --now snmpd

#
# Open firewall for SNMP
#
firewall-cmd --zone=public --add-service=snmp --permanent
firewall-cmd --reload

SNMPv3 - recommended hardend config

# Install packages as above, then:
cp -p /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.$(date +"%Y%m%d_%H%M%S")

# Create an authPriv user and restrict access to your NMS subnet
net-snmp-config --create-snmpv3-user -ro -a <AUTH_PASS> -x <PRIV_PASS> -A SHA -X AES <SNMPV3_USER>

cat >/etc/snmp/snmpd.conf <<'EOF'
# Restrict to local + NMS subnet and expose common host metrics
agentAddress udp:161
rouser <SNMPV3_USER> authPriv
# (optional) tighten views
view   restricted  included .1.3.6.1.2.1.1
view   restricted  included .1.3.6.1.2.1.25
access notConfigGroup "" any noauth exact restricted none none
syslocation  <DC/Cloud/Room-Rack>
syscontact   <[email protected]>
EOF

systemctl restart snmpd
firewall-cmd --zone=public --add-service=snmp --permanent
firewall-cmd --reload

Verify

# From NMS/jump host
snmpget -v3 -l authPriv -u <SNMPV3_USER> -a SHA -A <AUTH_PASS> -x AES -X <PRIV_PASS> <ORCH_HOST> 1.3.6.1.2.1.1.3.0   # sysUpTime
snmpwalk -v3 -l authPriv -u <SNMPV3_USER> -a SHA -A <AUTH_PASS> -x AES -X <PRIV_PASS> <ORCH_HOST> 1.3.6.1.2.1.25.2.3.1 # hrStorageTable

What to Monitor (Common OIDs)

Uptime: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)
CPU: 1.3.6.1.4.1.2021.11 (UCD-SNMP-MIB CPU stats)
Memory: 1.3.6.1.2.1.25.2.2.0 (hrMemorySize), 1.3.6.1.4.1.2021.4 (memAvail,memTotal)
Disk/FS: 1.3.6.1.2.1.25.2.3 (hrStorageTable)

If your tooling supports Orchestrator/ECOS natively via API or Notification Service, prefer those for SD-WAN alarms/telemetry and reserve SNMP here for OS metrics only.

Examples: API Requests

Reachability/DB Health

GET /gms/rest/gmsserver/ping

Example response:

{
  "hostname":"orchestrator.localdomain",
  "dbHeatlh": true,
  "timeStr": "Thu Jan 30 16:51:31 PDT 2020",
  "time": 1580429731303,
  "message": "I am alive!",
  "version": "9.3.1.40717",
    "uptime": "9d 2h 52m 39s"

Heap/memory trend

GET /gms/rest/stats/timeseries/metrics?startTime=<EPOC_SEC>&endTime=<EPOC_SEC>

Monitor totalHeapMemory and usedHeapMemory.

Example response:

[{
   "stats": {
   "buffersMemory": 2704,
   "usedMemory": 124163080,
   "totalMemory": 387740160,
   "applianceCount": 74,
   "usedSwapMemory": 0,
   "freeSwapMemory": 0,
   "totalHeapMemory": 1933049856,
   "usedHeapMemory": 1052471048,
   "totalSwapMemory": 0,
   "cachedSwapMemory": 77150288,
   "freeMemory": 263577080
 },
    "key": null,
    "timestamp": 1580407637
     },
                              …
                              ]