web-dev-qa-db-fra.com

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

Je reçois actuellement un flux HTTP assez important en ce moment, et cela provoque mon proxy inverse nginx à produire une 502 Bad Gateway.

J'ai un serveur frontal exécutant nginx en tant que proxy de mon serveur principal, mais il ne fait qu'obtenir un tas d'erreurs connect() failed (110: Connection timed out) while connecting to upstream. Des tonnes d'entre eux. Si je contourne le serveur proxy pour me connecter au backend, je peux très bien exécuter le site, donc je sais qu'il se trouve quelque part dans le proxy inverse. Cependant, je n'ai aucune idée de la façon de déterminer pourquoi le délai expire.

De l'aide?

exécution de nginx 1.2.3 sur CentOS 6.2

nginxreverse-proxy
35
Rob

Je suppose que vous avez déjà augmenté votre niveau de journalisation des erreurs Nginx pour le déboguer. Sinon, commencez par là.

Votre meilleur pari sera probablement d'utiliser strace pour afficher les appels système effectués par Nginx. En particulier, vous voudrez faire attention aux appels connect() et garder un œil sur les codes retour de ces derniers (man 2 connect peut être votre ami ici).

Une fois que vous avez ces informations, vous pouvez mieux faire une supposition éclairée pour savoir si le problème est limité à votre proxy frontal ou a quelque chose à voir avec les interactions entre le proxy et le serveur d'applications principal.

20
jgoldschrafe

Cela ne devient pas beaucoup plus pédant que cela, sauf si vous voulez mettre des sondes dtrace:

  1. Définissez le niveau du journal de débogage: /etc/nginx/nginx.conf:

    ...
http {
        ...
        error_log /var/log/nginx/error.log debug; # todo testing remove me not for production use
        ...
}

  2. Configurez tcpdump dans une autre fenêtre:

    tcpdump not port 22 -vvv -s0 -q -XXX

  3. Surveillez les fichiers journaux dans une autre fenêtre:

    tail -f /var/log/nginx/*

  4. Démarrage nginx interactivement avec strace:

    # top of /etc/nginx/nginx.conf:

daemon off; # todo testing remove me not for production use

    Et alors

     $ strace nginx

Un débogage supplémentaire peut être effectué avec un nginx compilé avec --with-debug. Vérifiez-le 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 . Selon toute vraisemblance, toute configuration décente nécessitera un nginx compilé sur mesure (emballage fortement recommandé à l'aide des outils d'emballage de distro).

La plupart d'entre eux ne conviennent pas pour une utilisation en production, regardez la compilation de nginx avec gperf si vous avez besoin de plus de statistiques.

39
user31170

On dirait que vous déboguez un site à fort trafic.

Utilisez debug avec debug_connection directive afin que le journal des erreurs nginx affiche uniquement les journaux de débogage de votre IP.

Une fois que vous commencez à voir des journaux d'erreurs utiles plutôt que d'activer l'option de débogage pour la configuration entière de nginx, ajoutez un error_log /path/to/some/file/ debug; directive dans location {..} bloc responsable de la connexion reverse_proxy.

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

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

Par exemple, veuillez vérifier: https://easyengine.io/tutorials/nginx/debugging/

Un niveau en avant, vous pouvez utiliser Nginx's HttpEchoModule

5
rahul286

Je n'ai jamais trouvé Nginx comme un goulot d'étranglement, dans la plupart des cas, il est plus que capable que les backends. Mais si vous avez testé sans Nginx et n'avez trouvé aucune erreur, alors ce sera soit (ou les deux):

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

Sans voir vos configurations Nginx, personne ne peut commenter la première. Et sans sorties appropriées de l'OS, personne ne peut commenter ce dernier.

2
Ben Lessani - Sonassi