Monitoring CFEngine with Vigilmon: Hub Web UI, Mission Portal Health, TCP Port Checks & SSL Alerts

CFEngine is one of the oldest and most efficient open-source configuration management tools in existence — predating Puppet and Chef by nearly a decade and trusted in environments running hundreds of thousands of nodes. CFEngine agents run autonomously every 5 minutes, converging each node to its desired state without central coordination. When the CFEngine Enterprise Hub goes down or cf-serverd becomes unreachable, agents can still run their cached policies, but they can't fetch policy updates, report back to the Hub, or receive new configurations. Vigilmon monitors CFEngine's Hub web UI, Mission Portal health endpoint, cf-serverd TCP port (5308), and SSL certificates — giving you the external visibility that CFEngine's own internal reporting can't provide.

What You'll Build

An HTTP monitor for the CFEngine Enterprise Hub web UI (port 443)
An HTTP monitor for the Mission Portal health endpoint
A TCP port check for cf-serverd on port 5308
SSL certificate monitoring for CFEngine Hub TLS
Heartbeat monitors for CFEngine agent convergence cycles

Prerequisites

CFEngine Enterprise Hub running and accessible via HTTPS
cf-serverd listening on TCP port 5308 (the default CFEngine protocol port)
Agents running convergence checks (default: every 5 minutes)
A free account at vigilmon.online

Step 1: Understand CFEngine's Monitoring Surface

CFEngine's components relevant to external monitoring:

# Verify Mission Portal web UI is serving
curl -I https://cfengine-hub.example.com/

# Check cf-serverd is listening on port 5308
nc -zv cfengine-hub.example.com 5308

# Verify the Apache-based Mission Portal health
curl -s https://cfengine-hub.example.com/api/status

Key CFEngine ports:

443 — Mission Portal web UI (HTTPS via Apache/nginx in front of CFEngine)
5308 — cf-serverd protocol port (agents connect here to fetch policies and send reports)
80 — HTTP redirect to HTTPS (optional)

Step 2: Create an HTTP Monitor for the Hub Web UI

The CFEngine Enterprise Mission Portal is the primary interface for viewing host compliance, promise outcomes, and CFEngine Enterprise reports. If it's down, your team can't monitor fleet state or investigate failures:

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://cfengine-hub.example.com/.
Check interval: 2 minutes.
Response timeout: 15 seconds.
Expected status: 200.
Keyword: CFEngine (appears in the Mission Portal page title and HTML).
Label: CFEngine Mission Portal UI.
Click Save.

This monitor catches:

Apache/nginx process crash in front of Mission Portal
PHP-FPM failures that break the Mission Portal application layer
CFEngine Hub process failures that cause the UI to serve error pages
VM or container restarts that take the Hub offline

Alert sensitivity: Trigger after 2 consecutive failures. Mission Portal can be slow during large report ingestion but rarely fails outright for only one check.

Step 3: Create an HTTP Monitor for the Mission Portal Health Endpoint

CFEngine Enterprise exposes an API status endpoint that confirms the Mission Portal application layer is healthy, separate from whether the web UI is serving:

# Check Mission Portal API status
curl -s https://cfengine-hub.example.com/api/status
# Returns JSON with CFEngine version, API status

# Alternative endpoint (CFEngine 3.18+)
curl -s -u admin:password https://cfengine-hub.example.com/api/

Add Monitor → HTTP.
URL: https://cfengine-hub.example.com/api/status.
Check interval: 2 minutes.
Response timeout: 10 seconds.
Expected status: 200.
Keyword: CFEngine (present in the version string returned).
Label: CFEngine API status.
Click Save.

Authentication note: Depending on your CFEngine version and configuration, /api/status may require authentication. If so, Vigilmon will receive a 401 — set Expected status to 401 to confirm the API is up and requiring auth, rather than down entirely.

When the API health endpoint fires but the web UI monitor is green, the Mission Portal application is degraded — check CFEngine Hub database connectivity and the cf-hub process.

Step 4: Create a TCP Monitor for cf-serverd on Port 5308

cf-serverd is the heart of CFEngine's policy distribution. Agents connect to port 5308 to:

Fetch updated policy files from the policy server
Send agent reports back to the Hub
Authenticate via CFEngine's built-in key exchange

If port 5308 is unreachable, agents continue running with their last cached policy (for a configurable period), but can't receive updates or report compliance:

# Verify cf-serverd is listening
nc -zv cfengine-hub.example.com 5308
# Connection to cfengine-hub.example.com 5308 port [tcp/*] succeeded!

# Check the cf-serverd process directly on the hub
systemctl status cf-serverd

Add Monitor → TCP.
Host: cfengine-hub.example.com.
Port: 5308.
Check interval: 1 minute.
Response timeout: 10 seconds.
Label: CFEngine cf-serverd port 5308.
Click Save.

This monitor catches:

cf-serverd process crash or failure to start
Firewall rule changes blocking port 5308 (common after security hardening)
Host network issues that don't affect HTTPS (port-specific failures)

When the TCP monitor fires but HTTP monitors are green, cf-serverd is down or blocked while Mission Portal continues to serve from cached data — agents across your fleet can't fetch policy updates.

Step 5: Monitor SSL Certificates for CFEngine Hub TLS

CFEngine Enterprise Hub serves Mission Portal over HTTPS using a TLS certificate. An expired certificate causes:

Agents configured to verify the Hub's TLS certificate to fail connections
Administrator browser warnings when accessing Mission Portal
API calls from automation scripts to fail with TLS errors

# Check Hub certificate expiry
openssl s_client -connect cfengine-hub.example.com:443 2>/dev/null | openssl x509 -noout -dates

Add Monitor → SSL Certificate.
Domain: cfengine-hub.example.com.
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days, 1 day.
Click Save.

CFEngine's internal certificates: CFEngine also manages its own key infrastructure for agent-to-hub trust (stored in /var/cfengine/ppkeys/). These are not standard TLS certificates and can't be monitored by Vigilmon's SSL check. The SSL monitor covers the web-facing certificate for Mission Portal HTTPS — manage internal CFEngine key trust separately with cf-key.

Step 6: Add Heartbeat Monitoring for CFEngine Agent Convergence

CFEngine agents run cf-agent every 5 minutes by default, converging node state to the defined policy. You can instrument this cycle to send a heartbeat to Vigilmon, confirming that agents are actually running and converging successfully.

Create a Heartbeat Monitor

Add Monitor → Heartbeat.
Label: CFEngine agent convergence (hub).
Expected interval: 5 minutes (300 seconds).
Grace period: 2 minutes.
Click Save and copy the heartbeat URL.

Instrument CFEngine Agent with a Heartbeat Promise

Add a promise to your CFEngine policy that sends a heartbeat ping on each successful convergence:

bundle agent vigilmon_heartbeat
{
  vars:
    "heartbeat_url" string => "https://vigilmon.online/heartbeat/abc123";

  commands:
    linux::
      "/usr/bin/curl -fsS $(vigilmon_heartbeat.heartbeat_url)"
        contain => in_shell,
        comment => "Ping Vigilmon on successful cf-agent convergence";
}

bundle agent main
{
  methods:
    # ... your other bundles ...
    "vigilmon" usebundle => vigilmon_heartbeat;
}

This promise runs at the end of every cf-agent run. If the agent stops running (process crash, system issue, cron problem), Vigilmon alerts after the grace period.

For monitoring a sample of hosts rather than every node, run this promise only on designated canary nodes:

commands:
  linux.Hr05::  # Only run at minute 05 of every hour
    "/usr/bin/curl -fsS $(vigilmon_heartbeat.heartbeat_url)"
      contain => in_shell;

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, set up alert routing:

| Monitor | Trigger | Action | |---|---|---| | Mission Portal UI | Non-200 or keyword missing | Check Apache/nginx; systemctl status cf-hub | | API status | Non-200/401 | PHP-FPM or database connectivity; check Mission Portal logs | | cf-serverd TCP 5308 | Connection refused or timeout | systemctl status cf-serverd; check firewall | | SSL certificate | < 30 days to expiry | Renew certificate via Certbot or CA; redeploy to Hub | | Heartbeat (agent) | No ping within window | Check cf-agent cron/systemd timer on affected nodes |

Firewall note: Ensure Vigilmon's probe IPs can reach port 5308 on your CFEngine Hub. Many organizations restrict port 5308 to agent IP ranges — you may need to whitelist Vigilmon's monitoring IPs or use an internal probe.

Common CFEngine Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | cf-hub process crash | Mission Portal UI returns error; API status fails | | cf-serverd down or port blocked | TCP monitor fires; agents can't fetch policy updates | | Apache/nginx crash in front of Mission Portal | Web UI monitor fires; API status may also fail | | SSL certificate expires | SSL monitor alerts at 30 days; TLS-verifying agents fail | | CFEngine database (PostgreSQL) failure | API status endpoint errors; report ingestion stops | | cf-agent cron disabled or removed | Heartbeat stops; convergence halted silently | | Hub disk full (/var/cfengine/ fills) | Policy updates stop; agents reuse cached policy | | Host network partition | All monitors fire simultaneously | | Hub VM restart | Brief TCP and HTTP outage during boot; SSL unchanged |

CFEngine's autonomy is its greatest strength and its greatest monitoring challenge: agents run without central coordination, making it easy to miss when they've stopped running or when the Hub they report to has gone dark. Vigilmon bridges this gap — monitoring the Mission Portal availability that your team depends on for fleet visibility, the cf-serverd port that your agents depend on for policy updates, and the convergence heartbeat that confirms agents are actually running. When CFEngine goes silent, Vigilmon speaks up.

Start monitoring CFEngine in under 5 minutes — register free at vigilmon.online.