NGINX Stub-status: Overvågning af webserveraktivitet i realtid

Hvad NGINX Stub Status viser

NGINX Stub-status leverer grundlæggende webserver-metrikker som tekst via et konfigureret HTTP-endepunkt. Svaret beskriver aktiviteten i den forespurgte NGINX-procesgruppe: især klientforbindelser og det samlede antal forespørgsler. Du kan hente dem lokalt og sammenligne dem gentagne gange uden at skulle bruge et komplet overvågningssystem til det.

Her skal du skelne mellem to typer værdier: En Øjebliksbillede viser for eksempel, hvor mange klientforbindelser der er aktive under hentningen. Samletællere som requests angiver derimod, hvor mange forespørgsler der i alt er blevet talt. Først ved at sammenligne flere tællerstande over kendte tidsintervaller kan man sige noget om forespørgselsfrekvensen.

Værdierne er ikke en direkte måling af CPU- eller hukommelsesudnyttelsen og angiver heller ikke en procentdel af den tilgængelige webserverkapacitet. Mange åbne forbindelser kan have forskellige årsager og medføre forskellige omkostninger. For at kunne vurdere den faktiske belastning har du derfor også brug for ressourcemålinger samt oplysninger om svartider og fejl.

Stub Status opdeler ikke tallene efter virtuel hjemmeside eller den anmodede URL. Hvis en installation kører flere hjemmesider, kan man ikke ud fra slutpunktet alene se, hvilken af dem der er årsag til en stigning. Hvis der er flere NGINX-instanser, bør du registrere deres værdier separat og tildele dem entydigt.

Selve hentningen af statussiden er også en HTTP-anmodning og påvirker de overvågede tællere en smule. Dette skal tages i betragtning ved fortolkningen af små anmodningsmængder eller meget hyppige forespørgsler. En enkelt hentning giver alligevel kun et udsnit; først forløbet viser, om aktiviteten ændrer sig.

At skelne mellem forbindelser og forespørgsler

Værdien Aktive forbindelser omfatter aktive klientforbindelser, herunder de ventende forbindelser. Den tæller altså ikke kun de forbindelser, hvor der netop overføres et svar. Tilstandene »Reading«, »Writing« og »Waiting« hjælper med at sætte dette samlede tal i perspektiv, men beskriver hverken CPU-forbruget eller antallet af aktive applikationer.

Når der modtages en anmodning, befinder en forbindelse sig i tilstanden »Reading«, mens NGINX læser anmodningens header. Derefter kan den skifte til tilstanden „Writing“, når NGINX behandler eller skriver svaret. Det betyder ikke, at der faktisk sendes bytes til klienten i hele denne periode: Det kan også omfatte ventetiden på et svar fra upstream.

Hvis en forbindelse forbliver åben efter et svar på yderligere forespørgsler, kan den betragtes som Venter vises. Denne tilstand omfatter inaktive klientforbindelser, der venter på den næste anmodning. En høj »Waiting«-værdi i sig selv er derfor ikke et tegn på overbelastning; den kan også være et tegn på drift med mange genanvendelige forbindelser.

Forbindelser og anmodninger er to forskellige størrelser: Der kan køre flere anmodninger efter hinanden via en keepalive-forbindelse. Med HTTP/2 kan flere anmodninger overføres via én forbindelse. Antallet af åbne forbindelser giver derfor ikke et fast antal anmodninger, og requests-tælleren behøver ikke at stige i samme forhold som forbindelsestællerne.

Med henblik på en praktisk vurdering er det en god idé at sammenligne data fra flere forespørgsler: Hvis »Waiting« stiger, mens svartider og fejl forbliver uændrede, er det i første omgang blot en observation og ikke et tegn på, at der er grund til bekymring. Hvordan genbrug og dets begrænsninger kan konfigureres, forklares i artiklen om NGINX Keepalive-anmodninger.

Kontroller modul og version

For at kunne bruge Stub Status skal du have en NGINX-installation med modulet ngx_http_stub_status_module, adgang til dens konfiguration og senere mulighed for at forespørge det beskyttede endepunkt fra det påtænkte netværksområde. Modulet er ikke inkluderet som standard i NGINX-buildet. Om en distributionspakke indeholder det, afhænger af den pågældende pakke og skal kontrolleres lokalt.

Kontroller i terminalen, hvilken version og hvilke Configure-parametre den NGINX-binærfil, som tjenesten rent faktisk bruger, har. Følgende kommando viser disse oplysninger; blandt parametrene er --with-http_stub_status_module på den relevante build-indstilling.

nginx -V

Den afgørende faktor er korrekt binærfil: Et program, der startes via søgestien nginx kan være en anden installation end den, som tjenesten kører på. Hvis der er tvivl, skal du kontrollere tjenestens konfiguration og den programstart, der anvendes der. Start derefter om nødvendigt den pågældende binærfil direkte, i stedet for at drage konklusioner om den produktive tjeneste ud fra output fra en anden installation.

Også versionen har indflydelse på, hvordan direktivet skrives. Siden NGINX 1.7.5 er stub_status bruges uden argument; ældre versioner krævede et vilkårligt argument, f.eks. on. Versionsgrænsen er en oplysning om kompatibilitet, ikke en antagelse om, hvilken version der er installeret på dit system.

Hvis build-indstillingen mangler i den kontrollerede installation, bør du, inden du foretager en konfigurationsændring, afklare, hvilket passende pakke eller hvilken build der er beregnet til dit miljø. En statusplacering alene erstatter ikke et manglende modul. Ændringer af pakker og servicekonfiguration skal følge den gældende drifts- og godkendelsesprocedure.

Opsætning af beskyttet status-endepunkt

For at tjekke den lokale status kan du bruge en separat Loopback-lytter konfigurere. Følgende eksempel er en filkonfiguration for den eksisterende http-Kontekst, ikke en terminalkommando. Det forudsætter, at stub-status-modulet er tilgængeligt, og at eksempelporten 8088 på den pågældende adresse ikke allerede er optaget af en anden tjeneste.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

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

Forbindelsen til 127.0.0.1 begrænser denne lytter til den lokale IPv4-loopback-grænseflade. Den nøjagtige placering tildeler kun den angivne sti; direktivet stub_status leverer statusdataene der. Lytteren kan derfor ikke nås via andre IPv4-grænseflader, uanset om de øvrige websteder er offentligt tilgængelige.

Die Adgangsregler supplerer bindingen: NGINX gennemgår dem i rækkefølge, indtil den finder det første match. Den lokale IPv4-adresse er tilladt, alle andre adresser afvises. Da der findes egne regler i denne placering, arves adgangsregler fra en overordnet kontekst ikke yderligere. Kontroller derfor den fulde konfiguration, før du anvender eksemplet.

Når det gælder containere, er netværksrummet afgørende: En eksportør i en separat container opnår via sit eget localhost Normalt er det ikke NGINX-containerens loopback-grænseflade. Til en fjernforespørgsel skal du have en bevidst planlagt privat forbindelsesvej og passende adgangskontrol. Du må ikke blot gøre statussiden offentligt tilgængelig; den indeholder driftsoplysninger.

Kontroller konfigurationen og hent status

Efter indtastningen skal du først kontrollere konfigurationen i terminalen. Følgende kommando kontrollerer syntaksen og forsøger at åbne de filer, der henvises til. Brug den NGINX-binærfil, der er relevant for tjenesten, og om nødvendigt den tilhørende konfigurationssti; en vellykket kontrol aktiverer ikke ændringen endnu.

nginx -t

En godkendt genindlæsning er et selvstændigt produktivt trin. Udfør det først efter godkendelse og i overensstemmelse med driftsprocedurerne for dit miljø. Ved en reload indlæser NGINX konfigurationen på ny, starter nye worker-processer med den nye konfiguration og afslutter de gamle worker-processer på en ordnet måde. Kontroller derefter, om det er lykkedes, og gennemgå logfilerne, i stedet for at konkludere, at der er tale om en aktiv ændring, blot fordi syntakschecken er bestået.

Når aktiveringen er godkendt, kan du lokalt tilgå slutpunktet i det samme netværksområde med curl afspørge. Kontakten -i viser ud over selve svarteksten også HTTP-status og headerne. Det følgende eksempel forudsætter, at listeneren og stien er angivet i filkonfigurationen.

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

Der forventes et vellykket HTTP-svar med statusoplysninger som Tekst, ikke som JSON. I tilfælde af en fejl kan statuskoden og NGINX-logfilerne hjælpe med at indsnævre fejlen. En vellykket lokal hentning viser dog kun, at denne adgangsvej fungerer: Den beviser ikke, at ingen anden konfiguration gør slutpunktet tilgængeligt udefra.

Aflæse statusværdier og beregne hastigheder

Udskriften kombinerer aktuelle forbindelsesstatus med akkumulerede værdier. For fortolkningen er denne skelnen vigtigere end den absolutte størrelse af en enkelt værdi: En Aktuel værdi beskriver tilstanden ved hentningen, mens en samlet tæller angiver de begivenheder, der er talt indtil da. Tabellen angiver de enkelte felter og typiske fejlkonklusioner.

Fra tælleren requests kan man beregne et gennemsnitligt Forespørgselsfrekvens Beregn for et interval: Træk den første værdi fra den anden, og del forskellen med de forløbne sekunder. Illustrativt regneeksempel, ikke en måling: Hvis værdien stiger fra 12.000 til 12.600 på 60 sekunder, giver 600 divideret med 60 et gennemsnit på 10 forespørgsler pr. sekund.

Dette gennemsnit viser hverken den højeste kortvarige spids eller hvilke URL’er der blev åbnet. Notér for hvert opkald tidspunktet og den forespurgte instans. Hvis tælleren falder, eller hvis du skifter mellem instanser, må du ikke uden nærmere undersøgelse fortolke den simple forskel som en frekvens; start i stedet en ny sammenligningsserie for den pågældende instans.

Hvis du sammenligner intervaller af forskellig længde, skal du i hvert tilfælde tage udgangspunkt i den faktisk forløbne tid i stedet for det planlagte interval mellem aflæsningerne. En forsinket statusforespørgsel på over to minutter kræver for eksempel en anden divider end en forespørgsel efter et minut. Et længere betragtningsinterval udjævner kortvarige udsving i højere grad; korte intervaller gør ændringer mere synlige, men øger andelen af statusforespørgsler.

Selve statusforespørgslen er også en HTTP-forespørgsel og påvirker de overvågede tællere i ringe grad. Dette får især betydning ved meget lav trafik eller hyppige forespørgsler. Et regelmæssigt, dokumenteret forespørgselsinterval gør det lettere at tage højde for sådanne overvågningsandele ved tolkningen.

Hvis der er flere instanser, beregner du først frekvensen ud fra de på hinanden følgende værdier for hver enkelt instans. Først derefter kan satserne for sammenlignelige perioder sammenføres. Mangler der en aflæsning, eller ændres en instans’ tilknytning, bør det opståede hul forblive synligt i stedet for at simulere et tilsyneladende sammenhængende forløb.

Undersøgelse af fejl og begrænsninger

Hvis status-endpunktet svarer med HTTP 403, skal du først kontrollere den kildeadresse, der rent faktisk modtages af NGINX, samt adgangsreglerne for den pågældende lokation. allow og deny udvurderes i rækkefølge, indtil det første match findes. Egne regler i lokationen erstatter i givet fald arvede regler; de supplerer ikke automatisk disse.

Ved en HTTP 404-fejl skal du først lede andre steder: Stemmer porten og lytteren, den anmodede sti og den valgte serverblok overens? Kontroller desuden, om den tilsigtede konfiguration rent faktisk er aktiv efter genindlæsningen. Et vellykket lokalt opkald via en anden port eller sti beviser ikke, at den ønskede placering blev tilgået.

Hvis der slet ikke kommer noget HTTP-svar, skal du skelne mellem, om lytteren er tilgængelig, og om der er tale om et svar med en fejlkode. Kontroller først adressen, porten og netværksområdet for den proces, der foretager anmodningen, samt tjenestens status. Først når der er oprettet forbindelse til den korrekte listener, kan HTTP-status og den valgte placering hjælpe med at indsnævre fejlen yderligere.

I forbindelse med den løbende fejlanalyse er det en god idé at sammenligne de samlede tællere accepteres og behandles. Normalt er de ens. Hvis forskellen mellem dem øges, kan det skyldes, at en ressourcegrænse er nået; en sammenligning af tællerne alene viser dog hverken den konkrete årsag eller antallet af afviste HTTP-anmodninger. Inddrag derfor fejllogfiler og konfigurationen i undersøgelsen.

En allerede eksisterende forskel viser i første omgang kun afstanden mellem de to samletællere. For at vurdere, om situationen ændrer sig i observationsperioden, skal du sammenligne denne afstand ved flere hentninger af den samme instans. Notér den pågældende periode, så du kan søge efter relevante logposter og driftshændelser i forbindelse hermed.

Direktivet worker_connections begrænser antallet af forbindelser pr. worker, ikke udelukkende klientforbindelser. Dette omfatter for eksempel også forbindelser til proxyservere; derudover kan filbeskrivelsesbegrænsninger også indvirke. Beregnes som antallet af aktive forbindelser divideret med antallet af workere gange worker_connections Derfor kan man ikke få et pålideligt billede af kapacitetsudnyttelsen. Undersøg i stedet de faktiske grænser og det øvrige ressourceforbrug i den konkrete sammenhæng.

En ændring af forbindelsesgrænser bør ikke udelukkende baseres på en høj statusværdi. Afklar først, om en grænse rent faktisk er nået, og hvilke andre ressourcer eller upstream-forbindelser der er involveret. Planlæg eventuelle ændringer sideløbende med overvågning af fejl og svartider, og kontroller dem i henhold til den fastlagte driftsprocedure.

Kategorisere forløb og problemer i de tidlige faser

En enkelt statusforespørgsel viser kun et enkelt tidspunkt. Gentagne forespørgsler med faste intervaller hjælper derimod med at afgøre, om forbindelsestilstandene stiger ud over et normalt niveau eller falder tilbage efter en spidsbelastning. Registrer flere NGINX-instanser separat, og noter, hvilken instans der ligger bag hver tidsserie; ellers kan skift mellem slutpunkter forvride forløbet.

En høj Waiting-værdi beskriver ventende, i øjeblikket inaktive klientforbindelser. I sig selv er det ikke et tegn på overbelastning: Ved genbrugte forbindelser kan klienter vente på yderligere forespørgsler. En stigning bliver mere sigende, hvis du sammenligner den med svartider, fejl og ressourcemålinger over samme tidsperiode.

Forbliver Skrivning Hvis den er forhøjet over en længere periode, skal du undersøge både upstream-tiderne og klienternes adfærd. Denne tilstand betyder ikke, at der løbende sendes bytes; den kan også omfatte ventetiden på et upstream-svar. Stub-status angiver hverken den berørte backend-tjeneste eller årsagen til en forsinkelse.

Supplerende data hjælper med at identificere årsagen: Adgangslogfiler og registrerede upstream-tider viser, hvilke forespørgsler og backends der er mistænkelige; fejllogfiler giver oplysninger om mislykkede forbindelser. Hvis der er tale om belastning af CPU eller hukommelse, har du brug for de relevante systemmetrikker. Hvis gentagne forsøg på at oprette forbindelse til backendet er relevant for undersøgelsen, forklarer artiklen om NGINX Upstream Keepalive konfigurationen af genanvendelige upstream-forbindelser.

Fra status til overvågning

Til en lejlighedsvis diagnose kan en beskyttet lokal statusforespørgsel være tilstrækkelig. Den angiver, hvilke basisværdier den forespurgte instans netop rapporterer, men gemmer ikke selv nogen historik. Hvis du skal sammenligne udviklinger eller blive underrettet ved vedvarende afvigelser, har du brug for en regelmæssig registrering og et system til tidsserier og alarmer.

Den officielle NGINX Prometheus-eksportør Der findes en separat komponent til dette formål: Den henter status fra stubben og stiller dataene til rådighed som Prometheus-metrikker. Prometheus henter derefter data fra eksportørens endpoint. Planlæg tilgængeligheden og adgangsbegrænsningerne for begge veje, dvs. både til status-endpointet og til eksportørens metrikudgang.

Når du konfigurerer systemet, skal du dokumentere, hvilken eksportør der forespørger på hvilken NGINX-instans, og hvorfra Prometheus når frem til eksportøren. Især når der er tale om separate containere, er der to forskellige netværksveje. Et tilgængeligt eksportør-endepunkt er derfor ikke i sig selv nok til at erstatte kontrollen af, om eksportøren selv kan hente den korrekte statusside.

Den supplerende registrering gør ikke basisværdierne til detaljerede målinger af responstid eller HTTP-statusklasser. For at kunne undersøge langsomme URL’er, fejlresponser eller enkelte upstream-servere er det nødvendigt med relevante adgangslogfiler og yderligere telemetri. Også den mere omfattende NGINX Plus API skal skelnes fra Stub Status i NGINX Open Source; deres tilgængelighed og konfiguration er ikke indbyrdes udskiftelige.

Vælg yderligere data ud fra det konkrete spørgsmål: For at vurdere en stigende forespørgselsrate er det i første omgang tilstrækkeligt at sammenligne tælleren over tid. Handler det derimod om langsomme svar eller en bestemt backend-tjeneste, har du brug for tidsmæssigt relevante data om latenstid og upstream. Statussiden kan give anledning til en undersøgelse, men kan ikke alene stå for tilordningen.

Alarmtærskler bør baseres på den pågældende instans’ normale adfærd og på servicemålene, ikke på et generelt tal for ventetid eller skrivning. Sammenlign afvigelser med ventetider, fejl og tilgængelige ressourcer, og kontroller, om en alarm rent faktisk kræver handling. På den måde bliver en enkelt tæller anledning til en målrettet undersøgelse i stedet for en forhastet diagnose.

Når du planlægger alarmer, skal du også tage højde for, at dataindsamlingsvejen kan svigte: Manglende data er ikke det samme som nul forespørgsler eller nul forbindelser. En separat kontrol af tilgængeligheden hjælper med at skelne mellem en afbrudt hentning og faktisk lav aktivitet. Fastlæg desuden, hvem der skal håndtere en alarm, og hvilke yderligere data der skal være tilgængelige til diagnosticering.