Comment résoudre le problème de 499 et l'échec du mécanisme de basculement causé par une configuration nginx incorrecte

La signification et les raisons possibles de 499

499 n'est en fait pas le code d'état standard du protocole HTTP, mais un code d'état personnalisé de nginx. Je n'ai pas trouvé d'explication claire de ce code d'état dans le nginx officiel. documentation, ici Pour citer une explication tirée d'un article de blog qui semble plus professionnel :

L'erreur HTTP 499 signifie simplement que le client s'est arrêté au milieu du traitement de la demande via le serveur. Le code d'erreur 499 met mieux en lumière le fait que quelque chose s'est produit. avec le client, c'est pourquoi la demande ne peut pas être effectuée. Alors ne vous inquiétez pas : le code de réponse HTTP 499 n'est pas du tout de votre faute.

L'idée générale est que 499 signifie généralement que le client met activement fin au processus de traitement pendant ce temps. la requête HTTP est toujours en cours de traitement-- La connexion réseau correspondante est déconnectée 499 signifie généralement que certains problèmes sont survenus côté client et n'ont rien à voir avec le serveur.
Ce qui suit est un commentaire dans le code source de nginx :

/*
* HTTP does not define the code for the case when a client closed
* the connection while we are processing its request so we introduce
* own code to log such situation when a client has closed the connection
* before we even try to send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST     499

Cela signifie que nginx a introduit un code personnalisé 499 pour enregistrer le scénario dans lequel nginx n'a pas fini de traiter sa demande lorsque le client se déconnecte.
Je me souviens que lorsque j'ai rencontré pour la première fois le scénario 499 il y a de nombreuses années, j'ai également vu des réponses similaires lors de la recherche d'informations sur Internet, j'ai donc toujours pensé que 499 n'avait pas grand-chose à voir avec le serveur, et que tout cela devrait être causé par le client.

Un exemple du comportement proactif d'un client menant à 499

J'ai rencontré une fois une interface de recherche Lenovo, et son ratio 499 était des dizaines de fois supérieur à celui des autres API - Yiqi Juechen, en regardant cette API seule, elle est restée essentiellement à l'alarme seuil depuis longtemps Ci-dessus, nous avons également suivi les raisons spécifiques de l'anomalie, et avons finalement travaillé avec les partenaires clients pour arriver à la conclusion : Il est normal que le ratio 499 soit élevé lors de la recherche de l'interface Lenovo, car :

• Le scénario d'appel de cette API est lorsque l'utilisateur recherche dans le champ de recherche. Lors de la saisie d'un terme de recherche, chaque fois que l'utilisateur saisit un caractère, l'API sera immédiatement appelée avec la dernière entrée et les résultats d'association renvoyés seront affiché à l'utilisateur, réalisant ainsi une fonction d'association de recherche en temps quasi réel.

• Étant donné qu'à chaque fois que l'utilisateur saisit un nouveau caractère, la dernière demande d'appel API est déclenchée, même si la demande d'appel précédente est toujours en cours, le client doit directement mettre fin à ces anciennes demandes qui n'ont aucun effet réel. dans nginx Le journal affiche 499 indiquant que le client s'est activement déconnecté.

Ainsi, bien que la recherche de l'API Lenovo soit différente de l'API normale avec un ratio élevé de 499, elle est tout à fait raisonnable. Le client est responsable de la déconnexion active, mais il n'a rien fait de mal et il n'y a pas de problème. avec le serveur.

Un exemple de comportement passif du client provoquant 499

Un autre exemple de comportement client précédemment considéré comme provoquant 499 est le pic de poussée. Certains utilisateurs peuvent tuer l'application instantanément après avoir ouvert l'application via le push. Pendant la période de pointe de poussée, le serveur général. La pression est relativement élevée. La réponse elle-même sera plus lente que pendant les périodes de pointe. À ce moment-là, certaines requêtes API peuvent être encore en cours. À ce moment-là, l'utilisateur tue l'application - l'application meurt injustement et est impuissante - la connexion correspondante. est naturellement déconnecté et recyclé par le système d'exploitation, il en résulte donc également 499. Il n'y a aucun problème côté serveur dans ce scénario.

Les problèmes côté serveur peuvent provoquer 499 ?

D'après les deux exemples ci-dessus, à première vue, 499 est causé par le côté client, qu'il s'agisse d'un comportement actif ou passif. Ce sont ces deux exemples qui renforcent la conscience du blogueur que le serveur 499 ne devrait pas être responsable.
Pour résumer les codes d'erreur nginx qui peuvent être causés par des erreurs côté serveur, il doit s'agir principalement des scénarios suivants :

• 500 : Erreur interne, généralement les paramètres de la requête provoquent directement l'erreur de code d'exécution du thread de traitement en amont, et le le code commercial ou le framework renvoie directement une erreur interne

• 502 : généralement, le serveur en amont se bloque directement et ne peut pas être connecté en amont, il retourne donc à Bad Gateway

• 503 : la charge en amont est trop élevée, mais il ne se bloque pas et revient directement au service indisponible

• 504 : En amont prend trop de temps pour traiter la demande. nginx attend le retour en amont, expire et revient à Gateway Timeout

Alors, s'il s'agit d'une exécution de code. erreur, le service se bloque, le service est trop occupé ou le traitement de la demande prend trop de temps, ce qui entraîne l'échec de la demande HTTP. Le 5XX renvoyé ne déclenchera pas du tout 499.
C'est effectivement le cas en général, mais le nouveau Pingfeng 499 n'est cette fois pas une situation générale. Lors de la recherche d'informations sur Internet, certaines personnes ont suggéré que nginx 499 pourrait être dû au fait que le serveur prend trop de temps à traiter, ce qui entraîne le client se déconnecte activement après l'expiration du délai. Mais selon la description ci-dessus, cette situation ne devrait pas appartenir au scénario 4 : le traitement de la demande en amont prend trop de temps, donc nginx renvoie 504, n'est-ce pas ?
Il semble donc que le traitement côté serveur prenne trop de temps, ce qui peut amener le client à déconnecter activement 499, ou nginx à renvoyer Gateway Timeout 504. Alors, quel est le facteur clé conduisant à cette différence ?
Pour faire simple, si le client se déconnecte en premier et est détecté par nginx, ce sera 499. Si l'amont prend trop de temps et que le délai d'attente est d'abord déterminé par nginx, ce sera 504. La clé est donc le réglage de l'heure de nginx pour délai d'attente en amont. Cliquez ici et dépêchez-vous. Après avoir examiné la configuration liée au délai d'attente de nginx, eh bien, le délai d'expiration correspondant n'est pas explicitement configuré - !

Configuration du délai d'attente lié à la détermination 504 dans nginx

Étant donné que l'API et nginx communiquent via le protocole uwsgi, les principaux paramètres de configuration du délai d'attente sont les suivants :

Syntax:	uwsgi_connect_timeout time;
Default:	
uwsgi_connect_timeout 60s;
Context:	http, server, location
Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.
Syntax:	uwsgi_send_timeout time;
Default:	
uwsgi_send_timeout 60s;
Context:	http, server, location
Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.
Syntax:	uwsgi_read_timeout time;
Default:	
uwsgi_read_timeout 60s;
Context:	http, server, location
Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.

在未明确指定的情况下其超时时间均默认为60s，简单来说（实际情况更复杂一些但这里不进一步探讨）只有在upstream处理请求耗时超过60s的情况下nginx才能判定其Gateway Timeout 并按照504处理，然而客户端设置的HTTP请求超时时间其实只有15s--这其中还包括外网数据传输的时间，于是问题来了：每一个服务端处理耗时超过15s的请求，nginx由于还没达到60s的超时阈值不会判定504，而客户端则会由于超过本地的15s超时时间直接断开连接，nginx于是就会记录为499。
通过回查nginx log，非高峰期的499告警时段确实是存在单台upstream 请求处理缓慢，耗时过长，于是可能导致：

• 用户在需要block等待请求的页面等待虽然不到15s但是已经不耐烦了，直接采取切页面或者杀死app重启的方式结束当前请求。

• 用户耐心等待了15s、或者非阻塞的后台HTTP请求超过了15s超过超时阈值主动断开连接结束了当前请求。

服务端耗时过长导致的499

上面已经知道近期新出现的单台upstream 偶发499是由于响应缓慢引起的，既然是由于客户端超时时间(15s)远小于nginx upstream超时时间(60s)引起的，这应该属于一个明显的配置不当，会导致三个明显的问题：

• 将用户由于各种原因(如杀app)很快主动断开连接导致的499与客户端达到超时时间(这里是15s)导致的499混在了一起，无法区分客户端责任与服务端责任导致499问题。

• 对于nginx判定为499的请求，由于认为是客户端主动断开，不会被认为是服务端导致的unsuccessful attempt而被计入用于failover判定的max_fails计数中，所以即便一个upstream大量触发了499，nginx都不会将其从可用upstream中摘除，相当于摘除不可用节点的功能失效，而由于负载过高导致499的upstream收到的请求依然不断增加最终可能导致更大的问题。

• 对于判定为499的请求，也是由于不会被认为是unsuccessful attempt，所以uwsgi_next_upstream这一配置也不会work，于是当第一个处理请求的upstream耗时过长超时后，nginx不会尝试将其请求转发为下一个upstream尝试处理后返回，只能直接失败。

那是不是把客户端超时时间调大？或者把nginx upstream超时时间调小解决呢？
调大客户端超时时间当然是不合理的，任何用户请求15s还未收到响应肯定是有问题的，所以正确的做法应该是调小upstream的超时时间，一般来说服务端对于客户端请求处理时间应该都是在数十、数百ms之间，超过1s就已经属于超长请求了，所以不但默认的60s不行，客户端设置的15s也不能用于upstream的超时判定。
最终经过综合考虑服务端各api的耗时情况，先敲定了一个upstream 5s的超时时间配置--由于之前没有经验首次修改步子不迈太大，观察一段时间后继续调整，这样做已经足以很大程度解决以上的3个问题：

• 将用户由于各种原因(如杀app)很快主动断开连接导致的499与nginx达到upstream超时时间时主动结束的504区分开了。

• 504会被纳入max_fails计算，触发nginx摘除失败节点逻辑，在单台机器故障响应缓慢时可以被识别出来暂时摘除出可用节点列表，防止其负载进一步加大并保证后续请求均被正常可用节点处理返回。

• 当nginx等待upstream处理达到5s触发超时时，其会按照uwsgi_next_upstream配置尝试将请求(默认仅限幂等的GET请求)转交给下一个upstream尝试处理后返回，这样在单一upstream由于异常负载较高超时时，其他正常的upstream可以作为backup兜底处理其超时请求，这里客户端原本等待15s超时的请求一般在5~10s内可以兜底返回。

通过proxy_ignore_client_abort配置解决499问题？

在网上查找资料时还有网友提出解除nginx 499问题的一个思路是设置proxy_ignore_client_abort参数，该参数默认为off，将其设置为on 后，对于客户端主动断开请求的情况，nginx会ignore而以upstream实际返回的状态为准，nginx官方文档说明如下：

Syntax:	proxy_ignore_client_abort on | off;
Default:	
proxy_ignore_client_abort off;
Context:	http, server, location
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.

但是在客户端主动断开连接时，设置这个参数的意义除了使nginx log中记录的状态码完全按照upstream返回确定，而非表示客户端断连的499之外，对于实际问题解决完全没有任何帮助，感觉颇有把头埋进沙子的鸵鸟风格，不知道这个参数设置到底会有什么实用的场景。

La raison pour laquelle un seul amont répond parfois lentement et expire pendant les périodes creuses

C'est une bonne question. Ce problème n'est apparu que récemment. Après avoir résolu le problème de non-concordance nginx mentionné ci-dessus, j'ai essayé de résoudre ce problème. Du point de vue du phénomène, ce sont certaines requêtes spécifiques qui déclenchent des surtensions du processeur en amont, et la réponse lente affecte en outre le traitement des requêtes ultérieures, provoquant finalement une réponse lente de toutes les requêtes et le déclenchement du client 499.
Une fois le problème d'incompatibilité de nginx résolu, si le délai d'attente lent d'un seul problème d'accès en amont se reproduit, nginx supprimera rapidement le problème en amont via le basculement pour éviter une détérioration supplémentaire de la situation, et la demande GET pour le délai d'expiration en amont du premier problème d'accès sera également être sauvegardé. Le transfert vers d'autres amonts disponibles pour traitement puis retour a considérablement réduit l'impact de telles exceptions.
Enfin, après avoir corrigé la configuration, des exceptions occasionnelles dans un seul amont déclencheront un petit nombre d'alarmes de seuil 504 pour certaines API POST une fois tous les quelques jours. La cause première du problème est toujours en cours d'exploration.

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!