Simplifying Application Health Monitoring with F5 BIG-IP

A simple agreement between BIG-IP administrators and application owners can foster smooth collaboration between teams. Application owners define their own simple or complex health monitors and agree to expose a conventional /health endpoint. When a /health endpoint responds with an HTTP 200 request, BIG-IP assumes the application is healthy based on the application owners' own criteria.

The Challenge of Health Monitoring in Modern Environments

F5 BIG-IP administrators in Network Operations (NetOps) teams often work with application teams because the BIG-IP acts as a full proxy, providing services like:

• TLS termination
• Load balancing
• Health monitoring

Health checks are crucial for effective load balancing. The BIG-IP uses them to determine where to send traffic among back-end application servers. However, health monitoring frequently causes friction between teams.

Problems with the Traditional Approach 

Traditionally, BIG-IP administrators create and maintain health monitors ranging from simple ICMP pings to complex monitors that:

• Simulate user transactions
• Verify HTTP response codes
• Validate payload contents
• Track application dependencies

This leads to several issues:

1. Knowledge Gap: NetOps may not fully grasp each application's intricacies.
2. Change Management Overhead: Application updates require retesting monitors, causing delays. 
3. Production Risk: Monitors can break after application changes, incorrectly marking services as up/down.
4. Team Friction: Troubleshooting failed health checks involves tedious back-and-forth between teams.

A Cloud-Native Solution

The cloud-native and microservices communities have patterns that elegantly solve these problems. One widely used pattern is the [health endpoint], which adapts well to BIG-IP environments.

The /health Endpoint Convention

Cloud-native applications commonly expose dedicated health endpoints like /health, /healthy, or /ready. These return standard status codes reflecting the application's state. 

The /health endpoint provides a clear contract between NetOps and application teams for BIG-IP integration.

Implementing the Contract

This approach establishes a simple agreement:

Application Team Responsibilities:

• Implement /health to return HTTP 200 when the application is ready for traffic
• Define "healthy" based on application needs (database connectivity, dependencies, etc.)
• Maintain the health check logic as the application changes

BIG-IP Team Responsibilities:

• Configure an HTTP monitor targeting the /health endpoint
• Treat 200 as "healthy", anything else as "unhealthy"

Benefits of This Approach

1. Aligned Expertise: Application teams define health based on their knowledge.
2. Less Friction: BIG-IP configuration stays stable as applications evolve. 
3. Better Reliability: Health checks reflect true application health, including dependencies.
4. Easier Troubleshooting: The /health endpoint can return detailed diagnostic info, but this is ignored by the BIG-IP and used strictly for troubleshooting.

Implementation Examples

F5 BIG-IP Health Monitor Configuration

ltm monitor http /Common/app-health-monitor {  
    defaults-from /Common/http
    destination *:*
    interval 5 
    recv 200
    recv-disable none
    send "GET /health HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n"
    time-until-up 0
    timeout 16      
}

 

Node.js Health Endpoint Implementation

const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Application is running');  
});

app.get('/health', async (req, res) => {
  try {
    const dbStatus = await checkDatabaseConnection();
    const serviceStatus = await checkDependentServices();
    
    if (dbStatus && serviceStatus) {
      return res.status(200).json({
        status: 'healthy',
        database: 'connected', 
        services: 'available',
        timestamp: new Date().toISOString()
      });
    }
    
    res.status(503).json({
      status: 'unhealthy', 
      database: dbStatus ? 'connected' : 'disconnected',
      services: serviceStatus ? 'available' : 'unavailable', 
      timestamp: new Date().toISOString()
    });
    
  } catch (error) {
    res.status(500).json({
      status: 'error',
      message: error.message,
      timestamp: new Date().toISOString() 
    });
  }
});

async function checkDatabaseConnection() {
  // Check real database connection
  return true; 
}

async function checkDependentServices() {
  // Check required service connections
  return true;
}

app.listen(port, () => {
  console.log(`Application listening at http://localhost:${port}`);
});

 

Adopting this health check pattern can greatly reduce friction between NetOps and application teams while improving reliability. The simple contract of HTTP 200 for healthy provides the needed integration while letting each team focus on their expertise.

For apps that can't implement a custom /health endpoint, BIG-IP admins can still use traditional ICMP or TCP port monitoring. However, these basic checks can't accurately reflect an app's true health and complex dependencies.

This approach fosters collaboration and leverages the specialized knowledge of both network and application teams. The result is more reliable services and smoother operations.