ONOS (Open Network Operating System) is an open source SDN network operating system developed by the Open Networking Foundation (ONF) and launched in 2014, purpose-built for carrier-grade, high-availability deployments. Unlike traditional network management, ONOS expresses network behavior through intents — your application says "connect host A to host B" and ONOS compiles that intent into OpenFlow or P4Runtime rules across the fabric. ONOS runs as a distributed cluster using Apache Atomix (Raft consensus) for coordination, and it's used in production by AT&T, SK Telecom, NTT, and China Unicom. When ONOS degrades — an Atomix leader election stalls, an intent gets stuck in FAILED state, or cluster membership drops below quorum — your SDN fabric stops responding to network events. Vigilmon gives you proactive visibility into every layer of the ONOS stack before your carrier network feels the impact.
What You'll Set Up
- ONOS HTTP management API uptime monitor
- Cluster node membership and quorum health check
- Device connectivity count monitor (OpenFlow / P4Runtime)
- Intent compilation health monitor (pending and failed intents)
- Atomix distributed store leader health check
- Northbound REST API latency monitor
- Segment routing fabric health check
- ONOS JVM heap cron heartbeat
- Alert channels with appropriate thresholds
Prerequisites
- ONOS running as a single node or cluster (Karaf-based, ONOS 2.x or later)
- ONOS REST API accessible (default port: 8181)
onosCLI or REST credentials available- A free Vigilmon account
Step 1: Monitor the ONOS Management API
The ONOS REST API is the primary signal for controller health. If it stops responding, ONOS is down and your SDN fabric is running blind.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - URL:
http://your-onos-host:8181/onos/v1/info - Set Method to
GET. - Under Basic Auth, enter
onos/rocks(the default credentials — change these in production). - Set Expected HTTP status to
200. - Set Check interval to
1 minute. - Under Keyword check, enter
versionto confirm the ONOS info response body is present. - Click Save.
This catches ONOS crashes, Karaf startup failures, and REST API bundle failures.
Step 2: Monitor Cluster Node Membership
ONOS is designed as a distributed system — losing nodes below quorum causes write failures across the cluster. Monitor the cluster membership endpoint to detect node departures.
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:8181/onos/v1/cluster - Method:
GET - Basic Auth: ONOS credentials
- Expected HTTP status:
200 - Under Keyword check, enter
READYto verify at least one node reports as ready. - Check interval:
2 minutes - Click Save.
For a three-node ONOS cluster, you need at least two nodes READY for quorum. Add this monitor on each ONOS node IP so you catch per-node failures:
http://onos-node-1:8181/onos/v1/clusterhttp://onos-node-2:8181/onos/v1/clusterhttp://onos-node-3:8181/onos/v1/cluster
Step 3: Monitor Device Connectivity
ONOS manages OpenFlow switches, P4Runtime devices, and NETCONF devices. The device count dropping signals switches disconnecting from SDN control.
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:8181/onos/v1/devices - Method:
GET - Basic Auth: ONOS credentials
- Expected HTTP status:
200 - Under Keyword check, enter
AVAILABLEto verify at least one device shows as available. - Check interval:
2 minutes - Click Save.
Also monitor the OpenFlow southbound listening port:
- Click Add Monitor → TCP Port.
- Host:
your-onos-host - Port:
6653(OpenFlow 1.3) - Check interval:
1 minute - Click Save.
Step 4: Monitor Intent Compilation Health
Intents are the core of ONOS's northbound model. When intents get stuck in INSTALLING or FAILED state, connectivity requirements from your applications are not being realized as flow rules.
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:8181/onos/v1/intents - Method:
GET - Basic Auth: ONOS credentials
- Expected HTTP status:
200 - Under Keyword check, enter
INSTALLEDto verify intents are compiling successfully. - Check interval:
3 minutes - Click Save.
For deeper intent monitoring, use a cron heartbeat script that counts FAILED intents:
- Click Add Monitor → Cron Heartbeat.
- Set expected interval to
5 minutes. - Copy the heartbeat URL.
- On your ONOS server, create a script:
#!/bin/bash
# /usr/local/bin/onos-intent-check.sh
ONOS_URL="http://localhost:8181"
ONOS_CREDS="onos:rocks"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-intent-heartbeat-id"
MAX_FAILED=5
FAILED_COUNT=$(curl -sf -u "$ONOS_CREDS" \
"$ONOS_URL/onos/v1/intents" \
| python3 -c "
import sys, json
data = json.load(sys.stdin)
intents = data.get('intents', [])
failed = sum(1 for i in intents if i.get('state') in ['FAILED', 'INSTALL_REQ'])
print(failed)
" 2>/dev/null)
if [ -z "$FAILED_COUNT" ] || [ "$FAILED_COUNT" -le "$MAX_FAILED" ]; then
curl -sf "$HEARTBEAT_URL" > /dev/null
fi
# More than MAX_FAILED intents stuck: don't ping — Vigilmon alerts
chmod +x /usr/local/bin/onos-intent-check.sh
Add to crontab:
*/5 * * * * /usr/local/bin/onos-intent-check.sh
Step 5: Monitor Atomix Distributed Store Health
ONOS uses Apache Atomix for distributed state replication. If the Atomix leader is unreachable or Raft log replication lags, cluster writes fail.
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:5678/v1/primitives(Atomix REST API, if enabled) - Method:
GET - Expected HTTP status:
200 - Check interval:
2 minutes - Click Save.
For Atomix management port availability:
- Click Add Monitor → TCP Port.
- Host:
your-onos-host - Port:
5679(Atomix cluster communication port) - Check interval:
1 minute - Click Save.
Step 6: Monitor the Topology and Links
ONOS maintains a real-time topology model. Monitoring the topology endpoint confirms that ONOS is processing link events and maintaining an accurate network view.
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:8181/onos/v1/topology - Method:
GET - Basic Auth: ONOS credentials
- Expected HTTP status:
200 - Under Keyword check, enter
devicesto verify topology data is present. - Check interval:
2 minutes - Click Save.
Also monitor the links endpoint to detect link topology loss:
- URL:
http://your-onos-host:8181/onos/v1/links - Expected HTTP status:
200 - Check interval:
3 minutes - Click Save.
Step 7: Monitor Segment Routing Fabric Health
If you use ONOS with the Trellis segment routing application (leaf-spine fabric), monitor the route programming endpoint:
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:8181/onos/v1/routes - Method:
GET - Basic Auth: ONOS credentials
- Expected HTTP status:
200 - Under Keyword check, enter
prefixto verify route prefixes are present. - Check interval:
5 minutes - Click Save.
For ECMP group health in a Trellis fabric:
- URL:
http://your-onos-host:8181/onos/v1/groups - Expected HTTP status:
200 - Under Keyword check, enter
SELECTto verify ECMP select groups exist. - Check interval:
5 minutes - Click Save.
Step 8: Monitor P4Runtime Device Programming
If you use ONOS with P4Runtime-enabled devices (Barefoot Tofino, BMv2 software switches), monitor the pipeline push health:
- Click Add Monitor → HTTP / HTTPS.
- URL:
http://your-onos-host:8181/onos/v1/devices(filter for P4Runtime devices) - Method:
GET - Basic Auth: ONOS credentials
- Expected HTTP status:
200 - Under Keyword check, enter
p4runtimeto verify P4Runtime devices are listed. - Check interval:
5 minutes - Click Save.
Step 9: Monitor ONOS JVM Heap via Cron Heartbeat
Like OpenDaylight, ONOS runs on a Karaf JVM and is susceptible to heap exhaustion under heavy topology event loads.
- Click Add Monitor → Cron Heartbeat.
- Set expected interval to
5 minutes. - Copy the heartbeat URL.
- Create a monitoring script on your ONOS server:
#!/bin/bash
# /usr/local/bin/onos-heap-check.sh
ONOS_URL="http://localhost:8181"
ONOS_CREDS="onos:rocks"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-heap-heartbeat-id"
HEAP_THRESHOLD=85
# Check ONOS is responding first
HTTP_STATUS=$(curl -sf -o /dev/null -w "%{http_code}" \
-u "$ONOS_CREDS" "$ONOS_URL/onos/v1/info")
if [ "$HTTP_STATUS" != "200" ]; then
# ONOS is not responding — don't ping heartbeat
exit 0
fi
# Check heap via JMX/Jolokia if available
HEAP_PCT=$(curl -sf -u "$ONOS_CREDS" \
"$ONOS_URL/jolokia/read/java.lang:type=Memory/HeapMemoryUsage" \
| python3 -c "
import sys, json
d = json.load(sys.stdin)
used = d['value']['used']
mx = d['value']['max']
print(int(used * 100 / mx))
" 2>/dev/null)
if [ -z "$HEAP_PCT" ] || [ "$HEAP_PCT" -lt "$HEAP_THRESHOLD" ]; then
curl -sf "$HEARTBEAT_URL" > /dev/null
fi
chmod +x /usr/local/bin/onos-heap-check.sh
Add to crontab:
*/5 * * * * /usr/local/bin/onos-heap-check.sh
Step 10: Configure Alert Channels and Thresholds
- Go to Alert Channels in Vigilmon and configure Slack, email, or PagerDuty.
- For the ONOS management API monitor, set Consecutive failures before alert to
2— ONOS cluster leader re-election can cause brief HTTP unavailability. - For cluster membership monitors, set Consecutive failures to
1— node departure from quorum is immediately critical. - For device connectivity and intent monitors, set Consecutive failures to
2. - For OpenFlow TCP port and Atomix TCP monitors, set Consecutive failures to
1. - For JVM heap and intent health heartbeats, Vigilmon alerts automatically after the expected window passes.
- Enable Recovery notifications on all monitors.
Conclusion
You now have comprehensive monitoring across ONOS's distributed control plane: the management API confirms the controller is running, cluster membership monitors catch quorum loss before it causes write failures, device connectivity and intent monitors detect fabric programming issues, and Atomix store health checks guard against distributed coordination failures. The JVM heap heartbeat gives early warning before memory pressure crashes the carrier-grade controller. For more self-hosted infrastructure monitoring guides, see vigilmon.online.