Comment configurer la vérification de l'état http de Nginx

Vérifications passives

Pour les vérifications de santé passives, nginx et nginx plus surveillent les événements au fur et à mesure qu'ils se produisent et tentent de récupérer les connexions échouées. Si cela ne fonctionne toujours pas, nginx open source et nginx plus marqueront le serveur comme indisponible et cesseront temporairement de lui envoyer des requêtes jusqu'à ce qu'il soit à nouveau marqué actif.

Les conditions dans lesquelles un serveur en amont est marqué comme indisponible sont définies pour chaque serveur en amont avec le paramètre en amont de la directive serveur dans le bloc :

• fail_timeout - Définit le temps après lequel plusieurs tentatives infructueuses doivent être effectuées lorsqu'un le serveur est marqué comme indisponible et l'heure à laquelle le serveur est marqué comme indisponible (la valeur par défaut est de 10 secondes).

• max_fails - Définit le nombre de tentatives infructueuses qui doivent se produire pendant fail_timeout pour que le serveur soit marqué comme indisponible (la valeur par défaut est 1 tentative). Dans l'exemple suivant, si nginx ne parvient pas à envoyer une requête au serveur ou ne reçoit pas de réponse 3 fois dans les 30 secondes, cela signifie que le serveur est indisponible dans les 30 secondes :

upstream backend {
  server backend1.example.com;
  server backend2.example.com max_fails=3 fail_timeout=30s;
}

Il est à noter que s'il y a n'est qu'un seul groupe de serveurs, les paramètres fail_timeout et max_fails sont ignorés et le serveur n'est jamais marqué comme indisponible.

Démarrage lent du serveur

Les serveurs récemment restaurés peuvent facilement être inondés de connexions, ce qui peut entraîner à nouveau le serveur comme indisponible. Le démarrage lent permet à un serveur en amont de restaurer progressivement son poids de zéro à sa valeur nominale après sa récupération ou sa disponibilité. Cela peut être fait en spécifiant le paramètre slow_start du module serveur en amont :

upstream backend {
  server backend1.example.com slow_start=30s;
  server backend2.example.com;
  server 192.0.0.1 backup;
}

Remarque : S'il n'y a qu'un seul serveur dans le groupe, le paramètre slow_start sera ignoré et le serveur ne sera jamais marqué comme indisponible. Le démarrage lent est une fonctionnalité exclusive de nginx plus

Vérifications proactives de nginx plus

nginx plus peut vérifier régulièrement l'état des serveurs en amont en envoyant des demandes de contrôle de santé spéciales à chaque serveur et en vérifiant la réponse correcte.

Pour activer les contrôles de santé actifs :

1. Dans le bloc d'emplacement transmettant les requêtes (proxy_pass) au groupe en amont, incluez la directive health_check :

server {
 location / {
   proxy_pass http://backend;
   health_check;
 }
}

Cet extrait définit un serveur qui gérera toutes les requêtes. Correspond à l'emplacement/en amont. groupe transmis au backend d’appel. Il permet également une surveillance avancée de l'état à l'aide de la directive health_check : par défaut, nginx plus envoie une requête "/" à chaque serveur du backend du groupe toutes les cinq secondes.

Si une erreur de communication ou un délai d'attente se produit (le code d'état renvoyé par le serveur est en dehors de la plage 200-399), la vérification de l'état échoue. Le serveur est marqué comme défectueux et nginx plus ne lui enverra pas de requêtes client tant qu'il n'aura pas réussi à nouveau la vérification de l'état.

Une autre option facultative : vous pouvez spécifier un autre port pour les contrôles de santé, par exemple, pour surveiller la santé de nombreux services sur le même hôte. Spécifiez le nouveau port à l'aide du paramètre port de la directive health_check :

server {
 location / {
   proxy_pass  http://backend;
   health_check port=8080;
 }
}

2. Dans le groupe de serveurs en amont, utilisez la directive zone pour définir une zone de mémoire partagée :

http {
 upstream backend {
   zone backend 64k;
   server backend1.example.com;
   server backend2.example.com;
   server backend3.example.com;
   server backend4.example.com;
 }
}

Cette zone est partagée entre tous les processus de travail et stocke le configuration du groupe amont. Cela permet aux processus de travail d'utiliser le même ensemble de compteurs pour suivre les réponses des serveurs du groupe.

La valeur par défaut des contrôles de santé actifs peut être remplacée à l'aide de l'argument de la directive health_check :

location / {
  proxy_pass http://backend;
  health_check interval=10 fails=3 passes=2;
}

Ici, l'argument interval augmente le délai entre les contrôles de santé de 5 secondes par défaut à 10 secondes. Le paramètre fails nécessite que le serveur échoue à trois vérifications de l'état afin de le marquer comme non sain (en commençant par la valeur par défaut). Enfin, le paramètre pass signifie que le serveur doit passer deux vérifications consécutives avant de pouvoir à nouveau être marqué comme sain, au lieu de la valeur par défaut.

Spécifiez l'url demandée

Spécifiez le paramètre uri dans la directive health_check pour définir l'itinéraire de la demande de vérification de l'état :

location / {
  proxy_pass http://backend;
  health_check uri=/some/path;
}

L'uri spécifié sera ajouté au nom de domaine du serveur ou à l'adresse IP définie pour le serveur dans le bloc amont. Pour le premier serveur du groupe d'échantillons backend déclaré ci-dessus, la vérification de l'état demande l'uri http://backend1.example.com/some/path.

Définir des conditions personnalisées

Vous pouvez définir des conditions personnalisées qu'une réponse doit remplir pour que le serveur réussisse le contrôle de santé. Les conditions sont définies dans un bloc de correspondance, qui est référencé dans l'argument de la directive health_check.

1. Au niveau http {}, précisez le bloc match {} et donnez-lui un nom, par exemple : 'server_ok'

http {
 #... 
 match server_ok {
   # tests are here     
 }
}

2.health_check en précisant le paramètre match du bloc et le nom de la correspondance bloc de paramètres :

http {
 #... 
 match server_ok {
   status 200-399;
   body !~ "maintenance mode";
 }
 server {
   #...     
   location / {
     proxy_pass http://backend;
     health_check match=server_ok;
   }
 }
}

if Le contrôle de santé est réussi si le code d'état de la réponse est compris entre 200 et 399 et que son corps ne contient pas la chaîne : 'mode maintenance'

La directive match permet à nginx plus de vérifier le code d'état , les champs d'en-tête et le corps de la réponse. Utilisez cette directive pour vérifier que l'état se situe dans la plage spécifiée, que la réponse contient des en-têtes ou que les en-têtes ou le corps correspondent à une expression régulière. La directive match peut contenir une condition de statut, une condition de corps et plusieurs conditions de titre. La réponse doit remplir toutes les conditions définies dans le bloc de correspondance pour que le serveur réussisse le contrôle de santé.

例如，下面的 match 指令匹配有状态代码响应 200，精确值 text/html 的content-type 标题，页面中的文字：'welcome to nginx!'.

match welcome {
  status 200;
  header content-type = text/html;
  body ~ "welcome to nginx!";
}

以下示例使用感叹号（!）来定义响应不得通过运行状况检查的特征。在这种情况下，健康检查在非 301，302，303，或 307状态码，同时并没有 refresh 头信息时将通过检查，。

match not_redirect {
  status ! 301-303 307;
  header ! refresh;
}

健康检查可以在其他非 http 协议中启用, 例如 fastcgi, , scgi,  甚至 tcp 和 udp。

很多很好的特性，就是需要 nginx plus 才能使用。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!