Vigilmon

Posted on Aug 4

How to Monitor AWS RDS with Vigilmon

#aws #database #monitoring #devops

AWS RDS is the backbone of countless production applications — hosting PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server instances with managed backups, replication, and patching. But "managed" doesn't mean "infallible." RDS instances experience connectivity issues, failover events, storage exhaustion, and performance degradation just like any other database.

The key difference is that RDS isn't directly internet-accessible (and shouldn't be). So how do you monitor it externally? This guide explains the right approach using Vigilmon.

Why You Can't Just Ping RDS Directly

RDS instances live inside a VPC and typically have no public endpoint (unless you explicitly enable one, which is a security anti-pattern). Even if they did, a TCP ping to port 5432 or 3306 only tells you the port is open — not whether your application can actually query data.

The right approach is to monitor RDS through your application layer: expose a health check endpoint in your API or backend service that performs a lightweight database query, then monitor that endpoint with Vigilmon.

Setting Up RDS Monitoring with Vigilmon

Step 1: Add a Database Health Check to Your Application

In your API (running on EC2, ECS, Lambda, or App Runner), create a health endpoint that tests RDS connectivity:

Node.js / Express example:

app.get('/health/db', async (req, res) => {
  try {
    const result = await pool.query('SELECT 1');
    res.status(200).json({
      status: 'healthy',
      database: 'connected',
      latency_ms: result.duration
    });
  } catch (error) {
    res.status(503).json({
      status: 'unhealthy',
      database: 'disconnected',
      error: error.message
    });
  }
});

Python / FastAPI example:

@app.get("/health/db")
async def health_check():
    try:
        await db.execute("SELECT 1")
        return {"status": "healthy", "database": "connected"}
    except Exception as e:
        raise HTTPException(status_code=503, detail=str(e))

Keep this endpoint lightweight — SELECT 1 is sufficient. Don't run complex queries in health checks.

Step 2: Sign Up for Vigilmon

Head to vigilmon.online — the free tier gives you 10 monitors with 3-minute check intervals. No credit card required.

Step 3: Add an HTTP Monitor

Click Add Monitor in the dashboard
Choose HTTP monitor type
Enter your health endpoint URL (e.g., https://api.myapp.com/health/db)
Set expected status: 200
Enable multi-region checks (US, EU, AP) to confirm outages aren't regional network blips
Set your check interval

Step 4: Monitor Your Application's Primary Endpoint Too

Add a second monitor for your main API endpoint (e.g., https://api.myapp.com/health). This gives you a distinction between:

App is down: Both monitors fail
Database is down, app is up: Only the DB health monitor fails

This separation makes incident diagnosis much faster.

Step 5: Configure Alerts

Set up notifications via:

Email: Immediate alert to your team
Slack: Post to #incidents with context
PagerDuty: Escalate to on-call engineer
Webhooks: Trigger runbooks, auto-scaling, or snapshot creation

Key RDS Metrics to Watch (Via Application Layer)

Signal	How Vigilmon Captures It
Database connectivity	HTTP monitor on `/health/db` returns 503
Query latency degradation	Response time increases on health endpoint
RDS failover event	Brief downtime window (30–60 seconds) during Multi-AZ failover
Application + DB both down	Both monitors fail simultaneously

Complementing CloudWatch

AWS CloudWatch gives you RDS metrics like CPU utilization, free storage space, and read/write IOPS. Vigilmon gives you the user-facing perspective: is your app actually serving requests successfully?

Use both:

CloudWatch for infrastructure-level early warnings (storage filling up, CPU spiking)
Vigilmon for end-to-end availability from external vantage points

Heartbeat Monitors for RDS Maintenance Tasks

If you run scheduled maintenance jobs against RDS (e.g., nightly vacuum, stats updates, data exports), use Vigilmon's heartbeat monitor to confirm they complete successfully. Your job pings a unique Vigilmon URL on completion; if the ping doesn't arrive in the expected window, you're alerted.

Alert Configuration Tips

Multi-region confirmation: Configure Vigilmon to require confirmation from multiple regions before alerting. This prevents false alarms during single-region network hiccups.

Response time alerts: Set a threshold (e.g., alert if response time exceeds 3 seconds). Slow health checks often precede full outages.

Separate monitors per RDS instance: If you have multiple RDS instances (e.g., read replicas, separate databases per service), add a dedicated health endpoint and Vigilmon monitor for each.

Get Started

External monitoring is the first line of defense for any production database. Sign up at vigilmon.online — it's free to start, no credit card needed. The free tier gives you 10 monitors to cover your most critical services, and paid plans start at just $6/month.

Don't let your users be the first to tell you your database is down.

DEV Community