Jak mogę debugować nginx dalej niż dziennik błędów?

Obecnie otrzymuję dość duży zalew HTTP, co powoduje, że moje odwrotne proxy nginx wytwarza 502 Złą Bramę.

Mam serwer frontonu z nginxem jako serwerem proxy do mojego serwera backend, ale dostaję mnóstwo connect() failed (110: Connection timed out) while connecting to upstreambłędów. Mnóstwo ich. Jeśli pominę serwer proxy, aby połączyć się z backendem, mogę dobrze uruchomić witrynę, dzięki czemu wiem, że jest gdzieś w odwrotnym proxy. Nie mam jednak pojęcia, jak ustalić, dlaczego upłynął limit czasu.

Jakaś pomoc?

działający nginx 1.2.3 na CentOS 6.2

Zakładam, że podłączyłeś już swój poziom rejestrowania błędów Nginx do debugowania. Jeśli nie, zacznij od tego.

Twój najlepszy zakład prawdopodobnie będzie używany stracedo przeglądania wywołań systemowych wykonywanych przez Nginx. W szczególności należy zwracać uwagę na connect()połączenia i man 2 connectsprawdzać ich kody powrotne (tutaj może być Twój przyjaciel).

Po uzyskaniu tych informacji możesz lepiej odgadnąć, czy problem ogranicza się do serwera proxy frontonu, czy ma coś wspólnego z interakcjami między serwerem proxy a serwerem aplikacji backendu.

Nie robi się o wiele bardziej pedantyczny niż ten, chyba że chcesz umieścić sondy dtrace:

1. Ustaw poziom dziennika debugowania: /etc/nginx/nginx.conf:

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

2. Skonfiguruj tcpdump w innym oknie:

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

3. Monitoruj pliki dziennika w innym oknie:

   tail -f /var/log/nginx/*
   

4. Uruchom nginx interaktywnie za pomocą strace:

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

   I wtedy

    $ strace nginx 
   

Dalsze debugowanie można przeprowadzić za pomocą skompilowanego nginx --with-debug. Sprawdź, uruchamiając:

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

Innym dobrym modułem, który nie jest kompilowany domyślnie jest: HttpStubStatusModule . Najprawdopodobniej każda przyzwoita konfiguracja będzie wymagała skompilowanego na zamówienie nginx (wysoce zalecane opakowanie przy użyciu narzędzi do pakowania distro).

Większość z nich nie nadaje się do użytku produkcyjnego, spójrz na kompilowanie nginx z gperf, jeśli potrzebujesz więcej statystyk.

Wygląda na to, że debugujesz witrynę o dużym ruchu.

Użyj debugzdebug_connection dyrektywą, aby dziennik błędów nginx wyświetlał dzienniki debugowania tylko z twojego adresu IP.

Gdy zaczniesz widzieć przydatne dzienniki błędów zamiast aktywować opcję debugowania dla całej konfiguracji nginx, dodaj osobną error_log /path/to/some/file/ debug;dyrektywę wlocation {..} bloku odpowiedzialnym za połączenie reverse_proxy.

W ten sposób będziesz mógł odizolować dziennik błędów debugowania tylko od adresu IP.

Spróbuj powiązać to z żądaniem, które wysyłasz (z poziomu przeglądarki).

Na przykład sprawdź: https://easyengine.io/tutorials/nginx/debugging/

Na wyższym poziomie możesz użyć HttpEchoModule Nginx

Nigdy nie uważałem Nginx za wąskie gardło, w większości przypadków jest ono bardziej niż zdolne niż zaplecze. Ale jeśli testowałeś bez Nginx i nie znalazłeś błędu, to będzie jeden (lub oba):

1. Problem z konfiguracją Nginx
   1. Błędna wartość limitu czasu wysyłania
   2. Nieprawidłowy adres URL sondy na wcześniejszym etapie
   3. Za mało pracowników
   4. Itp.
2. System operacyjny wąskie gardło TCP / IP
   1. Możliwe, że samo proxy powoduje duplikację otwartych portów i stanów. Czy to deskryptory plików, porty, połączenia TCP

Nie widząc twoich konfiguracji Nginx, nikt nie może komentować tego pierwszego. I bez odpowiednich wyników z systemu operacyjnego nikt nie może komentować tego ostatniego.