Kassinipedia

Health Monitors

Se lee en 4 min

Health Monitors

Resumen

Un monitor comprueba cada cierto tiempo si un miembro (o nodo) responde, y BIG-IP solo envía tráfico a los que están up. Un ping solo prueba que el servidor está encendido; un monitor HTTP con receive string prueba que la aplicación realmente funciona. Esta nota crea monitores personalizados, los asigna, combina varios con Availability Requirement y usa alias para revisar un segundo servicio.

Requisitos previos

  • Una URL de salud en la aplicación (ej. /health que devuelva OK)
  • Qué servicios deben estar vivos para considerar el servidor sano
  • El pool creado (Pools y Load Balancing)

Conceptos clave

ConceptoQué es
Interval / TimeoutCada cuánto se revisa / cuánto esperar antes de marcar down. Regla: timeout = 3 × interval + 1 (5 s / 16 s)
Send StringLo que envía el monitor (ej. un GET)
Receive StringTexto que debe aparecer en la respuesta
Receive Disable StringSi aparece, el miembro pasa a disabled (drenado), no a down
Alias Address / PortRevisar otra IP o puerto distinto al del miembro
Availability RequirementCon varios monitores: All o At least N deben pasar
bigdDaemon que ejecuta los monitores

No edites los monitores por defecto

Crea uno nuevo usando el de sistema como parent (http, tcp, gateway_icmp…).

Configuración (Ejemplo, Lab CBT Nuggets)

1. Crear un monitor HTTP de contenido

Local Traffic > Monitors > Create > Name: APP1-Content-Monitor, Type: HTTP > Interval 5, Timeout 16 > Send String y Receive String > Finished.

  • Send String: GET /health HTTP/1.1\r\nHost: app1.f5lab.int\r\nConnection: close\r\n\r\n
  • Receive String: OK
tmsh create ltm monitor http APP1-Content-Monitor defaults-from http interval 5 timeout 16 send "GET /health HTTP/1.1\r\nHost: app1.f5lab.int\r\nConnection: close\r\n\r\n" recv "OK"

2. Asignarlo al pool

Local Traffic > Pools > Pool List > el pool > Configuration: Basic > Health Monitors: mover el monitor de Available a Active > Update.

tmsh modify ltm pool HTTP_APP1_Pool monitor APP1-Content-Monitor

3. Monitor ICMP en los nodos (opcional)

Local Traffic > Nodes > el nodo > Health Monitors: Node Specific > icmp > Update.

tmsh modify ltm node 10.10.101.101 monitor icmp

El monitor del nodo afecta a todos sus pools

Si falla, todos los miembros de ese servidor caen en todos los pools.

4. Revisar dos servicios del mismo servidor (alias)

Caso: el miembro solo está sano si responden HTTP (80) y un servicio en TCP 8080.

  1. Monitors > Create > Name: TCP-8080, Type: TCP > Configuration: Advanced > Alias Service Port: 8080 > Finished.
  2. Pool > Health Monitors: activa http y TCP-8080.
  3. Pool > Configuration: Advanced > Availability Requirement: All > Update.
tmsh create ltm monitor tcp TCP-8080 defaults-from tcp destination *:8080
tmsh modify ltm pool HTTP_APP1_Pool monitor "http and TCP-8080"

"http and TCP-8080" equivale a Availability Requirement = All; "min 1 of { http TCP-8080 }" equivale a At least 1.

5. Drenado controlado por la aplicación

En el monitor: Receive Disable String = MAINTENANCE. Cuando el equipo de la app pone ese texto en /health, el miembro pasa a disabled sin que toques el BIG-IP.

6. Probar el servicio a mano desde el BIG-IP

curl -v http://10.10.101.101/health
telnet 10.10.101.101 80
nc -vz 10.10.101.101 8080
nc -vzu 10.10.101.101 53

nc -u sirve para servicios UDP.

Verificación

Comando o lugarQué debes verSi no lo ves
Local Traffic > Network MapMiembros 🟢Revisa el monitor y el servicio
tmsh show ltm pool HTTP_APP1_Pool membersAvailability: availableRevisa la respuesta con curl
tail -f /var/log/ltmMensajes monitor status up/down—
Apagar NGINX en un servidorEl miembro pasa a 🔴 tras el timeoutMonitor mal asignado o solo ICMP

Errores comunes

El miembro está rojo pero la web abre en el navegador

  • Causa: el Receive String no coincide (mayúsculas, texto distinto), falta el header Host, o la ruta devuelve redirect (301/302).
  • Revisa: curl -v con el mismo Send String.
  • Solución: corrige la URL, el Host o el texto esperado.

El miembro sigue verde con el servicio caído

  • Causa: solo hay monitor ICMP o TCP, o Availability Requirement en “At least 1”.
  • Solución: usa un monitor de aplicación y, con varios monitores, All.

Los miembros suben y bajan (flapping)

  • Causa: intervalos muy cortos, servidor sobrecargado o pérdida de paquetes.
  • Solución: ajusta interval/timeout (3n+1), usa Time Until Up y revisa el servidor.

Todos los miembros de varios pools cayeron a la vez

  • Causa: falló el monitor del nodo o el nodo se deshabilitó.
  • Solución: revisa Local Traffic > Nodes.

Retroenlaces