46 votes

Comment puis-je déboguer nginx plus profondément que le journal des erreurs?

Je reçois actuellement une assez grosse attaque HTTP flood en ce moment, ce qui cause à mon proxy inverse nginx de produire un code d'erreur 502 Bad Gateway.

J'ai un serveur frontal qui exécute nginx en tant que proxy vers mon serveur backend, mais il reçoit simplement une série d'erreurs connect() failed (110: Connection timed out) while connecting to upstream. Beaucoup d'entre elles. Si je contourne le serveur proxy pour me connecter au backend, je peux faire fonctionner le site correctement, donc je sais que le problème se trouve quelque part dans le proxy inverse. Cependant, je ne sais pas comment déterminer la cause du timeout.

Quelqu'un peut-il m'aider ?

nginx 1.2.3 sur CentOS 6.2

47voto

Il n'y a rien de plus pédant que cela à moins que vous ne vouliez mettre des sondes dtrace:

  1. Définir le niveau de journalisation détaillé: /etc/nginx/nginx.conf:

    ...
    http {
            ...
            error_log /var/log/nginx/error.log debug; # todo testing remove me not for production use
            ...
    }
  2. Configurer tcpdump dans une autre fenêtre:

    tcpdump not port 22 -vvv -s0 -q -XXX
  3. Surveiller les fichiers journaux dans une autre fenêtre:

    tail -f /var/log/nginx/*
  4. Démarrer nginx de manière interactive avec strace:

    # top of /etc/nginx/nginx.conf:
    
    daemon off; # todo testing remove me not for production use

    Et ensuite

     $ strace nginx 

Un débogage supplémentaire peut être effectué avec un nginx compilé avec --with-debug. Vérifiez en exécutant:

    nginx -V 2>&1 | grep -- '--with-debug' # no output if not debug

Un autre bon module non compilé par défaut est: HttpStubStatusModule. Très probablement, toute configuration correcte nécessitera un nginx compilé sur mesure (recommandé avec les outils d'emballage de la distribution).

La plupart de ces configurations ne conviennent pas à une utilisation en production, consultez la compilation de nginx avec gperf si vous avez besoin de plus de statistiques.

26voto

madcapnmckay Points 8477

Je pars du principe que vous avez déjà augmenté le niveau de journalisation des erreurs de votre Nginx à debug. Si ce n'est pas le cas, commencez par là.

Il serait probablement préférable d'utiliser strace pour visualiser les appels système effectués par Nginx. En particulier, vous voudrez porter une attention particulière aux appels connect(), et surveiller les codes de retour de ces derniers (man 2 connect peut être votre allié ici).

Une fois que vous avez ces informations, vous pourrez mieux faire une supposition éclairée sur le fait que le problème se limite à votre proxy frontal, ou a quelque chose à voir avec les interactions entre le proxy et le serveur d'application en backend.

7voto

MrZebra Points 6508

Il semble que vous déboguez un site à fort trafic.

Utilisez debug avec la directive debug_connection afin que le journal d'erreurs de nginx affiche des journaux de débogage uniquement à partir de votre adresse IP.

Une fois que vous commencez à voir des journaux d'erreurs utiles au lieu d'activer l'option de débogage pour l'ensemble de la configuration nginx, ajoutez une directive séparée error_log /chemin/vers/un/fichier/ debug; dans le bloc location {..} responsable de la connexion reverse_proxy.

De cette façon, vous pourrez isoler le journal d'erreurs de débogage uniquement à partir de votre adresse IP.

Essayez de le relier à la demande que vous faites (depuis votre navigateur).

Par exemple, veuillez consulter : https://easyengine.io/tutorials/nginx/debugging/

Un niveau au-dessus, vous pouvez utiliser le module HttpEchoModule de Nginx

3voto

Ben Lessani Points 5146

Je n'ai jamais trouvé Nginx être un goulot d'étranglement, dans la plupart des cas il est plus que capable que les back-ends. Mais si vous avez testé sans Nginx et n'avez trouvé aucune erreur, alors cela va être soit (ou les deux) :

  1. Problème de configuration de Nginx
    1. Valeur de délai d'attente en amont incorrecte
    2. URL de sonde incorrecte en amont
    3. Trop peu de travailleurs
    4. Etc.
  2. Goulot d'étranglement du système d'exploitation TCP/IP
    1. Il se peut que le proxy lui-même entraîne une duplication des ports ouverts et des états. Que ce soit des descripteurs de fichiers, des ports, des connexions TCP

Sans voir vos configurations Nginx, personne ne peut commenter sur le premier point. Et sans des sorties appropriées de l'OS, personne ne peut commenter sur le second point.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X