DEV Community

Vigilmon
Vigilmon

Posted on

How to Monitor Microservices Architecture with Vigilmon

#microservices #monitoring #architecture #devops

How to Monitor Microservices Architecture with Vigilmon

Microservices give you deployment flexibility and team autonomy — but they multiply your monitoring surface. What was one monolith to watch becomes 10, 20, or 50 services that can all fail independently. This guide shows how to monitor a microservices architecture with Vigilmon.

The Microservices Monitoring Challenge

In a microservices architecture:

  • Any single service failure can cascade to downstream services
  • API gateways may mask individual service failures
  • Distributed tracing helps with debugging but does not replace uptime monitoring
  • You need external uptime monitoring AND internal observability — they complement each other

Health Check Patterns for Microservices

The /health Endpoint Standard

Every microservice should expose a health endpoint:

// Express.js microservice
app.get('/health', async (req, res) => {
  const checks = {
    status: 'ok',
    service: 'user-service',
    version: process.env.SERVICE_VERSION || '1.0.0',
    dependencies: {}
  };

  try {
    await db.query('SELECT 1');
    checks.dependencies.database = 'ok';
  } catch(e) {
    checks.dependencies.database = 'error';
    checks.status = 'degraded';
  }

  const statusCode = checks.status === 'ok' ? 200 : 503;
  res.status(statusCode).json(checks);
});
Enter fullscreen mode Exit fullscreen mode 
# FastAPI microservice
@app.get("/health")
async def health():
    return {
        "status": "ok",
        "service": "order-service",
        "dependencies": {
            "database": await check_db(),
            "redis": await check_redis()
        }
    }
Enter fullscreen mode Exit fullscreen mode

Liveness vs Readiness Pattern

Follow Kubernetes conventions even outside k8s:

  • /health/live: Is the process alive? (no dependencies checked)
  • /health/ready: Is the service ready to handle traffic? (checks all dependencies)

Monitor both with Vigilmon — liveness catches crashes, readiness catches dependency failures.

Setting Up Vigilmon for Microservices

Step 1: Monitor Each Service Individually

Create one Vigilmon monitor per microservice:

Service URL Check
API Gateway https://api.yourapp.com/health 200 + "ok"
User Service https://users-internal.yourapp.com/health 200 + "ok"
Order Service https://orders-internal.yourapp.com/health 200 + "ok"
Payment Service https://payments-internal.yourapp.com/health 200 + "ok"

Step 2: Monitor the API Gateway First

Your API gateway is the single point of entry — monitor it with highest priority:

  • URL: https://api.yourapp.com/health
  • Method: GET
  • Expected status: 200
  • Multi-region: Yes (gateway is public-facing)
  • Interval: 30 seconds (critical path)

Step 3: Proxy Internal Services via Gateway

If internal services are not publicly accessible, add health proxy routes to your API gateway:

GET /internal-health/user-service   -> user-service:3001/health
GET /internal-health/order-service  -> order-service:3002/health
Enter fullscreen mode Exit fullscreen mode

Then monitor https://api.yourapp.com/internal-health/user-service.

Cascade Failure Detection

Configure Vigilmon alerts to identify cascade failures:

  1. Service A alert fires at T+0
  2. Service B alert fires at T+30s (was waiting for A)
  3. Pattern suggests A caused B's failure

Add to your incident runbooks:

"If multiple services alert within 60 seconds, check shared dependencies: database, Redis, message queue"

Alert Routing for Microservices Teams

Route alerts by service ownership:

User Service down:      -> Slack #team-identity + PagerDuty identity on-call
Order Service down:     -> Slack #team-commerce + PagerDuty commerce on-call
API Gateway down:       -> Slack #incidents (all teams) + PagerDuty platform on-call
Enter fullscreen mode Exit fullscreen mode

Naming Convention for Monitor Clarity

When you have 20+ services, include dependency context in monitor names:

  • "API Gateway [CRITICAL - blocks all]"
  • "User Service [blocks: auth, orders, profile]"
  • "Order Service [depends on: users, payments, inventory]"

This context helps on-call engineers triage faster during incidents.

Best Practices

  1. Every service needs /health — make it a non-negotiable engineering standard
  2. Monitor the gateway AND individual services — gateway up does not mean all services are up
  3. Set service-appropriate timeouts — payment services may be slower than user services
  4. Route alerts to service owners — do not blast everyone for every failure
  5. Use keyword checks — a degraded service might return 200 with error JSON
  6. Monitor inter-service dependencies — if service A calls B, both need independent monitoring

Conclusion

Monitoring microservices requires monitoring every service individually, not just the gateway. Vigilmon makes this manageable with unlimited monitors, multi-region checks, and flexible alert routing.

Start monitoring your microservices free at vigilmon.online

Top comments (0)