Monitoring OpenDaylight with Vigilmon

OpenDaylight (ODL) is an open source Software-Defined Networking (SDN) controller platform hosted by the Linux Foundation — founded in 2013 by a consortium including Cisco, IBM, Red Hat, Ericsson, Juniper Networks, and Microsoft to provide a vendor-neutral SDN controller. When you run OpenDaylight, you own the control plane for your entire network: the Karaf OSGi runtime programs switches and routers via OpenFlow, NETCONF, and OVSDB southbound protocols, while northbound REST APIs expose the topology to your applications. If OpenDaylight goes down, the SDN control plane goes dark — your network may keep forwarding based on cached flows, but no new programming happens and no topology changes are reflected. Vigilmon gives you proactive alerting across every critical OpenDaylight health dimension before your network starts misbehaving.

What You'll Set Up

• OpenDaylight Karaf process health via HTTP management API monitor
• MD-SAL data store transaction health check
• OpenFlow switch connectivity count monitor
• NETCONF device session health check
• Northbound REST API latency and availability monitor
• ODL cluster synchronization health (for clustered deployments)
• JVM heap and GC health via cron heartbeat
• Flow programming success rate monitor
• Alert channels with appropriate thresholds

Prerequisites

• OpenDaylight installed and running (Karaf-based distribution, any recent release)
• OpenDaylight management API accessible (default: port 8181 for HTTPS, port 8080 for HTTP)
• RESTCONF API enabled (the odl-restconf feature installed in Karaf)
• A free Vigilmon account

Step 1: Monitor the OpenDaylight Karaf Management API

OpenDaylight runs on Apache Karaf and exposes a management REST API. This is the primary health signal — if it stops responding, the SDN controller is down.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. URL: http://your-odl-host:8080/restconf/operational/network-topology:network-topology/ (or https://your-odl-host:8181/restconf/operational/network-topology:network-topology/).
4. Set Method to GET.
5. Under Basic Auth, enter your ODL credentials (default: admin / admin — change these in production).
6. Set Expected HTTP status to 200.
7. Set Check interval to 1 minute.
8. Under Keyword check, enter network-topology to verify the RESTCONF response body, not just that the port is open.
9. Click Save.

This single monitor catches ODL controller crashes, Karaf startup failures, and RESTCONF bundle failures in one probe.

Step 2: Monitor OpenFlow Switch Connectivity

OpenDaylight manages OpenFlow-enabled switches. The number of connected OpenFlow devices is a critical operational metric — a drop means switches are disconnecting from SDN control.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-odl-host:8080/restconf/operational/opendaylight-inventory:nodes/
3. Method: GET
4. Basic Auth: ODL credentials
5. Expected HTTP status: 200
6. Under Keyword check, enter openflow to verify OpenFlow nodes are present in the response.
7. Check interval: 2 minutes
8. Click Save.

This check alerts you when OpenFlow switches disconnect from the controller — for example after a network partition, switch reboot, or ODL restart that didn't recover all connections.

Set up a second monitor for the OpenFlow southbound port:

1. Click Add Monitor → TCP Port.
2. Host: your-odl-host
3. Port: 6633 (OpenFlow 1.0) or 6653 (OpenFlow 1.3, the standard port)
4. Check interval: 1 minute
5. Click Save.

Switches connect to ODL on these ports. If the TCP port stops accepting connections, no new OpenFlow sessions can form.

Step 3: Monitor NETCONF Device Connectivity

If you manage network devices via NETCONF (routers, YANG-model capable switches), monitor the NETCONF topology to detect session drops.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-odl-host:8080/restconf/operational/network-topology:network-topology/topology/topology-netconf/
3. Method: GET
4. Basic Auth: ODL credentials
5. Expected HTTP status: 200
6. Under Keyword check, enter connected to verify at least one NETCONF node shows as connected.
7. Check interval: 3 minutes
8. Click Save.

Step 4: Monitor the Northbound REST API Response Time

Applications use OpenDaylight's northbound REST API to program the network. Latency spikes on this API indicate MD-SAL data store pressure or JVM GC pauses.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-odl-host:8080/restconf/operational/ietf-interfaces:interfaces/
3. Method: GET
4. Basic Auth: ODL credentials
5. Expected HTTP status: 200
6. Check interval: 1 minute
7. Under Response time alert, set the threshold to 2000ms — REST API responses taking more than 2 seconds indicate data store or JVM issues.
8. Click Save.

Step 5: Monitor ODL Clustering Health (Clustered Deployments)

If you run an OpenDaylight cluster (typically three nodes using Akka Raft consensus), monitor each node's cluster membership API to detect split-brain conditions.

On each ODL cluster node, add a monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://odl-node-1:8080/restconf/operational/entity-owners:entity-owners/ (repeat for each node IP)
3. Method: GET
4. Basic Auth: ODL credentials
5. Expected HTTP status: 200
6. Check interval: 2 minutes
7. Click Save.

For the Akka cluster status endpoint (if your ODL distribution exposes it):

1. URL: http://odl-node-1:8558/cluster/members
2. Expected HTTP status: 200
3. Under Keyword check, enter Up to verify cluster members are reachable.
4. Check interval: 2 minutes

A leader election failure causes one or more nodes to stop serving write requests — catching this early prevents network programming outages.

Step 6: Monitor the OVSDB Southbound (Open vSwitch Integration)

If OpenDaylight manages Open vSwitch instances via OVSDB, monitor the OVSDB topology:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-odl-host:8080/restconf/operational/network-topology:network-topology/topology/ovsdb:1/
3. Method: GET
4. Basic Auth: ODL credentials
5. Expected HTTP status: 200
6. Check interval: 3 minutes
7. Click Save.

Also monitor the OVSDB passive listening port on ODL:

1. Click Add Monitor → TCP Port.
2. Host: your-odl-host
3. Port: 6640 (OVSDB passive mode)
4. Check interval: 1 minute
5. Click Save.

Step 7: Monitor BGP Topology Health

If you use OpenDaylight for BGP-LS topology collection (common in WAN SDN deployments), monitor the BGP RIB:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-odl-host:8080/restconf/operational/bgp-rib:bgp-rib/
3. Method: GET
4. Basic Auth: ODL credentials
5. Expected HTTP status: 200
6. Under Keyword check, enter peer to verify BGP peers are present.
7. Check interval: 5 minutes
8. Click Save.

Step 8: Monitor OpenDaylight JVM Heap via Cron Heartbeat

OpenDaylight's Karaf JVM heap usage is a leading indicator of GC pressure and eventual out-of-memory crashes. Use a cron heartbeat with a local monitoring script.

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected interval to 5 minutes.
3. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).
4. On your ODL server, create a monitoring script:

#!/bin/bash
# /usr/local/bin/odl-heap-check.sh

ODL_URL="http://localhost:8080"
ODL_CREDS="admin:admin"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
HEAP_THRESHOLD=85

# Get JVM stats via Jolokia if available, or use Karaf console
HEAP_USED=$(curl -s -u "$ODL_CREDS" \
  "$ODL_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_USED" ]; then
  # Jolokia not available — fall back to process check
  pgrep -f "karaf" > /dev/null && curl -sf "$HEARTBEAT_URL" > /dev/null
  exit 0
fi

if [ "$HEAP_USED" -lt "$HEAP_THRESHOLD" ]; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
# Above threshold: don't ping — Vigilmon alerts on missed heartbeat

chmod +x /usr/local/bin/odl-heap-check.sh

5. Add to crontab:

*/5 * * * * /usr/local/bin/odl-heap-check.sh

When heap exceeds 85%, the script stops pinging and Vigilmon alerts you — before the JVM runs out of memory and crashes ODL.

Step 9: Configure Alert Channels and Thresholds

1. Go to Alert Channels in Vigilmon and add Slack, email, or PagerDuty.
2. For the primary Karaf management API monitor, set Consecutive failures before alert to 2 — a single probe failure during ODL's Karaf startup window shouldn't page you.
3. For OpenFlow TCP port monitors, set Consecutive failures to 1 — loss of the OpenFlow listening port is immediately critical.
4. For NETCONF and cluster health monitors, set Consecutive failures to 2.
5. For the JVM heap heartbeat, Vigilmon alerts automatically after the 5-minute window passes without a ping.
6. Enable Recovery notifications on all monitors so you know when ODL reconnects after a restart.

Step 10: Test Your Alert Pipeline

Before going live, trigger a test alert to confirm your notification channels work:

1. In Vigilmon, open any monitor and click Pause — this simulates a monitor going into alert state.
2. Verify you receive a notification via your configured channel (Slack, email, etc.).
3. Click Resume and verify the recovery notification arrives.

For a more realistic test, temporarily change a monitor's URL to an invalid endpoint, wait for two consecutive failures, then fix it.

Conclusion

You now have complete observability across OpenDaylight's control plane: the Karaf management API confirms the controller is running, OpenFlow and NETCONF topology endpoints track device connectivity, the northbound REST API monitor catches programming latency spikes, and cluster health monitors detect split-brain conditions before they cause network programming outages. The JVM heap heartbeat gives you early warning of memory pressure before an out-of-memory crash takes down the SDN controller.

For more self-hosted infrastructure monitoring guides, see vigilmon.online.