Stan stubu NGINX: monitorowanie aktywności serwera WWW w czasie rzeczywistym

Co oznacza status „stub” w NGINX

Stan stubu NGINX udostępnia podstawowe wskaźniki serwera WWW w postaci tekstowej poprzez skonfigurowany punkt końcowy HTTP. Odpowiedź opisuje aktywność zapytanego zespołu procesów NGINX: w szczególności połączenia klienckie oraz łączną liczbę zliczonych żądań. Możesz je pobrać lokalnie i wielokrotnie porównywać bez konieczności wdrażania w tym celu pełnego systemu monitorowania.

W tym kontekście musisz rozróżnić dwa rodzaje wartości: jedną Migawka pokazuje na przykład, ile połączeń klienckich jest aktywnych w momencie wywołania. Liczniki ogólne, takie jak requests podają natomiast, ile zapytań zliczono łącznie. Dopiero porównanie kilku odczytów w znanych odstępach czasu pozwala na określenie częstotliwości zapytań.

Wartości te nie stanowią bezpośredniego pomiaru obciążenia procesora ani pamięci, ani też nie odzwierciedlają procentowej wartości dostępnej wydajności serwera WWW. Duża liczba otwartych połączeń może wynikać z różnych przyczyn i wiązać się z różnymi kosztami. Aby oszacować rzeczywiste obciążenie, potrzebujesz zatem dodatkowych wskaźników dotyczących zasobów oraz informacji o czasach odpowiedzi i błędach.

Stub Status nie rozdziela danych według wirtualnych stron internetowych ani żądanych adresów URL. Jeśli dana instalacja obsługuje kilka witryn, na podstawie samego punktu końcowego nie da się ustalić, która z nich jest odpowiedzialna za wzrost. W przypadku kilku instancji NGINX należy rejestrować ich wartości oddzielnie i jednoznacznie je przyporządkować.

Również samo wywołanie strony stanu stanowi żądanie HTTP i ma niewielki wpływ na obserwowane liczniki. Należy to uwzględnić przy interpretacji niewielkiej liczby żądań lub bardzo częstych zapytań. Pojedyncze wywołanie dostarcza zresztą tylko fragment danych; dopiero przebieg pokazuje, czy aktywność uległa zmianie.

Rozróżnianie połączeń i zapytań

Wartość Aktywne połączenia obejmuje aktywne połączenia klienckie, w tym połączenia oczekujące. Nie uwzględnia więc wyłącznie połączeń, przez które właśnie przesyłana jest odpowiedź. Stany „Reading”, „Writing” i „Waiting” pomagają zinterpretować tę łączną liczbę, ale nie opisują ani obciążenia procesora, ani liczby uruchomionych aplikacji.

W przypadku przychodzącego żądania połączenie znajduje się w stanie „Reading”, podczas gdy NGINX odczytuje nagłówek żądania. Następnie może przejść do stanu „Writing”, gdy NGINX przetwarza lub zapisuje odpowiedź. Nie oznacza to jednak, że przez cały ten czas faktycznie przepływają bajty do klienta: może to również obejmować oczekiwanie na odpowiedź z serwera upstream.

Jeśli po udzieleniu odpowiedzi na kolejne zapytania połączenie pozostaje otwarte, można je potraktować jako Oczekiwanie pojawiają się. Stan ten obejmuje nieaktywne połączenia klienckie, które oczekują na kolejne żądanie. Sama wysoka wartość parametru „Waiting” nie świadczy zatem o przeciążeniu; może ona również wynikać z pracy systemu wykorzystującego wiele ponownie wykorzystywanych połączeń.

Połączenia i żądania to różne wielkości: przez jedno połączenie typu keepalive może przebiegać kolejno kilka żądań. W protokole HTTP/2 za pośrednictwem jednego połączenia można przesyłać wiele żądań. Na podstawie liczby otwartych połączeń nie można zatem określić stałej liczby żądań, a licznik żądań nie musi rosnąć w tym samym tempie co liczniki połączeń.

W celu praktycznej oceny warto przeanalizować dane z kilku wywołań: jeśli wskaźnik „Waiting” rośnie, a czasy odpowiedzi i liczba błędów pozostają na niezmienionym poziomie, jest to na razie jedynie spostrzeżenie, a nie powód do niepokoju. Jak skonfigurować ponowne wykorzystanie i jego ograniczenia, wyjaśnia artykuł poświęcony Żądania Keepalive w NGINX.

Sprawdź moduł i wersję

Aby korzystać z funkcji Stub Status, potrzebujesz zainstalowanego serwera NGINX z modułem ngx_http_stub_status_module, dostęp do jego konfiguracji, a później możliwość sprawdzenia chronionego punktu końcowego z przewidzianej przestrzeni sieciowej. Moduł ten nie jest domyślnie włączany podczas kompilacji NGINX. To, czy dany pakiet dystrybucyjny go zawiera, zależy od konkretnego pakietu i należy to sprawdzić lokalnie.

W terminalu sprawdź wersję oraz parametry konfiguracyjne pliku binarnego NGINX faktycznie używanego przez usługę. Poniższe polecenie wyświetla te informacje; wśród parametrów znajduje się --with-http_stub_status_module na odpowiednią opcję kompilacji.

nginx -V

Decydującym czynnikiem jest prawidłowy plik binarny: Uruchomiony poprzez ścieżkę wyszukiwania nginx może to być inna instalacja niż ta, z której korzysta usługa. W razie wątpliwości sprawdź konfigurację usługi i sposób uruchamiania programu w niej zastosowany. Następnie, w razie potrzeby, uruchom bezpośrednio odpowiedni plik binarny, zamiast wyciągać wnioski na temat usługi produkcyjnej na podstawie wyników innej instalacji.

Również wersja ma wpływ na sposób zapisu dyrektywy. Od wersji NGINX 1.7.5 stosuje się stub_status używane bez argumentu; starsze wersje wymagały dowolnego argumentu, na przykład on. Ograniczenie dotyczące wersji stanowi informację dotyczącą zgodności, a nie założenie co do tego, która wersja jest zainstalowana w Twoim systemie.

Jeśli w sprawdzanej instalacji brakuje opcji kompilacji, przed wprowadzeniem zmian w konfiguracji należy ustalić, jaki pakiet lub kompilacja są przewidziane w danym środowisku. Sama lokalizacja statusu nie uzupełnia brakującego modułu. Zmiany w pakietach i konfiguracji usług powinny być dokonywane zgodnie z obowiązującą procedurą eksploatacyjną i zatwierdzającą.

Konfiguracja chronionego punktu końcowego statusu

Aby sprawdzić stan lokalny, możesz użyć osobnego Słuchacz pętli zwrotnej skonfigurować. Poniższy przykład przedstawia plik konfiguracyjny dla istniejącego http-kontekst, nie polecenie terminala. Wymaga to, aby moduł stanu stub był dostępny, a przykładowy port 8088 pod danym adresem nie był już zajęty przez inną usługę.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

    location = /stub_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

Powiązanie z 127.0.0.1 ogranicza ten moduł nasłuchujący do lokalnego interfejsu pętli zwrotnej IPv4. Dokładna lokalizacja określa jedynie podaną ścieżkę; dyrektywa stub_status dostarcza tam dane o stanie. Dzięki temu nie można uzyskać dostępu do modułu nasłuchującego przez inne interfejsy IPv4, niezależnie od tego, czy pozostałe strony internetowe są publicznie dostępne.

Die Zasady dostępu uzupełniają regułę: NGINX sprawdza je po kolei, aż do pierwszego trafienia. Dopuszczalny jest lokalny adres IPv4, wszystkie pozostałe adresy są odrzucane. Ponieważ w tej lokalizacji znajdują się własne reguły, reguły dostępu z nadrzędnego kontekstu nie są dodatkowo dziedziczone. Dlatego przed zastosowaniem tego przykładu sprawdź pełną konfigurację.

W przypadku kontenerów kluczowe znaczenie ma przestrzeń sieciowa: eksporter w oddzielnym kontenerze uzyskuje dostęp poprzez własny localhost Zazwyczaj nie jest to interfejs pętli zwrotnej kontenera NGINX. Aby uzyskać zdalny dostęp, potrzebujesz specjalnie zaplanowanej prywatnej ścieżki połączenia oraz odpowiednich mechanizmów kontroli dostępu. Nie udostępniaj strony stanu publicznie; zawiera ona informacje operacyjne.

Sprawdź konfigurację i pobierz informacje o stanie

Po wprowadzeniu danych sprawdź najpierw konfigurację w terminalu. Poniższe polecenie sprawdza poprawność składni i próbuje otworzyć pliki, do których odwołuje się konfiguracja. Należy przy tym użyć pliku binarnego NGINX odpowiedniego dla danej usługi oraz, w razie potrzeby, odmiennej ścieżki konfiguracyjnej; pomyślne zakończenie sprawdzania nie powoduje jeszcze aktywacji zmiany.

nginx -t

A zatwierdzone ponowne ładowanie jest to osobny krok produkcyjny. Wykonaj go dopiero po uzyskaniu zgody i zgodnie z procedurami operacyjnymi obowiązującymi w Twoim środowisku. Podczas operacji reload NGINX ponownie ładuje konfigurację, uruchamia nowe procesy robocze z nową konfiguracją i w uporządkowany sposób zamyka stare procesy robocze. Następnie sprawdź, czy operacja zakończyła się powodzeniem, oraz przejrzyj logi, zamiast wnioskować o aktywnej zmianie na podstawie pomyślnego wyniku sprawdzania składni.

Po zatwierdzeniu aktywacji możesz połączyć się lokalnie z punktem końcowym w tej samej przestrzeni sieciowej za pomocą curl sprawdzić. Przełącznik -i wyświetla nie tylko treść odpowiedzi, ale także status HTTP i nagłówki. Poniższy przykład zakłada, że słuchacz i ścieżka zostały określone w pliku konfiguracyjnym.

curl -i http://127.0.0.1:8088/stub_status

Oczekuje się pomyślnej odpowiedzi HTTP zawierającej dane o statusie w postaci Tekst, a nie w formacie JSON. W razie błędu kod statusu i logi NGINX pomagają w zawężeniu zakresu poszukiwań. Pomyślne pobranie danych lokalnie wskazuje jednak jedynie, że ta ścieżka dostępu działa: nie dowodzi to, że żadna inna konfiguracja nie umożliwia dostępu do punktu końcowego z zewnątrz.

Odczytywanie wartości stanu i obliczanie częstotliwości

Wynik łączy aktualne stany połączeń z wartościami zsumowanymi. Dla interpretacji to rozróżnienie jest ważniejsze niż bezwzględna wielkość pojedynczej wartości: Jedno wartość chwilowa opisuje stan w momencie wywołania, a licznik ogólny – liczbę zdarzeń zarejestrowanych do tego momentu. Tabela przedstawia poszczególne pola oraz typowe błędne wnioski.

Z licznika requests można obliczyć średnią Wskaźnik zapytań Obliczanie dla przedziału czasu: odejmij pierwszą wartość od drugiej, a następnie podziel różnicę przez liczbę upływających sekund. Przykład obliczeniowy, nie jest to pomiar: jeśli wartość wzrośnie w ciągu 60 sekund z 12 000 do 12 600, to 600 podzielone przez 60 daje średnio 10 zapytań na sekundę.

Średnia ta nie odzwierciedla ani najwyższego krótkotrwałego szczytu, ani tego, które adresy URL zostały wywołane. Dla każdego wywołania zanotuj czas oraz instancję, do której nastąpiło wywołanie. Jeśli licznik maleje lub przełączasz się między instancjami, nie wolno interpretować zwykłej różnicy jako wskaźnika bez weryfikacji; dla danej instancji należy rozpocząć nową serię porównawczą.

Jeśli porównujesz przedziały o różnej długości, w każdym przypadku należy uwzględniać faktycznie upływający czas, a nie planowaną częstotliwość odczytów. Na przykład opóźnione odczytanie o ponad dwie minuty wymaga innego dzielnika niż odczytanie po upływie jednej minuty. Dłuższy okres obserwacji silniej wygładza krótkoterminowe wahania; krótkie przedziały czasowe uwidaczniają zmiany, ale zwiększają liczbę zapytań o status.

Również samo sprawdzenie statusu jest żądaniem HTTP i ma niewielki wpływ na obserwowane liczniki. Ma to szczególne znaczenie w przypadku bardzo małego natężenia ruchu lub częstych zapytań. Regularny, udokumentowany interwał między zapytaniami ułatwia uwzględnienie takich elementów monitorowania podczas oceny.

W przypadku wielu instancji należy najpierw obliczyć wskaźnik na podstawie kolejnych wartości każdej z instancji. Dopiero potem można połączyć wskaźniki dla porównywalnych okresów. Jeśli brakuje odczytu lub zmienia się przypisanie instancji, powstała luka powinna pozostać widoczna, zamiast symulować pozornie ciągły przebieg.

Analiza błędów i ograniczeń

Jeśli punkt końcowy stanu zwraca kod HTTP 403, najpierw sprawdź rzeczywisty adres źródłowy docierający do serwera NGINX oraz reguły dostępu dla danej lokalizacji. allow oraz deny są analizowane po kolei aż do momentu wystąpienia pierwszego trafienia. Własne reguły w lokacji zastępują w razie potrzeby reguły odziedziczone; nie uzupełniają ich automatycznie.

W przypadku błędu HTTP 404 należy najpierw sprawdzić inne elementy: czy port i listener, żądana ścieżka oraz wybrany blok serwerów są prawidłowe? Sprawdź również, czy po ponownym załadowaniu strona przewidziana w konfiguracji jest rzeczywiście aktywna. Pomyślne wywołanie lokalne na innym porcie lub ścieżce nie oznacza, że nawiązano połączenie z żądaną lokalizacją.

Jeśli nie otrzymano żadnej odpowiedzi HTTP, należy odróżnić dostępność słuchacza od odpowiedzi ze statusem błędu. Najpierw sprawdź adres, port i przestrzeń sieciową procesu wysyłającego żądanie, a także stan usługi. Dopiero po nawiązaniu połączenia z właściwym odbiorcą status HTTP i wybrana lokalizacja pomogą w dalszym zawężaniu zakresu poszukiwań.

W celu bieżącej analizy błędów warto porównać liczniki ogólne przyjmuje i przetwarza. Zazwyczaj są one takie same. Jeśli różnica między nimi rośnie, może to oznaczać, że osiągnięto limit zasobów; samo porównanie liczników nie wskazuje jednak ani konkretnej przyczyny, ani liczby odrzuconych żądań HTTP. Dlatego w ramach analizy należy uwzględnić logi błędów i konfigurację.

Istniejąca różnica wskazuje początkowo jedynie na różnicę między wartościami obu liczników sumujących. Aby ocenić, czy sytuacja uległa zmianie w obserwowanym okresie, porównaj tę różnicę przy kilku wywołaniach tej samej instancji. Zanotuj ten okres, aby móc wyszukać odpowiednie wpisy w dzienniku i zdarzenia operacyjne.

Dyrektywa worker_connections ogranicza liczbę połączeń na pracownika, a nie wyłącznie połączeń klienckich. Obejmuje to na przykład również połączenia z serwerami proxy; dodatkowo ograniczenia mogą wynikać z limitów deskryptorów plików. Liczba aktywnych połączeń podzielona przez liczbę pracowników razy worker_connections W związku z tym nie można uzyskać wiarygodnych danych dotyczących wykorzystania mocy produkcyjnych. Zamiast tego sprawdź rzeczywiste limity oraz pozostałe zużycie zasobów w danym kontekście.

Zmiana limitów połączeń nie powinna opierać się wyłącznie na wysokiej wartości statusu. Najpierw należy ustalić, czy limit rzeczywiście został osiągnięty oraz jakie inne zasoby lub połączenia upstream są w to zaangażowane. Ewentualne zmiany należy planować, monitorując jednocześnie błędy i czasy odpowiedzi, a następnie zweryfikować je zgodnie z przewidzianą procedurą operacyjną.

Klasyfikowanie przebiegów i problemów na wcześniejszych etapach procesu

Pojedyncze sprawdzenie stanu odzwierciedla jedynie jeden moment w czasie. Natomiast powtarzające się zapytania w stałych odstępach czasu pomagają rozpoznać, czy stan połączeń wzrasta powyżej normalnego poziomu lub czy po osiągnięciu szczytu znów spada. Rejestruj osobno kilka instancji NGINX i odnotowuj, która instancja odpowiada za każdą serię czasową; w przeciwnym razie zmiany między punktami końcowymi mogą zafałszować przebieg danych.

Wysoki Wartość oczekiwania Określa połączenia klientów oczekujące, które są obecnie nieaktywne. Samo w sobie nie stanowi to dowodu na przeciążenie: w przypadku ponownego wykorzystania połączeń klienci mogą czekać na kolejne żądania. Wzrost tego wskaźnika staje się bardziej miarodajny, gdy porównasz go z czasami odpowiedzi, liczbą błędów i wskaźnikami wykorzystania zasobów w tym samym okresie.

Pozostaje Pisanie Jeśli obciążenie utrzymuje się na podwyższonym poziomie przez dłuższy czas, należy sprawdzić zarówno czasy odpowiedzi z serwerów upstream, jak i zachowanie klientów. Stan ten nie oznacza, że bajty są wysyłane w sposób ciągły; może on również obejmować czas oczekiwania na odpowiedź upstream. Stan „Stub” nie określa ani danej usługi backendowej, ani przyczyny opóźnienia.

W identyfikacji problemów pomocne są dane uzupełniające: logi dostępu i zarejestrowane czasy upstream wskazują, które żądania i serwery backendowe budzą podejrzenia; logi błędów dostarczają wskazówek dotyczących nieudanych połączeń. Jeśli chodzi o obciążenie procesora lub pamięci, potrzebne są odpowiednie wskaźniki systemowe. Jeśli problem dotyczy powtarzających się prób nawiązania połączenia z serwerem backendowym, artykuł na temat NGINX – funkcja Keepalive w upstreemie konfiguracja połączeń upstreamowych wielokrotnego użytku.

Od statusu do monitorowania

W przypadku sporadycznej diagnostyki wystarczające może być zabezpieczone lokalne zapytanie o stan. Dostarcza ono informacji o tym, jakie wartości bazowe zgłasza aktualnie sprawdzana instancja, ale samo w sobie nie przechowuje historii. Jeśli chcesz porównywać zmiany lub otrzymywać powiadomienia w przypadku utrzymujących się nieprawidłowości, potrzebujesz regularnego gromadzenia danych oraz systemu do obsługi szeregów czasowych i alertów.

Oficjalny Eksportator NGINX do Prometheusa W tym celu służy oddzielny komponent: pobiera on stan stubu i udostępnia dane jako metryki Prometheusa. Następnie Prometheus pobiera dane z punktu końcowego eksportera. Należy zaplanować dostępność i ograniczenia dostępu dla obu ścieżek, czyli zarówno do punktu końcowego stanu, jak i do wyjścia metrycznego eksportera.

Podczas konfiguracji należy odnotować, który eksporter wysyła zapytania do której instancji NGINX oraz skąd Prometheus łączy się z eksporterem. Zwłaszcza w przypadku oddzielnych kontenerów są to dwie różne ścieżki sieciowe. Dlatego sama dostępność punktu końcowego eksportera nie zastępuje sprawdzenia, czy eksporter z kolei może pomyślnie pobrać właściwą stronę stanu.

Dodatkowe gromadzenie danych nie przekształca wartości bazowych w szczegółowe wskaźniki dotyczące czasu odpowiedzi ani klas statusów HTTP. W przypadku pytań dotyczących wolno działających adresów URL, odpowiedzi błędowych lub poszczególnych serwerów źródłowych konieczne są odpowiednie logi dostępu oraz dodatkowe dane telemetryczne. Również bardziej szczegółowe Interfejs API NGINX Plus Należy odróżnić status „Stub” w NGINX Open Source; ich dostępność i konfiguracja nie są zamienne.

Wybierz dodatkowe dane w zależności od konkretnego pytania: aby sprawdzić, czy liczba zapytań rośnie, na początek wystarczy porównanie wartości licznika w czasie. Jeśli natomiast chodzi o powolne odpowiedzi lub konkretną usługę backendową, potrzebujesz danych dotyczących opóźnień i przepustowości w odpowiednim przedziale czasowym. Strona stanu może stanowić punkt wyjścia do analizy, ale sama w sobie nie pozwala na jednoznaczną identyfikację przyczyny.

Progi alarmowe powinny opierać się na typowym zachowaniu danego elementu oraz na celach usługi, a nie na ogólnych wartościach dotyczących czasu oczekiwania lub zapisu. Porównaj nietypowe zjawiska z opóźnieniami, błędami i dostępnymi zasobami oraz sprawdź, czy alarm rzeczywiście wymaga podjęcia działań. W ten sposób pojedynczy odczyt licznika staje się pretekstem do przeprowadzenia ukierunkowanej analizy, a nie pochopnej diagnozy.

Podczas planowania alarmów weź również pod uwagę awarię kanału gromadzenia danych: brak danych to nie to samo, co brak zapytań lub brak połączeń. Oddzielna kontrola dostępności pomaga odróżnić awarię od sytuacji, w której aktywność jest faktycznie niska. Należy również określić, kto zajmuje się alarmem oraz jakie dodatkowe dane muszą być dostępne do celów diagnostycznych.