Nested Host Monitoring: Organize Monitors by Infrastructure

Who This Is For

This guide is for DevOps engineers and platform teams who manage dozens of monitors and struggle with organization. If your monitoring dashboard is an overwhelming flat list, nested host monitoring will change how you work.

If you've ever asked "which server hosts this endpoint?" during an incident, you need better monitor organization.

What Is Nested Host Monitoring?

Nested host monitoring organizes monitors in a hierarchy that reflects your infrastructure:

Traditional Flat Approach

Monitors:
- api.example.com/health
- api.example.com/users
- api.example.com/orders
- example.com
- example.com/login
- db-primary:5432
- redis:6379

No context. No relationships. Just a list.

Nested Host Approach

Production Environment
├── Web Server (web-prod-01)
│   ├── HTTP: example.com
│   ├── HTTP: example.com/login
│   └── Server: CPU 45%, Memory 72%, Disk 58%
│
├── API Server (api-prod-01)
│   ├── HTTP: api.example.com/health
│   ├── HTTP: api.example.com/users
│   ├── HTTP: api.example.com/orders
│   └── Server: CPU 23%, Memory 65%, Disk 42%
│
├── Database Server (db-prod-01)
│   ├── TCP: 5432
│   └── Server: CPU 15%, Memory 89%, Disk 75%
│
└── Cache Server (redis-prod-01)
    ├── TCP: 6379
    └── Server: CPU 8%, Memory 45%, Disk 22%

Now you see relationships. When api.example.com/health fails, you immediately check the API Server's CPU and memory.

Why Nested Organization Matters

1. Faster Root Cause Analysis

Without nested hosts:

Alert: api.example.com/health is down
Action: SSH into server, run htop, check logs
Time: 5-15 minutes to find cause

With nested hosts:

Alert: api.example.com/health is down
Dashboard shows: API Server CPU at 98%
Action: Scale or restart
Time: 1-2 minutes to find cause

2. Understanding Blast Radius

When a server has issues, all endpoints on it are affected. Nested views make this obvious:

API Server (api-prod-01) ⚠️ CPU Critical
├── ✗ api.example.com/health (timeout)
├── ✗ api.example.com/users (timeout)
└── ✗ api.example.com/orders (timeout)

Flat lists don't show this relationship.

3. Easier Maintenance

When you need to maintenance a server:

1. Find the server in your hierarchy
2. See all affected endpoints
3. Schedule maintenance window
4. Notify affected users

4. Cleaner Dashboards

50 monitors organized into 8 hosts is manageable. 50 monitors in a flat list is chaos.

Wakestack's Nested Host Model

Wakestack is built around the concept of hosts and their children:

Hosts

A host represents a server, VM, or logical grouping:

• Physical servers
• Cloud VMs (EC2, Droplet, etc.)
• Kubernetes nodes
• Logical groups (all payment services)

Children

Each host can have:

• Uptime monitors: HTTP, TCP, DNS, Ping checks
• Server metrics: CPU, memory, disk, processes
• Child hosts: For hierarchical grouping

Example Structure

Infrastructure
├── US-East Cluster
│   ├── Load Balancer
│   │   └── HTTP: lb.example.com
│   ├── Web-1
│   │   ├── HTTP: web1.example.com
│   │   └── Metrics: CPU, Memory, Disk
│   └── Web-2
│       ├── HTTP: web2.example.com
│       └── Metrics: CPU, Memory, Disk
│
├── US-West Cluster
│   └── ...
│
└── Database Cluster
    ├── Primary
    │   ├── TCP: 5432
    │   └── Metrics: CPU, Memory, Disk
    └── Replica
        ├── TCP: 5432
        └── Metrics: CPU, Memory, Disk

Setting Up Nested Monitoring

Step 1: Plan Your Hierarchy

Before adding monitors, sketch your infrastructure:

Questions to answer:
- What servers do I have?
- What endpoints run on each server?
- How do servers relate (clusters, regions)?

Step 2: Create Parent Hosts

Start with top-level groupings:

1. Go to Hosts in Wakestack
2. Create "Production" as a parent
3. Create "Staging" as a parent

Step 3: Add Server Hosts

Under each environment:

1. Create hosts for each server
2. Install the agent on each server
3. Metrics start flowing automatically

Step 4: Add Monitors to Hosts

Attach monitors to their servers:

1. Create HTTP monitor for api.example.com
2. Set parent host to "API Server"
3. Monitor now appears under that server

Step 5: Verify Relationships

Check your dashboard:

• Expand a server host
• See all endpoints beneath it
• See server metrics alongside

Comparing Organizational Approaches

Tags vs Nested Hosts

Tags add metadata but don't create hierarchy:

With tags:

api-health [production] [api] [us-east]
api-users [production] [api] [us-east]

Can filter by tag, but still a flat view.

With nested hosts:

Production → US-East → API Server
├── api-health
└── api-users

True hierarchy shows relationships.

Best Practices for Nested Monitoring

1. Mirror Your Infrastructure

Your monitoring hierarchy should match your mental model of infrastructure:

• Data center → Cluster → Server → Services
• Cloud region → VPC → Instance → Endpoints

2. Use Meaningful Names

Bad:

Server 1
├── Check 1
└── Check 2

Good:

api-prod-east-01
├── /api/health
└── /api/v1/users

3. Don't Over-Nest

Keep hierarchy to 3-4 levels max:

Environment → Region → Server → Monitor

Too deep becomes confusing.

4. Group Logically, Not Just Physically

Sometimes logical groups make more sense:

Payment Services (logical group)
├── Payment API Server
│   └── /payments
├── Stripe Webhook Server
│   └── /webhooks/stripe
└── Billing Database
    └── TCP 5432

5. Include Server Metrics

The power of nested hosts comes from combining uptime and server monitoring:

API Server
├── /api/health (⚠️ slow)
├── CPU: 92% (⚠️ high)  ← Root cause
├── Memory: 45%
└── Disk: 60%

Use Case: Incident Response

Scenario

Alert: api.example.com/orders is returning 503 errors

Without Nested Hosts

1. Check Slack for alerts
2. Open monitoring dashboard
3. Find the failing monitor in a list of 50
4. Wonder which server it's on
5. Check documentation (if it exists)
6. SSH into server
7. Run diagnostic commands
8. Find CPU at 100%
9. Investigate process

Time to root cause: 10-15 minutes

With Nested Hosts

1. Check Slack for alerts
2. Open monitoring dashboard
3. Click on alert → see it under "API Server (api-prod-01)"
4. Server metrics show CPU at 100%
5. Process list shows runaway worker
6. Kill process

Time to root cause: 2-3 minutes

Try Wakestack's Nested Host Monitoring

Organize your monitors by infrastructure, not by flat lists.

• Hierarchical organization built-in
• Server metrics alongside uptime
• Free tier to try it out
• No credit card required

Start Organizing →

Related Resources

• Infrastructure-Aware Uptime Monitoring
• Server Monitoring: Complete Guide
• Uptime Monitoring: Complete Guide