NGINX Stub Status: Övervaka webbserverns aktivitet i realtid

Vad NGINX-statusen ”Stub” visar

NGINX Stub-status tillhandahåller grundläggande webbservermått som text via en konfigurerad HTTP-ändpunkt. Svaret beskriver aktiviteten i den förfrågade NGINX-processgruppen: framför allt klientanslutningar och det totala antalet förfrågningar. Du kan hämta dem lokalt och jämföra dem upprepade gånger utan att behöva använda ett fullständigt övervakningssystem.

Här måste du skilja mellan två typer av värden: En Ögonblicksbild visar till exempel hur många klientanslutningar som är aktiva vid hämtningen. Totala räknare som requests anger däremot hur många förfrågningar som totalt har räknats. Det är först genom att jämföra flera mätvärden över kända tidsintervall som man kan dra slutsatser om förfrågningsfrekvensen.

Värdena är inte en direkt mätning av CPU- eller minnesutnyttjandet och ger inte heller något procenttal för webbserverns tillgängliga kapacitet. Ett stort antal öppna anslutningar kan ha olika orsaker och medföra olika kostnader. För att kunna bedöma den faktiska belastningen behöver du därför även resursmått samt information om svarstider och fel.

Stub Status specificerar inte siffrorna efter virtuell webbplats eller begärd URL. Om en installation hanterar flera webbplatser går det inte att avgöra utifrån enbart slutpunkten vilken av dem som ligger bakom en ökning. Om du har flera NGINX-instanser bör du registrera deras värden separat och tilldela dem entydiga koder.

Även själva hämtningen av statussidan är en HTTP-förfrågan och påverkar de övervakade räknarna i viss utsträckning. Detta bör beaktas vid tolkningen av små förfrågningsvolymer eller mycket frekventa förfrågningar. En enskild hämtning ger ändå bara en ögonblicksbild; det är först utvecklingen över tid som visar om aktiviteten förändras.

Skillnaden mellan kontakter och förfrågningar

Värdet Aktiva anslutningar omfattar aktiva klientanslutningar, inklusive de som väntar. Den räknar alltså inte bara anslutningar där ett svar just nu överförs. Tillstånden Reading, Writing och Waiting hjälper till att sätta detta totala antal i sitt sammanhang, men beskriver varken CPU-användning eller antalet aktiva applikationer.

När en begäran kommer in befinner sig anslutningen i tillståndet ”Reading” medan NGINX läser begärans rubrik. Därefter kan den övergå till tillståndet ”Writing” när NGINX bearbetar eller skriver svaret. Detta innebär inte att data faktiskt skickas till klienten under hela tiden: även väntan på ett svar från uppströms kan ingå i detta.

Om en anslutning förblir öppen efter ett svar på ytterligare förfrågningar kan den betraktas som Väntar på visas. Detta tillstånd omfattar inaktiva klientanslutningar som väntar på nästa förfrågan. Ett högt ”Waiting”-värde i sig är därför inte ett bevis på överbelastning; det kan också vara typiskt för en miljö med många återanvändbara anslutningar.

Anslutningar och förfrågningar är olika storheter: Flera förfrågningar kan skickas efter varandra via en keepalive-anslutning. Med HTTP/2 kan flera förfrågningar överföras via en enda anslutning. Antalet öppna anslutningar ger därför ingen indikation på ett fast antal förfrågningar, och antalet förfrågningar behöver inte öka i samma proportion som antalet anslutningar.

För en praktisk utvärdering är det värt att jämföra flera förfrågningar: Om ”Waiting” ökar medan svarstider och fel förblir normala är detta i första hand en iakttagelse och inte ett tecken på något allvarligt. Hur återanvändning och dess begränsningar kan konfigureras förklaras i artikeln om NGINX Keepalive-förfrågningar.

Kontrollera modul och version

För att använda Stub Status behöver du en NGINX-installation med modulen ngx_http_stub_status_module, åtkomst till dess konfiguration och senare en möjlighet att hämta den skyddade slutpunkten från det avsedda nätverksområdet. Modulen ingår inte som standard i NGINX-byggnaden. Om ett distributionspaket innehåller den beror på det aktuella paketet och måste kontrolleras lokalt.

Kontrollera i terminalen vilken version och vilka Configure-parametrar som gäller för den NGINX-binärfil som faktiskt används av tjänsten. Följande kommando visar dessa uppgifter; bland parametrarna anges --with-http_stub_status_module till motsvarande byggalternativ.

nginx -V

Den avgörande faktorn är rätt binärfil: Ett program som startats via sökvägen nginx kan vara en annan installation än den som tjänsten kör. Om du är osäker, kontrollera tjänstens konfiguration och vilken programstart som används där. Starta sedan vid behov den aktuella binärfilen uttryckligen, istället för att dra slutsatser om den produktiva tjänsten utifrån utdata från en annan installation.

Även versionen påverkar hur direktivet skrivs. Från och med NGINX 1.7.5 gäller att stub_status används utan argument; äldre versioner krävde ett valfritt argument, till exempel on. Versionsgränsen är en kompatibilitetsuppgift, inte ett antagande om vilken version som är installerad på ditt system.

Om byggalternativet saknas i den granskade installationen bör du, innan du gör några konfigurationsändringar, ta reda på vilket paket eller vilken build som är avsedd för din miljö. En statusplats i sig ersätter inte ett saknat modul. Ändringar av paket och tjänstekonfigurationer ska följa gällande drifts- och godkännandeprocedurer.

Konfigurera en skyddad statusändpunkt

För att kontrollera statusen lokalt kan du använda en separat Loopback-lyssnare konfigurera. Följande exempel visar en filkonfiguration för den befintliga http-Kontext, inget terminalkommando. Det förutsätter att stub-statusmodulen är tillgänglig och att exempelporten 8088 på den aktuella adressen inte redan används av en annan tjänst.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

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

Kopplingen till 127.0.0.1 begränsar denna lyssnare till det lokala IPv4-loopback-gränssnittet. Den exakta platsen tilldelar endast den angivna sökvägen; direktivet stub_status levererar statusdata där. Lyssnarprogrammet är därmed inte tillgängligt via andra IPv4-gränssnitt, oavsett om de övriga webbplatserna är offentliga eller inte.

Die Åtkomstregler kompletterar bindningen: NGINX kontrollerar dem i tur och ordning tills den första träffen uppnås. Den lokala IPv4-adressen tillåts, alla andra adresser avvisas. Eftersom det finns egna regler i denna plats ärvs inte åtkomstregler från en överordnad kontext. Kontrollera därför hela konfigurationen innan du använder exemplet.

När det gäller containrar är nätverksutrymmet avgörande: En exporterare i en separat container når via sin egen localhost Vanligtvis inte NGINX-containerns loopback-gränssnitt. För en fjärrförfrågan behöver du en noggrant planerad privat anslutningsväg och lämpliga åtkomstkontroller. Gör inte statussidan offentligt tillgänglig utan vidare; den innehåller driftsinformation.

Kontrollera konfigurationen och hämta status

Kontrollera först konfigurationen i terminalen efter att du har angett uppgifterna. Följande kommando kontrollerar syntaxen och försöker öppna de filer som refereras till. Använd den NGINX-binärfil som gäller för tjänsten och, om nödvändigt, dess avvikande konfigurationsväg; en lyckad kontroll aktiverar inte ändringen ännu.

nginx -t

En godkänd omladning är ett separat produktionssteg. Utför det först efter godkännande och i enlighet med driftsrutinerna för din miljö. Vid en omstart laddar NGINX om konfigurationen, startar nya arbetare med den nya konfigurationen och avslutar de gamla arbetarna på ett ordnat sätt. Kontrollera därefter att allt har gått bra och granska loggarna, istället för att dra slutsatsen att en ändring har trätt i kraft enbart på grund av att syntaxkontrollen har godkänts.

Efter att aktiveringen har godkänts kan du lokalt nå slutpunkten i samma nätverksområde med curl fråga. Knappen -i visar förutom själva svarstexten även HTTP-statusen och rubrikerna. Följande exempel förutsätter att lyssnaren och sökvägen anges i filkonfigurationen.

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

Man förväntar sig ett lyckat HTTP-svar med statusinformation i form av Text, inte som JSON. Om ett fel uppstår kan statuskoden och NGINX-loggarna hjälpa till att ringa in felet. En lyckad lokal hämtning visar dock bara att just den här åtkomstvägen fungerar: den bevisar inte att ingen annan konfiguration gör slutpunkten tillgänglig från utsidan.

Läsa av statusvärden och beräkna hastigheter

Utmatningen kombinerar aktuella anslutningsstatusar med summerade värden. För tolkningen är denna distinktion viktigare än det absoluta värdet hos ett enskilt värde: Ett aktuellt värde beskriver tillståndet vid hämtningen, medan en totalräknare visar antalet händelser som har räknats fram till dess. Tabellen redogör för de enskilda fälten och typiska felaktiga slutsatser.

Från mätaren requests kan man beräkna ett genomsnittligt Andel förfrågningar Beräkna för ett intervall: Dra det första värdet från det andra och dela skillnaden med antalet förflutna sekunder. Illustrativt räkneexempel, ingen mätning: Om värdet stiger från 12 000 till 12 600 på 60 sekunder blir 600 dividerat med 60 i genomsnitt 10 förfrågningar per sekund.

Detta genomsnitt visar varken den högsta kortsiktiga toppen eller vilka URL:er som har besökts. Notera tidpunkten och den instans som begärdes för varje hämtning. Om räknaren sjunker eller om du växlar mellan instanser får du inte tolka den enkla skillnaden som en hastighet utan att kontrollera den; börja istället en ny jämförelseserie för den aktuella instansen.

Om du jämför intervall av olika längd ska du i varje fall utgå från den faktiskt förflutna tiden istället för det planerade avläsningsintervallet. En fördröjd avläsning på över två minuter kräver till exempel en annan delare än en avläsning efter en minut. En längre tidsperiod jämnar ut kortsiktiga fluktuationer i högre grad; korta intervall gör förändringar tydligare, men ökar andelen statusförfrågningar.

Även själva statusförfrågan är en HTTP-förfrågan och påverkar de övervakade räknarna i viss utsträckning. Detta blir särskilt märkbart vid mycket låg trafik eller vid frekventa förfrågningar. Ett regelbundet och dokumenterat förfrågningsintervall gör det enklare att ta hänsyn till sådana övervakningsandelar vid tolkningen.

Om det finns flera instanser beräknar du först kurvan utifrån de på varandra följande värdena för varje enskild instans. Först därefter kan frekvenserna för jämförbara tidsperioder slås samman. Om en avläsning saknas eller om tilldelningen av en instans ändras bör den uppkomna luckan förbli synlig, istället för att ge sken av en till synes sammanhängande kurva.

Undersöka fel och begränsningar

Om status-ändpunkten svarar med HTTP 403, kontrollera först den källadress som faktiskt anländer till NGINX och åtkomstreglerna för den aktuella platsen. allow och deny utvärderas i tur och ordning tills den första träffen uppnås. Egna regler på platsen ersätter i förekommande fall ärvda regler; de kompletterar inte dessa automatiskt.

Vid ett HTTP 404-fel bör du först söka orsaken på annat håll: Stämmer porten och lyssnaren, den begärda sökvägen och det valda serverblocket? Kontrollera dessutom om den avsedda konfigurationen verkligen är aktiv efter omstarten. Att ett lokalt anrop lyckas på en annan port eller sökväg bevisar inte att den önskade platsen har nåtts.

Om det inte kommer något HTTP-svar alls, skilj mellan om lyssnaren är tillgänglig och ett svar med felstatus. Kontrollera först adress, port och nätverksområde för den process som gör förfrågan samt tjänstens status. Först när en anslutning till rätt lyssnare har upprättats kan HTTP-status och vald plats hjälpa till med ytterligare avgränsning.

För den löpande felanalysen är det värt att jämföra totalräknarna tar emot och hanterar. Normalt sett är de lika. Om skillnaden ökar kan det bero på att en resursgräns har nåtts; en jämförelse av räknarna i sig visar dock varken den konkreta orsaken eller antalet avvisade HTTP-förfrågningar. Ta därför med felloggar och konfigurationen i utredningen.

En redan befintlig skillnad visar inledningsvis endast avståndet mellan de två totala räknarna. För att bedöma om situationen förändras under observationsperioden bör du jämföra detta avstånd vid flera hämtningar av samma instans. Notera den aktuella tidsperioden så att du kan söka efter relevanta loggposter och driftshändelser.

Direktivet worker_connections begränsar antalet anslutningar per arbetare, inte enbart klientanslutningar. Detta omfattar till exempel även anslutningar till proxyservrar; dessutom kan gränser för filbeskrivare begränsa antalet. Beräknas som antalet aktiva anslutningar dividerat med antalet arbetare gånger worker_connections Därför kan man inte få fram någon tillförlitlig bild av kapacitetsutnyttjandet. Kontrollera istället de faktiska gränserna och den övriga resursförbrukningen i sammanhanget.

En ändring av anslutningsgränserna bör inte enbart baseras på ett högt statusvärde. Kontrollera först om en gräns verkligen har nåtts och vilka andra resurser eller uppströmsanslutningar som är inblandade. Planera eventuella ändringar samtidigt som du övervakar fel och svarstider, och granska dem enligt den fastställda driftsproceduren.

Att kartlägga förlopp och problem i tidigare led

En enskild statusförfrågan visar endast en tidpunkt. Upprepade förfrågningar med fasta intervall hjälper däremot till att upptäcka om anslutningsstatusen stiger över en normal nivå eller sjunker tillbaka efter en topp. Registrera flera NGINX-instanser separat och notera vilken instans som ligger bakom varje tidsserie; annars kan växlingar mellan slutpunkter förvränga utvecklingen.

En hög Waiting-värde beskriver väntande, för tillfället inaktiva klientanslutningar. Detta är i sig inte ett tecken på överbelastning: vid återanvända anslutningar kan klienter vänta på ytterligare förfrågningar. En ökning blir mer meningsfull om du jämför den med svarstider, fel och resursmått under samma tidsperiod.

Kvar Skrivande Om värdet är förhöjt under en längre tid bör du undersöka både uppströms-tiderna och klienternas beteende. Detta tillstånd innebär inte att byte skickas kontinuerligt; det kan även omfatta väntetiden på ett uppströms-svar. Stub-status anger varken vilken backend-tjänst som är berörd eller orsaken till fördröjningen.

Kompletterande data underlättar identifieringen: åtkomstloggar och registrerade uppströms-tider visar vilka förfrågningar och backend-servrar som avviker; felloggar ger ledtrådar om misslyckade anslutningar. Om det handlar om belastning på CPU eller minne behöver du motsvarande systemmetriker. Om upprepade försök att ansluta till backend-systemet påverkar utredningen, förklarar artikeln om NGINX Upstream Keepalive konfigurationen av återanvändbara uppströmsförbindelser.

Från status till övervakning

För en tillfällig diagnos kan en skyddad lokal statusförfrågan räcka. Den visar vilka basvärden den förfrågade instansen just nu rapporterar, men lagrar inte själv någon historik. Om du vill jämföra utvecklingen eller bli underrättad vid ihållande avvikelser behöver du regelbunden datainsamling och ett system för tidsserier och larm.

Den officiella NGINX Prometheus-exportör Det finns en separat komponent för detta: den hämtar status från stubben och tillhandahåller data som Prometheus-metriker. Prometheus hämtar därefter exportörens slutpunkt. Planera för tillgänglighet och åtkomstbegränsningar för båda vägarna, det vill säga både till status-slutpunkten och till exportörens metrikutmatning.

Dokumentera vid konfigurationen vilken exportör som hämtar data från vilken NGINX-instans och varifrån Prometheus når exportören. Särskilt när det gäller separata containrar handlar det om två olika nätverksvägar. En tillgänglig exportörsändpunkt räcker därför inte för att ersätta kontrollen av om exportören i sin tur lyckas hämta rätt statussida.

Denna ytterligare datainsamling ger inte några detaljerade mätvärden för svarstider eller HTTP-statusklasser utifrån basvärdena. För att kunna undersöka långsamma URL:er, felmeddelanden eller enskilda uppströmsanslutningar krävs lämpliga åtkomstloggar och ytterligare telemetri. Även den mer omfattande NGINX Plus API Man måste skilja mellan Stub-status i NGINX Open Source; deras tillgänglighet och konfiguration är inte utbytbara.

Välj ytterligare data utifrån den specifika frågan: För att se om antalet förfrågningar ökar räcker det till en början med att jämföra tidsvärdena för räknaren. Handlar det däremot om långsamma svar eller en viss backend-tjänst behöver du latens- och uppströmsdata från samma tidsperiod. Statussidan kan ge upphov till en utredning, men kan inte på egen hand fastställa orsaken.

Larmtrösklar bör baseras på det normala beteendet hos respektive instans och på tjänstens mål, inte på ett generellt värde för väntetid eller skrivtid. Jämför avvikelser med fördröjningar, fel och tillgängliga resurser och kontrollera om ett larm verkligen kräver åtgärder. På så sätt blir en enskild räknare en anledning till en målinriktad undersökning istället för en förhastad diagnos.

Ta även hänsyn till att datainsamlingsvägen kan sluta fungera när du planerar larm: Saknade data är inte detsamma som noll förfrågningar eller noll anslutningar. En separat kontroll av tillgängligheten hjälper till att skilja ett misslyckat hämtningsförsök från faktiskt låg aktivitet. Fastställ dessutom vem som ska hantera ett larm och vilka ytterligare data som måste finnas tillgängliga för diagnosen.