Monitoring Racktables with Vigilmon

Racktables is the open source platform that datacenter and network engineers rely on to track every server, switch, cable, IP address, and rack unit in their infrastructure. When Racktables goes down, operations teams lose visibility into what's where — and that visibility loss has real consequences during incidents, maintenance windows, and capacity planning sessions. Vigilmon adds the uptime monitoring layer to your asset management platform: probing the web application, PHP-FPM workers, MySQL connectivity, and the specific services that make Racktables useful rather than just alive.

What You'll Set Up

• HTTP availability monitor for the Racktables web application (port 80)
• PHP-FPM process health check
• MySQL database connectivity monitor
• IP address allocation service probe
• Rack diagram rendering check
• User authentication endpoint monitor
• SSL certificate monitoring for HTTPS deployments

Prerequisites

• Racktables 0.20+ running on Apache or nginx with PHP-FPM
• MySQL or MariaDB backend database
• Web server accessible over HTTP or HTTPS
• A free Vigilmon account

Why Monitor Your Asset Management Platform

Racktables is often treated as a low-priority internal tool — until something goes wrong. Common scenarios where uptime matters:

• Incident response: Engineers checking which servers are in a rack or what IPs are allocated need Racktables available precisely when infrastructure is already under stress
• Rack installations: Datacenter technicians scheduling physical work need cable documentation and port mapping accessible
• IP address management: When IPAM data is unavailable, network teams make allocation decisions blind — leading to IP conflicts and routing errors

A Racktables outage doesn't break production services directly, but it breaks the operational visibility that keeps your datacenter organized. Monitoring it with the same rigor as production services is appropriate.

Step 1: Monitor the Racktables Web Application

The primary health check: is the Racktables interface accessible?

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your Racktables URL: http://your-racktables-host/racktables/ (adjust the path based on your installation).
4. Set Check interval to 2 minutes.
5. Set Expected HTTP status to 200 (or 302 if Racktables redirects to a login page).
6. Under Response body, add a keyword check: "RackTables" — this confirms the PHP application rendered, not just a web server default page.
7. Click Save.

If Racktables is deployed on HTTPS:

1. Open the monitor.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.

A common failure mode is PHP-FPM returning a 500 error while the web server returns 200 with a blank or error page. The keyword check catches this — a blank page passes the status code check but fails the content check.

Step 2: Monitor PHP-FPM Process Health

Racktables runs on PHP, which means PHP-FPM (or mod_php) handles request processing. PHP-FPM can exhaust its worker pool under load, run out of memory, or crash entirely — resulting in 502 Bad Gateway errors from the web server.

PHP-FPM exposes a status page you can probe. Enable it in your PHP-FPM pool configuration:

; /etc/php/8.x/fpm/pool.d/racktables.conf
pm.status_path = /fpm-status

Then configure nginx or Apache to expose it:

# nginx — expose PHP-FPM status on a local port
server {
    listen 127.0.0.1:8090;
    location /fpm-status {
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /fpm-status;
        include fastcgi_params;
    }
}

Reload PHP-FPM and nginx, then add a Vigilmon monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://localhost:8090/fpm-status.
3. Expected status: 200.
4. Keyword check: "pool:" — appears in every valid FPM status response.
5. Check interval: 2 minutes.
6. Click Save.

The FPM status page shows active workers, idle workers, and total requests. A pool with 0 idle workers is about to start rejecting requests — you can parse this for alerting:

#!/bin/bash
# /usr/local/bin/fpm-saturation-check.sh
IDLE=$(curl -s http://localhost:8090/fpm-status | grep "idle processes" | awk '{print $NF}')
if [ "$IDLE" -eq 0 ]; then
  echo '{"fpm": "saturated", "idle_workers": 0}'
  exit 1
fi
echo "{\"fpm\": \"ok\", \"idle_workers\": $IDLE}"

Step 3: Monitor MySQL Database Connectivity

Racktables stores all its data — racks, assets, IP ranges, cables, users — in MySQL. If the database becomes unreachable, Racktables displays PHP database errors and is entirely non-functional.

Add a TCP probe for MySQL:

1. Click Add Monitor → TCP Port.
2. Host: your-mysql-host (or localhost).
3. Port: 3306.
4. Set Check interval to 1 minute.
5. Click Save.

For a deeper check that validates Racktables' own database credentials work, create a PHP health script:

<?php
// /var/www/html/racktables/health.php
// Place this outside the Racktables document root or protect with auth

define('RACKTABLES_DB_HOST', 'localhost');
define('RACKTABLES_DB_NAME', 'racktables');
define('RACKTABLES_DB_USER', 'racktables');
define('RACKTABLES_DB_PASS', getenv('RACKTABLES_DB_PASS'));

try {
    $pdo = new PDO(
        'mysql:host=' . RACKTABLES_DB_HOST . ';dbname=' . RACKTABLES_DB_NAME,
        RACKTABLES_DB_USER,
        RACKTABLES_DB_PASS,
        [PDO::ATTR_TIMEOUT => 3]
    );
    $pdo->query('SELECT COUNT(*) FROM Object LIMIT 1');
    header('Content-Type: application/json');
    echo json_encode(['database' => 'ok']);
} catch (Exception $e) {
    http_response_code(503);
    header('Content-Type: application/json');
    echo json_encode(['database' => 'error', 'detail' => $e->getMessage()]);
}

Monitor http://your-racktables-host/health.php expecting status 200 and keyword "ok".

Step 4: Monitor the IP Address Allocation Service

Racktables manages IP address allocation across subnets. While this isn't a separate service per se, verifying that the IP management section renders correctly gives you confidence that the database queries for IP data are healthy:

Add a page-level check for the IP management interface:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-racktables-host/racktables/?page=ipv4space.
3. Expected status: 200 (or redirect to login — set to 302 if authentication is required).
4. Check interval: 5 minutes.
5. Click Save.

Since this page requires authentication, the most practical deep check is through the PHP health script approach — extend it to query IP allocation tables:

// Extend health.php with IP space check
$stmt = $pdo->query('SELECT COUNT(*) as count FROM IPv4Network');
$ipNetworks = $stmt->fetch()['count'];
echo json_encode(['database' => 'ok', 'ip_networks' => $ipNetworks]);

An ip_networks count of 0 when you expect dozens is a red flag that the IP management data may have been corrupted or deleted.

Step 5: Monitor Rack Diagram Rendering

Rack diagrams are one of Racktables' most-used features during physical datacenter work. They depend on PHP's GD or Imagick extension for image generation. If GD is missing after a PHP upgrade, diagrams silently fail.

Add a check for the rack visualization endpoint:

// Add to health.php
$gdInfo = gd_info();
$gdOk = isset($gdInfo['GD Version']);

// Also check that a known rack renders
// (optional — requires knowing a rack ID)
echo json_encode([
    'database' => 'ok',
    'gd_extension' => $gdOk ? 'ok' : 'missing',
]);

Monitor the health endpoint for "gd_extension":"ok" as a keyword.

After PHP upgrades, GD is a common casualty that silently breaks rack visualizations while the rest of Racktables works fine. Catching it here means you find out from Vigilmon rather than from a datacenter tech on-site who can't see the rack layout.

Step 6: Monitor the User Authentication Endpoint

Racktables uses PHP session-based authentication. If session handling breaks (typically from a PHP upgrade, session directory permissions change, or session.save_path misconfiguration), users can't log in even though the application appears to run.

The login page itself is a useful probe point:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-racktables-host/racktables/?page=login (or the redirect target if you use SSO).
3. Expected status: 200.
4. Keyword check: "password" — the login form should contain a password field.
5. Check interval: 5 minutes.
6. Click Save.

If Racktables redirects all unauthenticated requests to a login page (the default), your root URL monitor from Step 1 effectively checks this on every probe. Keep both monitors; they serve different diagnostic purposes when you're debugging a failure.

Step 7: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
2. Recommended thresholds:

| Monitor | Failures before alert | Urgency | |---|---|---| | Web application | 2 | High | | PHP-FPM health | 2 | High | | MySQL TCP | 1 | Critical | | MySQL query health | 1 | Critical | | IP allocation service | 3 | Medium | | Rack diagram rendering | 3 | Low | | Authentication endpoint | 2 | High |

Route database failures to an on-call channel — a dead MySQL means Racktables is completely down. Route rendering failures to a lower-urgency channel — they're disruptive but not blocking for most operations.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web application | :80/racktables/ | Apache/nginx down, PHP error | | PHP-FPM status | :8090/fpm-status | Worker pool exhaustion | | MySQL TCP | :3306 | Database unreachable | | MySQL query health | /health.php | Credential failure, query error | | IP allocation | /health.php (IP query) | IPAM data corruption | | Rack diagrams | GD extension check | PHP extension missing | | Authentication | Login page keyword | Session misconfiguration |

Racktables is your datacenter's source of truth — and the worst time to discover it's down is during an incident when you need to know exactly which server is in which rack, what IP it's using, and where its cables run. With Vigilmon monitoring every layer of the Racktables stack, you'll restore service before the next ops emergency arrives.