Description

Le monitoring dans ce contexte est le fait de vérifier à intervalle régulier l'état de santé d'un serveur backend pour savoir s'il est toujours apte à traiter du trafic.
Cela ne sert à rien d'envoyer une requête HTTP à un serveur qui est indisponible. Chez d'autres fournisseurs de laod balancing on trouvera des dénominations comme "health monitor", "health check", "des monitors".
Dans la suite de cet article nous ne traiterons que de monitoring pour des serveurs de backend HTTP.

Check de niveau 4

C'est le check le plus simple, il vérifie qu'une socket (une connexion sur une adresse IP et un port) s'ouvre bien, cela fonctionne sur tout type de serveur backend.

Configuration du fichier /etc/haproxy/haproxy.cfg (juste pas partie backend) :

backend bk_apache
        balance roundrobin
        mode http
        server apache1 10.0.0.1:80 check
        server apache2 10.0.0.2:80 check
        server apache3 10.0.0.3:80 check

Le mot check tout seul comme ça fait un monitoring via une ouverture de socket sur l'adresse IP et port du serveur backend concerné.

Résultat dans les statistiques :

On peut voir dans la colonne server | LastChk le type de monitoring ici L4 et l'état, si on survol ce champ avec la souris on peut avoir une infos dans une infobulle.
J'ai stoppé deux fois le serveur apache2, dans les colonnes server | Chk et server | Dwn on voit respectivement le nombre de check échoué et le nombre de fois que le serveur de backend a été vu indisponible depuis le redémarrage d'HAProxy.

Check de niveau 7

Pour des serveurs de backend HTTP c'est un moyen plus évolué de valider le bon fonctionnement du service, car le socket peut répondre alors que le service est dans un état indéterminé.

Configuration du fichier /etc/haproxy/haproxy.cfg (juste pas partie backend) :

backend bk_apache
        balance roundrobin
        mode http
        option httpchk HEAD /page_a_verifier.html HTTP/1.0
        server apache1 10.0.0.1:80 check
        server apache2 10.0.0.2:80 check
        server apache3 10.0.0.3:80 check

Lorsque l'on spécifie l'option httpchk, une requête HTTP est envoyée au serveur de backend, seules les status code HTTP 2xx et 3xx valident le monitor.
La syntax est la suivante :

option httpchk
option httpchk <uri>
option httpchk <method> <uri>
option httpchk <method> <uri> <version>

Note :
Lorsque l'on spécifie le HTTP 1.1, il faut obligatoirement spécifier le header Host.

Résultat dans les statistiques :

On voit bien dans la colonne server | LastChk le type de monitoring L7.

Voici un exemple tiré de la documentation HAProxy :

# Relay HTTPS traffic to Apache instance and check service availability
# using HTTP request "OPTIONS * HTTP/1.1" on port 80.
backend https_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www
    server apache1 192.168.1.1:443 check port 80

Je trouve cet exemple très intéressant dans le sens ou l'on check le port 80 alors que la VIP est en 443 (HTTPS), on a l'avantage de ne pas surcharger le serveur de backend avec la négociation SSL.

Autres options

En dehors du type de check, il est possible de positionner d'autres options comme inter (l’intervalle de temps entre deux checks) et fall (nombre de check échouée avant de considérer le serveur backend indisponible).

backend bk_apache
        balance roundrobin
        mode http
        server apache1 10.0.0.1:80 check inter 10000 fall 10
        server apache2 10.0.0.2:80 check inter 5000 fall 1
        server apache3 10.0.0.3:80 check

inter est de 2000 ms par défaut, il est possible de spécifier d'autres unités : us, ms, s, m, h, d.
fall vaut 3 par défaut.

Résultat des statistiques :

J'ai volontairement exagéré les valeurs des paramètres pour voir leurs impacts.
Dans la copie d'écran on voit bien apache2 être mis DOWN, alors que apache1 est vu comme allant être bientôt DOWN (c'est la phase fastinter qui est paramétrable) mais des requêtes lui sont encore envoyés donc la page que reçoit l'internaute n'est pas entière !