tutorial

Monitoring Centreon with Vigilmon

Centreon is a popular open source IT monitoring platform built on Nagios — here's how to monitor its Engine, Broker, Gorgone, web interface, MySQL database, pollers, and notification pipeline with Vigilmon.

Centreon is an open source IT infrastructure monitoring platform originally developed in France by Centreon SAS (founded 2005), built on Nagios Core and extending it with a modern web interface, distributed architecture, and a large plugin ecosystem. Centreon is widely deployed across European enterprises as an alternative to commercial Nagios XI and Zabbix. Its distributed architecture — central server, remote servers, and lightweight pollers — makes it scalable to thousands of monitored hosts, but it also means there are many components that can fail independently. When Centreon Engine stops executing checks, Centreon Broker stops persisting results, or Gorgone loses connectivity to a remote poller, monitoring gaps open silently — and the IT incidents you deployed Centreon to catch go undetected. Vigilmon adds an external layer of monitoring-the-monitor that catches Centreon component failures before your team notices the check feed going stale.

What You'll Set Up

  • Centreon Engine process health via cron heartbeat
  • Centreon Broker process and queue health monitor
  • Centreon Web HTTP availability monitor
  • Centreon Gorgone health check
  • MySQL/MariaDB database health monitor
  • Poller connectivity health heartbeat
  • Check execution rate monitor
  • Alert notification pipeline health check
  • Centreon REST API availability monitor
  • Disk space monitor for Centreon data directory
  • Alert channels with appropriate thresholds

Prerequisites

  • Centreon installed (central server or all-in-one deployment, Centreon 22.x or later)
  • Centreon Web accessible over HTTP/HTTPS
  • MySQL/MariaDB running on localhost or a dedicated host
  • SSH access to the Centreon server for cron heartbeat scripts
  • A free Vigilmon account

Step 1: Monitor the Centreon Web Interface

Centreon Web is what your operations team uses to view alerts, acknowledge incidents, and configure monitoring. If it goes down, operators are blind to the current incident state.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. URL: https://centreon.yourdomain.com/centreon/ (or your Centreon web URL).
  4. Set Expected HTTP status to 200.
  5. Set Check interval to 1 minute.
  6. Under Keyword check, enter Centreon to verify the web interface HTML loads (not just nginx responding).
  7. Enable Monitor SSL certificate and set the expiry alert to 21 days.
  8. Click Save.

This single check confirms that Apache/nginx, PHP-FPM, and the Centreon Web application are all running.


Step 2: Monitor the Centreon REST API

Centreon exposes a REST API for integrations, automation, and configuration management. API failures block CI/CD pipelines and third-party integrations.

  1. Click Add MonitorHTTP / HTTPS.
  2. URL: https://centreon.yourdomain.com/centreon/api/latest/
  3. Method: GET
  4. Expected HTTP status: 401 — an unauthenticated request should return 401, not 500. A 500 means the API backend is broken.
  5. Check interval: 2 minutes
  6. Click Save.

For an authenticated API check (optional, requires a monitoring API token):

  1. URL: https://centreon.yourdomain.com/centreon/api/latest/monitoring/hosts?limit=1
  2. Method: GET
  3. Under Headers, add X-AUTH-TOKEN: your-api-token
  4. Expected HTTP status: 200
  5. Under Response time alert, set threshold to 3000ms
  6. Check interval: 3 minutes
  7. Click Save.

Step 3: Monitor Centreon Engine Health

Centreon Engine (the Nagios-derived monitoring engine) executes all your host and service checks. If it crashes or stops processing, no new check results arrive and your monitoring data goes stale.

Since Engine doesn't expose an HTTP health endpoint, use a cron heartbeat:

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 3 minutes.
  3. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).
  4. On your Centreon server, create a health check script:
#!/bin/bash
# /usr/local/bin/centreon-engine-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-engine-heartbeat-id"
ENGINE_STATS="/var/log/centreon-engine/centengine.log"
ENGINE_PID="/var/run/centreon-engine/centengine.pid"

# Check Engine process is running
if [ ! -f "$ENGINE_PID" ] || ! kill -0 "$(cat $ENGINE_PID)" 2>/dev/null; then
  exit 1  # Engine not running — don't ping
fi

# Check Engine is actively writing (log modified in last 5 minutes)
if [ -f "$ENGINE_STATS" ]; then
  LAST_MOD=$(stat -c %Y "$ENGINE_STATS" 2>/dev/null)
  NOW=$(date +%s)
  AGE=$((NOW - LAST_MOD))
  if [ "$AGE" -gt 300 ]; then
    exit 1  # Log stale — Engine may be hung
  fi
fi

curl -sf "$HEARTBEAT_URL" > /dev/null
chmod +x /usr/local/bin/centreon-engine-check.sh

Add to crontab as the centreon user:

*/3 * * * * /usr/local/bin/centreon-engine-check.sh

Step 4: Monitor Centreon Broker Health

Centreon Broker receives check results from Engine and writes them to MySQL. If Broker stops or its queue grows too large (because MySQL is slow), recent check data is lost or delayed.

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 3 minutes.
  3. Copy the heartbeat URL.
  4. Create a Broker health script:
#!/bin/bash
# /usr/local/bin/centreon-broker-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-broker-heartbeat-id"
BROKER_PID="/var/run/centreon-broker/central-broker-master.pid"
QUEUE_DIR="/var/log/centreon-broker"
QUEUE_THRESHOLD_MB=500  # Alert if Broker queue exceeds 500 MB

# Check Broker process is running
if [ ! -f "$BROKER_PID" ] || ! kill -0 "$(cat $BROKER_PID)" 2>/dev/null; then
  exit 1  # Broker not running
fi

# Check Broker queue file size (data buffered when DB is slow)
QUEUE_MB=$(du -sm "$QUEUE_DIR" 2>/dev/null | cut -f1)
if [ -n "$QUEUE_MB" ] && [ "$QUEUE_MB" -gt "$QUEUE_THRESHOLD_MB" ]; then
  exit 1  # Queue too large — database write backlog
fi

curl -sf "$HEARTBEAT_URL" > /dev/null
chmod +x /usr/local/bin/centreon-broker-check.sh

Add to crontab:

*/3 * * * * /usr/local/bin/centreon-broker-check.sh

Also monitor the Broker RPC port (used for Engine-to-Broker communication):

  1. Click Add MonitorTCP Port.
  2. Host: localhost (or your Broker host)
  3. Port: 5669 (Centreon Broker BBDO protocol port)
  4. Check interval: 1 minute
  5. Click Save.

Step 5: Monitor Centreon Gorgone Health

Gorgone is the message broker that distributes commands and configuration from the central server to remote pollers. If it stops, poller configuration updates and passive check forwarding halt.

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 3 minutes.
  3. Copy the heartbeat URL.
  4. Create a Gorgone health check:
#!/bin/bash
# /usr/local/bin/centreon-gorgone-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-gorgone-heartbeat-id"

# Check Gorgone process is running
if ! pgrep -f "gorgoned" > /dev/null; then
  exit 1
fi

# Check Gorgone API response (if API enabled)
HTTP_STATUS=$(curl -sf -o /dev/null -w "%{http_code}" \
  http://localhost:8085/api/v1/nodes/me 2>/dev/null)

if [ "$HTTP_STATUS" = "200" ]; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
elif pgrep -f "gorgoned" > /dev/null; then
  # API not enabled but process is running — still healthy
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
chmod +x /usr/local/bin/centreon-gorgone-check.sh

Add to crontab:

*/3 * * * * /usr/local/bin/centreon-gorgone-check.sh

Step 6: Monitor MySQL/MariaDB Database Health

All Centreon check results, host/service configurations, and performance data are stored in MySQL/MariaDB. Database unavailability causes Broker to buffer data and eventually lose check results.

Monitor MySQL TCP connectivity:

  1. Click Add MonitorTCP Port.
  2. Host: localhost (or your database host)
  3. Port: 3306
  4. Check interval: 1 minute
  5. Click Save.

For a deeper database health check, add a cron heartbeat that tests a query:

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 5 minutes.
  3. Copy the heartbeat URL.
  4. Create a database health script:
#!/bin/bash
# /usr/local/bin/centreon-db-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-db-heartbeat-id"
DB_USER="centreon"
DB_PASS="your-centreon-db-password"
DB_NAME="centreon_storage"
QUERY_THRESHOLD=2  # Alert if query takes more than 2 seconds

START=$(date +%s%N)
RESULT=$(mysql -u"$DB_USER" -p"$DB_PASS" -e \
  "SELECT COUNT(*) FROM $DB_NAME.hosts LIMIT 1;" 2>/dev/null)
END=$(date +%s%N)

if [ -z "$RESULT" ]; then
  exit 1  # Query failed — don't ping
fi

ELAPSED_MS=$(( (END - START) / 1000000 ))
THRESHOLD_MS=$((QUERY_THRESHOLD * 1000))

if [ "$ELAPSED_MS" -lt "$THRESHOLD_MS" ]; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
# Slow query: don't ping — Vigilmon alerts
chmod +x /usr/local/bin/centreon-db-check.sh

Add to crontab:

*/5 * * * * /usr/local/bin/centreon-db-check.sh

Step 7: Monitor Check Execution Rate

When Centreon Engine is overloaded, checks get scheduled late ("late checks"). A growing late check count means your monitoring data is falling behind real time.

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 5 minutes.
  3. Copy the heartbeat URL.
  4. Create a check execution rate monitor:
#!/bin/bash
# /usr/local/bin/centreon-late-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-late-checks-heartbeat-id"
LATE_CHECK_THRESHOLD=50  # Alert if more than 50 checks are late

# Read Engine statistics via the stats file
STATS_FILE="/var/log/centreon-engine/centengine.stats"

if [ ! -f "$STATS_FILE" ]; then
  # Stats file not available — check if Engine is running instead
  pgrep -f centengine > /dev/null && curl -sf "$HEARTBEAT_URL" > /dev/null
  exit 0
fi

LATE_CHECKS=$(grep -oP "(?<=Active service latency: )\d+" "$STATS_FILE" 2>/dev/null | head -1)

if [ -z "$LATE_CHECKS" ] || [ "$LATE_CHECKS" -lt "$LATE_CHECK_THRESHOLD" ]; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
chmod +x /usr/local/bin/centreon-late-check.sh

Add to crontab:

*/5 * * * * /usr/local/bin/centreon-late-check.sh

Step 8: Monitor Poller Connectivity

In distributed Centreon deployments, pollers execute checks for remote network segments. A disconnected poller creates a monitoring gap for its entire segment.

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 5 minutes.
  3. Copy the heartbeat URL.
  4. Create a poller connectivity check on the central server:
#!/bin/bash
# /usr/local/bin/centreon-pollers-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-pollers-heartbeat-id"
EXPECTED_POLLERS=3  # Set to the number of pollers you expect to be connected

# Check poller status via Centreon API
API_TOKEN="your-centreon-api-token"
API_URL="https://localhost/centreon/api/latest"

CONNECTED=$(curl -sf -H "X-AUTH-TOKEN: $API_TOKEN" \
  "$API_URL/configuration/pollers?status=connected" 2>/dev/null \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('total', 0))" 2>/dev/null)

if [ -z "$CONNECTED" ]; then
  # API not responding — Broker/Engine already covered by other heartbeats
  exit 0
fi

if [ "$CONNECTED" -ge "$EXPECTED_POLLERS" ]; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
# Fewer pollers than expected: don't ping
chmod +x /usr/local/bin/centreon-pollers-check.sh

Add to crontab:

*/5 * * * * /usr/local/bin/centreon-pollers-check.sh

You can also monitor each poller's Broker port directly from the central:

  1. Click Add MonitorTCP Port.
  2. Host: poller-1.yourdomain.com
  3. Port: 5669 (BBDO protocol)
  4. Check interval: 2 minutes
  5. Click Save (repeat for each poller).

Step 9: Monitor Disk Space for Centreon Data

Centreon performance data, RRD files (for graphs), and Broker queue files accumulate on disk. If disk space is exhausted, Broker stops writing check results and Engine may halt.

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 15 minutes.
  3. Copy the heartbeat URL.
  4. Create a disk space monitor:
#!/bin/bash
# /usr/local/bin/centreon-disk-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-disk-heartbeat-id"
DISK_THRESHOLD=80  # Alert at 80% usage

# Check usage of key Centreon directories
for DIR in /var/lib/centreon /var/log/centreon /var/log/centreon-engine /var/lib/centreon-broker; do
  if [ -d "$DIR" ]; then
    PCT=$(df "$DIR" 2>/dev/null | awk 'NR==2{gsub(/%/,"",$5); print $5}')
    if [ -n "$PCT" ] && [ "$PCT" -ge "$DISK_THRESHOLD" ]; then
      exit 1  # Disk too full — don't ping
    fi
  fi
done

curl -sf "$HEARTBEAT_URL" > /dev/null
chmod +x /usr/local/bin/centreon-disk-check.sh

Add to crontab:

*/15 * * * * /usr/local/bin/centreon-disk-check.sh

Step 10: Monitor the Alert Notification Pipeline

Centreon's value is alerting you when infrastructure fails. If Centreon's own notification pipeline breaks — SMTP server unreachable, notification scripts failing — SLA breaches go unnotified.

Test notification delivery by using Centreon to send a test notification to a dedicated Vigilmon heartbeat email address (if you use email notifications) or by pinging Vigilmon from a Centreon notification script:

  1. Click Add MonitorCron Heartbeat.
  2. Set expected interval to 30 minutes.
  3. Copy the heartbeat URL.
  4. Create a notification pipeline test script that sends a test notification through Centreon's normal notification mechanism:
#!/bin/bash
# /usr/local/bin/centreon-notification-test.sh
# Run as centreon user, simulates the notification pipeline

HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-notify-heartbeat-id"

# Test SMTP connectivity (used by Centreon email notifications)
SMTP_HOST="your-smtp-host"
SMTP_PORT=25

if nc -z -w5 "$SMTP_HOST" "$SMTP_PORT" 2>/dev/null; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
# SMTP unreachable: don't ping — Vigilmon alerts
chmod +x /usr/local/bin/centreon-notification-test.sh

Add to crontab:

*/30 * * * * /usr/local/bin/centreon-notification-test.sh

Step 11: Configure Alert Channels and Thresholds

  1. Go to Alert Channels in Vigilmon and add Slack, email, or PagerDuty.
  2. For Centreon Web, set Consecutive failures before alert to 2 — brief Apache/PHP restarts can cause momentary 502s.
  3. For Engine and Broker heartbeats (3-minute intervals), Vigilmon alerts automatically after the window passes.
  4. For MySQL TCP port, set Consecutive failures to 1 — database loss is immediately critical.
  5. For the BBDO TCP port monitors (pollers), set Consecutive failures to 2.
  6. For disk space heartbeats (15-minute interval), the miss alert gives you lead time before disk fills completely.
  7. Enable Recovery notifications on all monitors.

Verifying Your Setup

After adding all monitors, verify the heartbeat scripts are running:

# List all crontab entries
crontab -l

# Check recent script executions
grep "centreon" /var/log/cron | tail -20

# Manually trigger a heartbeat to verify connectivity
/usr/local/bin/centreon-engine-check.sh && echo "Engine heartbeat sent"
/usr/local/bin/centreon-broker-check.sh && echo "Broker heartbeat sent"

In Vigilmon, all cron heartbeat monitors should show green within 5 minutes of adding the crontab entries.


Conclusion

You now have complete external observability over your Centreon monitoring stack: Engine and Broker heartbeats catch the core check execution and data persistence pipeline before stale data reaches your dashboards, Gorgone monitoring protects poller connectivity, the web interface and REST API monitors confirm operator access is intact, and the MySQL and disk space monitors guard the data store that Centreon depends on. By monitoring your monitoring platform, you close the blind spot where Centreon itself can fail silently while you trust it's watching your infrastructure. For more self-hosted infrastructure monitoring guides, see vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →