Monitoring EdgeX Foundry with Vigilmon

EdgeX Foundry is a vendor-neutral, open source IoT edge platform under the Linux Foundation Edge umbrella. It connects field devices — sensors, PLCs, barcode scanners, ONVIF cameras — to cloud platforms and IT systems using a layered microservices architecture deployed as Docker containers. Because EdgeX is a collection of independent services communicating over Redis Streams, any single service failure silently breaks the data pipeline: device readings stop flowing, commands stop reaching devices, or cloud exports go dark. Vigilmon gives you end-to-end visibility across every service in the EdgeX stack.

What You'll Set Up

• Core data service health monitor (sensor reading ingestion)
• Core metadata service health monitor (device registry)
• Redis message bus health monitor
• Per-protocol device service monitors (Modbus, MQTT, REST, BACnet)
• Device reading ingestion rate heartbeat
• Application service export health monitors (AWS IoT, Azure, MQTT)
• Alert/notification service health monitor
• Core command service health monitor
• EdgeX container restart detection
• Reading ingestion latency heartbeat

Prerequisites

• EdgeX Foundry deployed via Docker Compose or Kubernetes (Helm chart)
• EdgeX management API accessible (default port 59880 for core data, 59881 for core metadata)
• Redis accessible on port 6379 (or the port configured in your EdgeX compose file)
• A free Vigilmon account

Step 1: Monitor the Core Data Service

The EdgeX core data service is the central ingestion point for all sensor readings. Every device service pushes readings to core data via the message bus, and applications consume from core data. If core data goes down, sensor readings stop being stored and the entire EdgeX data pipeline stalls.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. URL: http://your-edgex-host:59880/api/v3/ping.
4. Expected HTTP status: 200.
5. Keyword check: enter pong to verify the service is actually responding, not just that a port is open.
6. Check interval: 1 minute.
7. Set Alert after: 1 failure — core data is critical; any outage stops ingestion immediately.
8. Click Save.

EdgeX v3 exposes a standardized /api/v3/ping across all its services. You can also monitor the version endpoint for a richer health check:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59880/api/v3/version.
3. Keyword check: enter serviceName to verify the response JSON structure.
4. Check interval: 2 minutes.
5. Click Save.

Step 2: Monitor the Core Metadata Service

The core metadata service is the device registry — it stores device configurations, device profiles (schemas), and provisioning records. Device services query metadata on startup to get their configuration. If metadata goes down and a device service restarts, it can't load its device list and won't start correctly.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59881/api/v3/ping.
3. Expected HTTP status: 200.
4. Keyword check: pong.
5. Check interval: 1 minute.
6. Click Save.

Add a device count check to verify the registry is populated:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59881/api/v3/device/count.
3. Expected HTTP status: 200.
4. Keyword check: enter count to verify the JSON response contains device records.
5. Check interval: 5 minutes.
6. Click Save.

If the keyword check fails (e.g., the database backing metadata is empty or the service crashed), Vigilmon alerts you before device services fail on their next restart.

Step 3: Monitor the Redis Message Bus

EdgeX uses Redis Streams as its internal message bus for all inter-service communication. Device services publish readings to Redis Streams; core data and application services consume from those streams. Redis is the nervous system of EdgeX — if Redis becomes unavailable, all EdgeX service communication stops instantly.

Monitor the Redis TCP port:

1. Click Add Monitor → TCP Port.
2. Host: your-edgex-host, Port: 6379.
3. Check interval: 30 seconds.
4. Set Alert after: 1 failure.
5. Click Save.

Also add an HTTP check against the EdgeX system management agent (if deployed), which provides an aggregate health endpoint:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:58890/api/v3/ping.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

For a deeper Redis health check, add a heartbeat monitor driven by a cron job that runs a Redis PING:

#!/bin/bash
# Check Redis message bus health
RESULT=$(redis-cli -h your-edgex-host -p 6379 PING 2>/dev/null)
if [ "$RESULT" = "PONG" ]; then
  curl -fsS -m 10 "https://vigilmon.online/api/push/YOUR_REDIS_KEY" > /dev/null
fi

Schedule every minute in crontab:

* * * * * /opt/monitoring/edgex-redis-check.sh

Step 4: Monitor Device Services Per Protocol

Each EdgeX device service connects to a specific type of field device using a protocol-specific driver. A Modbus device service, for example, connects to PLCs over Modbus TCP; an MQTT device service subscribes to MQTT topics from MQTT-capable sensors. If a device service crashes, readings from all devices on that protocol stop flowing.

Monitor each device service's health endpoint:

Modbus device service (default port 59901):

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59901/api/v3/ping.
3. Expected HTTP status: 200.
4. Keyword check: pong.
5. Check interval: 1 minute.
6. Click Save.

MQTT device service (default port 59982):

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59982/api/v3/ping.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

REST device service (default port 59986):

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59986/api/v3/ping.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

Repeat for each device service in your deployment. Use Vigilmon's tag edgex-device-services to group them for easy filtering in the dashboard.

Step 5: Monitor Device Reading Ingestion Rate

The most direct signal of EdgeX health is whether sensor readings are actually flowing. A healthy EdgeX stack ingests a predictable number of readings per second depending on your device fleet. A drop to zero means devices disconnected, a device service crashed, or the message bus is broken.

Add a heartbeat monitor for your ingestion rate checker:

1. Click Add Monitor → Heartbeat / Cron.
2. Expected interval: 2 minutes.
3. Copy the heartbeat URL.
4. Click Save.

Create a reading rate check script that polls the core data /api/v3/reading/count endpoint and only sends the heartbeat if readings have been ingested recently:

#!/bin/bash
# Check that EdgeX is ingesting readings
COUNT=$(curl -s http://your-edgex-host:59880/api/v3/reading/count | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('count', 0))")

# Store last count for comparison
LAST_COUNT_FILE=/tmp/edgex_last_count
LAST=$(cat "$LAST_COUNT_FILE" 2>/dev/null || echo "0")

if [ "$COUNT" -gt "$LAST" ]; then
  # New readings have arrived
  curl -fsS -m 10 "https://vigilmon.online/api/push/YOUR_INGESTION_KEY" > /dev/null
fi

echo "$COUNT" > "$LAST_COUNT_FILE"

Schedule every 2 minutes. If the heartbeat misses, Vigilmon alerts you that readings have stopped flowing.

Step 6: Monitor Application Service Export Health

EdgeX application services consume readings from the message bus and export them to cloud platforms (AWS IoT Core, Azure IoT Hub, MQTT brokers, REST webhooks). Export failures cause silent data gaps in your cloud analytics — the edge keeps running but the cloud never receives the data.

Monitor each application service:

App service for AWS IoT export (default port 59700):

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59700/api/v3/ping.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

App service for Azure IoT Hub export (default port 59701):

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59701/api/v3/ping.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

Add export success rate monitoring via a heartbeat that queries app service metrics:

#!/bin/bash
# Check export pipeline — alert if export errors increasing
METRICS=$(curl -s http://your-edgex-host:59700/api/v3/metrics)
ERRORS=$(echo "$METRICS" | python3 -c \
  "import sys,json; m=json.load(sys.stdin); \
   metrics=m.get('metrics',{}); print(metrics.get('MessagesExportedErrors',{}).get('count',0))")

if [ "$ERRORS" -eq "0" ]; then
  curl -fsS -m 10 "https://vigilmon.online/api/push/YOUR_EXPORT_KEY" > /dev/null
fi

Step 7: Monitor the Alert and Notification Service

EdgeX's support services include an alerts/notifications service that sends threshold-based alerts on device readings (e.g., temperature > 80°C). If this service is down, you lose device-level alerting in EdgeX itself.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59860/api/v3/ping.
3. Expected HTTP status: 200.
4. Keyword check: pong.
5. Check interval: 2 minutes.
6. Click Save.

Step 8: Monitor the Core Command Service

The EdgeX core command service is the gateway for sending commands to field devices — for example, turning an actuator on/off or setting a PLC register. If command service is down, your automation and SCADA integrations lose the ability to control devices.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-edgex-host:59882/api/v3/ping.
3. Expected HTTP status: 200.
4. Check interval: 1 minute.
5. Click Save.

Step 9: Detect EdgeX Container Restarts

EdgeX runs as Docker containers. A container that crashes and restarts loses in-flight data and may leave the message bus in an inconsistent state. Detect repeated container restarts with a monitoring heartbeat:

#!/bin/bash
# Alert if any EdgeX container has restarted recently
RESTART_COUNT=$(docker inspect $(docker ps --filter "name=edgex" -q) \
  --format '{{.RestartCount}}' 2>/dev/null | awk '{sum+=$1} END{print sum+0}')

if [ "$RESTART_COUNT" -eq "0" ]; then
  curl -fsS -m 10 "https://vigilmon.online/api/push/YOUR_CONTAINER_KEY" > /dev/null
fi

Set the Vigilmon heartbeat interval to 5 minutes. Any EdgeX container restart suppresses the heartbeat and Vigilmon alerts you.

Step 10: Configure Alerting

Open Alert Channels in Vigilmon and configure notification routing:

Critical alerts (immediate, 24/7):

• Core data service down (all sensor ingestion stops)
• Redis TCP port unreachable (all EdgeX communication stops)
• Any device service down (readings from that protocol stop)

Warning alerts (business hours or on-call):

• Ingestion rate heartbeat missed (readings stopped flowing)
• Export heartbeat missed (cloud data gap starting)
• Container restart detected

Recommended thresholds:

• Core services: alert after 1 failure (no redundancy by default)
• Device services: alert after 2 consecutive failures
• Heartbeats: alert after 1 missed ping (interval × 1.5)

Set a 10-minute alert cooldown for device service monitors to avoid floods when a protocol source (e.g., an MQTT broker) has a brief outage affecting many device services simultaneously.

Summary: Your EdgeX Monitoring Stack

| Monitor | Type | What It Catches | |---|---|---| | Core data :59880/api/v3/ping | HTTP | Sensor reading ingestion failure | | Core metadata :59881/api/v3/ping | HTTP | Device registry unavailability | | Redis :6379 | TCP Port | Message bus connectivity loss | | Redis PING heartbeat | Heartbeat | Redis health (deeper check) | | Device service :59901/ping (Modbus) | HTTP | Modbus device reading failure | | Device service :59982/ping (MQTT) | HTTP | MQTT device reading failure | | Ingestion rate heartbeat | Heartbeat | Readings stopped flowing | | App service :59700/ping | HTTP | AWS/cloud export service down | | Export success heartbeat | Heartbeat | Export errors causing data gap | | Notification service :59860/ping | HTTP | EdgeX alerting disabled | | Command service :59882/ping | HTTP | Device command delivery broken | | Container restart heartbeat | Heartbeat | EdgeX container crash/restart |

EdgeX Foundry is a multi-service platform where silent failures in any layer — a device service crash, Redis congestion, a failed cloud export — break the OT/IT bridge without obvious symptoms. Vigilmon makes every service boundary visible, so you detect failures before your operations team notices missing data in the cloud.

Get started free at vigilmon.online.