Stato dello stub NGINX: monitoraggio in tempo reale dell'attività del server web

Cosa indica lo stato "stub" di NGINX

Stato dello stub NGINX fornisce le metriche di base del server web in formato testo tramite un endpoint HTTP configurato. La risposta descrive l'attività del gruppo di processi NGINX interrogato: in particolare le connessioni dei client e il numero totale di richieste conteggiate. È possibile recuperarla localmente e confrontarla ripetutamente senza dover ricorrere a un sistema di monitoraggio completo.

A questo proposito, devi distinguere due tipi di valori: uno Istantanea mostra, ad esempio, quante connessioni client sono attive al momento della consultazione. I contatori totali come requests indicano invece il numero totale di richieste registrate. Solo il confronto tra diverse letture effettuate a intervalli di tempo noti consente di trarre conclusioni sul tasso di richieste.

Questi valori non rappresentano una misurazione diretta dell'utilizzo della CPU o della memoria, né indicano una percentuale della capacità disponibile del server web. Un numero elevato di connessioni aperte può avere cause e costi diversi. Per valutare il carico effettivo, sono quindi necessarie anche metriche sulle risorse e informazioni sui tempi di risposta e sugli errori.

Stub Status non suddivide i dati in base al sito web virtuale o all’URL richiesto. Se un’installazione gestisce più siti, dall’endpoint da solo non è possibile capire quale di essi sia responsabile di un aumento. In presenza di più istanze NGINX, è consigliabile registrare i relativi valori separatamente e associarli in modo univoco.

Anche la consultazione della pagina di stato costituisce di per sé una richiesta HTTP e influisce in misura minima sui contatori monitorati. È necessario tenerne conto nell’interpretazione di volumi di richieste ridotti o di interrogazioni molto frequenti. Una singola consultazione fornisce comunque solo un’istantanea; solo l’andamento nel tempo mostra se l’attività sta cambiando.

Distinguere tra collegamenti e richieste

Il valore Connessioni attive comprende le connessioni client attive, comprese quelle in attesa. Pertanto, non conta solo le connessioni attraverso le quali è in corso la trasmissione di una risposta. Gli stati “Reading”, “Writing” e “Waiting” aiutano a contestualizzare questo numero complessivo, ma non descrivono né il consumo di CPU né il numero di applicazioni attive.

Quando arriva una richiesta, una connessione si trova nello stato “Reading” mentre NGINX legge l’header della richiesta. Successivamente, può passare allo stato "Writing" quando NGINX elabora o scrive la risposta. Ciò non significa che durante l'intero periodo vengano effettivamente trasmessi byte al client: anche l'attesa di una risposta dall'upstream può rientrare in questo processo.

Se una connessione rimane aperta dopo una risposta per ulteriori richieste, può essere considerata come In attesa . Questo stato comprende le connessioni client inattive in attesa di una nuova richiesta. Un valore elevato di "Waiting", di per sé, non è quindi indice di sovraccarico; può infatti corrispondere anche a un funzionamento con numerose connessioni riutilizzabili.

Le connessioni e le richieste sono grandezze diverse: su una connessione keepalive possono essere elaborate più richieste in successione. Con HTTP/2, è possibile trasmettere più richieste tramite un'unica connessione. Dal numero di connessioni aperte non è quindi possibile dedurre un numero fisso di richieste, e il contatore delle richieste non deve necessariamente aumentare nella stessa proporzione del contatore delle connessioni.

Ai fini di una valutazione pratica, è utile effettuare un confronto su più sessioni: se il valore di “Waiting” aumenta mentre i tempi di risposta e gli errori rimangono nella norma, si tratta innanzitutto di un’osservazione e non di un segnale di allarme. L’articolo su spiega come configurare il riutilizzo e i suoi limiti: Richieste Keepalive di NGINX.

Verifica del modulo e della versione

Per Stub Status è necessaria un'installazione di NGINX con il modulo ngx_http_stub_status_module, l'accesso alla sua configurazione e, in seguito, la possibilità di interrogare l'endpoint protetto dall'area di rete prevista. Il modulo non viene integrato di default nella build di NGINX. La sua presenza in un pacchetto di distribuzione dipende dal pacchetto specifico e deve essere verificata localmente.

Verifica nel terminale la versione e i parametri di configurazione del file binario NGINX effettivamente utilizzato dal servizio. Il comando seguente mostra queste informazioni; tra i parametri figura --with-http_stub_status_module all'opzione di compilazione corrispondente.

nginx -V

Il fattore decisivo è la file binario corretto: Un programma avviato tramite il percorso di ricerca nginx potrebbe trattarsi di un'installazione diversa da quella utilizzata dal servizio. In caso di dubbi, verifica la configurazione del servizio e il programma di avvio ivi utilizzato. Se necessario, avvia esplicitamente il file binario in questione, invece di dedurre il servizio di produzione dall'output di un'altra installazione.

Anche la versione influisce sulla sintassi della direttiva. A partire da NGINX 1.7.5, stub_status utilizzato senza argomenti; le versioni precedenti richiedevano un argomento qualsiasi, ad esempio on. Il limite di versione è un'informazione relativa alla compatibilità, non un'ipotesi sulla versione installata sul tuo sistema.

Se nell'installazione verificata manca l'opzione di compilazione, prima di apportare qualsiasi modifica alla configurazione dovresti verificare quale pacchetto o quale build sia previsto nel tuo ambiente. Una semplice indicazione dello stato non sostituisce un modulo mancante. Le modifiche ai pacchetti e alla configurazione dei servizi devono essere effettuate secondo la procedura operativa e di approvazione prevista.

Configurazione protetta dell'endpoint di stato

Per verificare lo stato a livello locale, puoi utilizzare un Listener di loopback configurare. L'esempio seguente è un file di configurazione per l'attuale http-Contesto, non comando da terminale. Presuppone che il modulo Stub-Status sia disponibile e che la porta di esempio 8088 all'indirizzo in questione non sia già occupata da un altro servizio.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

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

Il legame con 127.0.0.1 limita questo listener all'interfaccia loopback IPv4 locale. La posizione esatta assegna solo il percorso specificato; la direttiva stub_status fornisce lì i dati di stato. Il listener non è quindi raggiungibile tramite altre interfacce IPv4, indipendentemente dal fatto che gli altri siti web siano pubblici o meno.

Il sito Regole di accesso integrano la regola di accesso: NGINX le verifica in ordine fino alla prima corrispondenza. L'indirizzo IPv4 locale è consentito, mentre tutti gli altri indirizzi vengono rifiutati. Poiché in questa posizione sono presenti regole specifiche, le regole di accesso di un contesto di livello superiore non vengono ereditate. Verifica quindi la configurazione completa prima di applicare l'esempio.

Nel caso dei container, lo spazio di rete è fondamentale: un esportatore in un container separato accede tramite il proprio localhost Di norma non si tratta dell'interfaccia loopback del container NGINX. Per un'interrogazione remota è necessario un percorso di connessione privato appositamente pianificato e adeguati controlli di accesso. Non rendere semplicemente pubblica la pagina di stato; essa contiene informazioni operative.

Verifica della configurazione e consultazione dello stato

Dopo aver inserito i dati, verifica innanzitutto la configurazione nel terminale. Il comando seguente verifica la sintassi e tenta di aprire i file a cui si fa riferimento. A tal fine, utilizza il file binario NGINX specifico per il servizio e, se necessario, il relativo percorso di configurazione alternativo; una verifica riuscita non attiva ancora la modifica.

nginx -t

A Ricarica approvata È un’operazione a sé stante. Eseguila solo dopo l’approvazione e in conformità con le procedure operative del tuo ambiente. Durante il reload, NGINX ricarica la configurazione, avvia nuovi worker con la nuova configurazione e termina i vecchi worker in modo ordinato. Verifica quindi il corretto esito dell’operazione e controlla i log, invece di dedurre che la modifica sia attiva solo in base al superamento del controllo sintattico.

Una volta approvata l'attivazione, puoi accedere all'endpoint localmente nella stessa rete utilizzando curl interrogare. L'interruttore -i mostra, oltre al corpo della risposta, anche lo stato HTTP e le intestazioni. L'esempio seguente presuppone che il listener e il percorso siano specificati nel file di configurazione.

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

Si prevede una risposta HTTP positiva con i dati di stato come Testo, non in formato JSON. In caso di errore, il codice di stato e i log di NGINX aiutano a individuare il problema. Tuttavia, un recupero locale riuscito dimostra solo che questa via di accesso funziona: non garantisce che non esista un’altra configurazione che renda l’endpoint accessibile dall’esterno.

Leggere i valori di stato e calcolare le frequenze

L'output combina gli stati attuali delle connessioni con i valori cumulativi. Ai fini dell'interpretazione, questa distinzione è più importante dell'entità assoluta di un singolo valore: un valore istantaneo descrive lo stato al momento della consultazione; un contatore totale indica gli eventi registrati fino a quel momento. La tabella elenca i singoli campi e i tipici errori di inferenza.

Dal contatore requests si può calcolare una media Tasso di richieste Calcolo per un intervallo: sottrai il primo valore dal secondo e dividi la differenza per i secondi trascorsi. Esempio di calcolo illustrativo, non si tratta di una misurazione: se il valore passa da 12.000 a 12.600 in 60 secondi, 600 diviso per 60 dà una media di 10 richieste al secondo.

Questa media non mostra né il picco massimo a breve termine né quali URL siano stati visitati. Per ogni accesso, annota l'ora e l'istanza consultata. Se il contatore diminuisce o se passi da un'istanza all'altra, non interpretare la semplice differenza come frequenza senza prima verificarla; avvia una nuova serie di confronti per l'istanza in questione.

Se confronti intervalli di durata diversa, calcola sempre in base al tempo effettivamente trascorso anziché all’intervallo di consultazione previsto. Ad esempio, una lettura ritardata di due minuti richiede un divisore diverso rispetto a una lettura dopo un minuto. Un intervallo di osservazione più lungo attenua maggiormente le fluttuazioni a breve termine; gli intervalli brevi rendono più visibili le variazioni, ma aumentano la percentuale di richieste di stato.

Anche la richiesta di stato stessa è una richiesta HTTP e influisce in misura minima sui contatori monitorati. Ciò diventa particolarmente rilevante in caso di traffico molto ridotto o di richieste frequenti. Un intervallo di interrogazione regolare e documentato facilita la considerazione di tali percentuali di monitoraggio nella valutazione.

In presenza di più istanze, calcola innanzitutto la frequenza sulla base dei valori consecutivi di ciascuna singola istanza. Solo successivamente è possibile raggruppare i tassi relativi a periodi comparabili. Se manca una lettura o cambia l'assegnazione di un'istanza, la lacuna che ne deriva dovrebbe rimanere visibile, anziché simulare un andamento apparentemente continuo.

Analizzare errori e limiti

Se l'endpoint di stato risponde con un codice HTTP 403, verifica innanzitutto l'indirizzo di origine effettivamente ricevuto da NGINX e le regole di accesso della location. allow e deny vengono valutate in ordine fino al primo risultato positivo. Le regole specifiche della location sostituiscono, se del caso, quelle ereditate; non le integrano automaticamente.

In caso di errore HTTP 404, la ricerca va inizialmente effettuata altrove: la porta e il listener, il percorso richiesto e il blocco server selezionato sono corretti? Verifica inoltre se la configurazione prevista sia effettivamente attiva dopo il ricaricamento. Il fatto che la richiesta locale abbia esito positivo su una porta o un percorso diverso non dimostra che sia stata raggiunta la posizione desiderata.

Se non viene generata alcuna risposta HTTP, distingue la raggiungibilità del listener da una risposta con codice di errore. Verifica innanzitutto l'indirizzo, la porta e lo spazio di rete del processo richiedente, nonché lo stato del servizio. Solo quando viene stabilita una connessione con il listener corretto, lo stato HTTP e la posizione selezionata aiutano a restringere ulteriormente il campo di ricerca.

Per l'analisi continua degli errori, è utile confrontare i contatori totali accetta e gestisce. Di norma sono uguali. Se la differenza aumenta, potrebbe essere coinvolto un limite di risorse raggiunto; tuttavia, il semplice confronto dei contatori non rivela né la causa concreta né il numero di richieste HTTP rifiutate. È quindi opportuno includere nell’analisi i log degli errori e la configurazione.

Una differenza già esistente indica inizialmente solo la distanza tra i due contatori totali. Per valutare se la situazione sia cambiata nel periodo di osservazione, confronta questa distanza in caso di più accessi alla stessa istanza. Prendi nota del periodo in questione, in modo da poter cercare le voci di log e gli eventi di sistema corrispondenti.

La direttiva worker_connections limita le connessioni per ogni worker, non solo quelle dei client. Tra queste rientrano, ad esempio, anche le connessioni ai server proxy; inoltre, i limiti dei descrittori di file possono imporre ulteriori restrizioni. Il numero di connessioni attive diviso per il numero di worker moltiplicato per worker_connections Non è quindi possibile ottenere un dato affidabile sull'utilizzo della capacità. Verifica invece i limiti effettivi e il restante consumo di risorse nel contesto.

Una modifica dei limiti di connessione non dovrebbe basarsi esclusivamente su un valore di stato elevato. Verifica innanzitutto se un limite è stato effettivamente raggiunto e quali altre risorse o connessioni a monte sono coinvolte. Pianifica le eventuali modifiche tenendo conto del monitoraggio degli errori e dei tempi di risposta e verificale secondo la procedura operativa prevista.

Classificare gli andamenti e i problemi a monte

Una singola richiesta di stato mostra solo un istante. Le richieste ripetute a intervalli regolari aiutano invece a individuare se gli stati di connessione superano un livello normale o se, dopo un picco, tornano a diminuire. Monitorare separatamente più istanze di NGINX e registrare quale istanza corrisponde a ciascuna serie temporale; in caso contrario, i cambiamenti tra gli endpoint potrebbero falsare l’andamento.

Un alto Valore di attesa descrive le connessioni client in attesa, attualmente inattive. Di per sé, non costituisce una prova di sovraccarico: nel caso di connessioni riutilizzate, i client possono rimanere in attesa di ulteriori richieste. Un aumento diventa più significativo se lo si confronta con i tempi di risposta, gli errori e le metriche delle risorse relative allo stesso periodo.

Rimane Scrittura Se il valore rimane elevato per un periodo prolungato, verificare sia i tempi di upstream che il comportamento dei client. Questo stato non implica che vengano inviati byte in modo continuo; può includere anche il tempo di attesa per una risposta upstream. Lo stato "Stub" non indica né il servizio backend interessato né la causa di un ritardo.

Per l'identificazione sono utili dati aggiuntivi: i log di accesso e i tempi upstream registrati mostrano quali richieste e backend presentano anomalie; i log degli errori forniscono indicazioni sulle connessioni fallite. Se si tratta di sovraccarico della CPU o della memoria, sono necessarie le metriche di sistema corrispondenti. Se il problema riguarda ripetuti tentativi di connessione al backend, l’articolo su Keepalive upstream di NGINX la configurazione di connessioni upstream riutilizzabili.

Dallo stato al monitoraggio

Per una diagnosi occasionale può essere sufficiente una richiesta di stato locale protetta. Essa fornisce informazioni sui valori di base che l’istanza interrogata sta segnalando in quel momento, ma non memorizza essa stessa alcuna cronologia. Se devi confrontare gli andamenti o ricevere notifiche in caso di anomalie persistenti, hai bisogno di una raccolta regolare dei dati e di un sistema per le serie temporali e gli allarmi.

Il sito ufficiale Esportatore NGINX per Prometheus A tale scopo esiste un componente separato: recupera lo stato dello stub e rende disponibili i dati come metriche Prometheus. Prometheus recupera quindi l'endpoint dell'esportatore. Pianifica la raggiungibilità e le restrizioni di accesso per entrambi i percorsi, ovvero sia per l'endpoint di stato che per l'output delle metriche dell'esportatore.

Durante la configurazione, documenta quale esportatore interroga quale istanza di NGINX e da dove Prometheus raggiunge l'esportatore. Soprattutto nel caso di container separati, si tratta di due percorsi di rete diversi. Un endpoint dell'esportatore raggiungibile non sostituisce quindi di per sé la verifica che l'esportatore stesso riesca a recuperare correttamente la pagina di stato.

La raccolta aggiuntiva non trasforma i valori di base in metriche dettagliate relative ai tempi di risposta o alle classi di stato HTTP. Per individuare URL lenti, risposte di errore o singoli upstream, sono necessari log di accesso adeguati e ulteriori dati di telemetria. Anche la più completa API di NGINX Plus occorre distinguere lo "Stub Status" in NGINX Open Source; la loro disponibilità e configurazione non sono intercambiabili.

Scegli i dati aggiuntivi in base alla domanda specifica: per un aumento del numero di richieste, è sufficiente, in un primo momento, il confronto temporale del contatore. Se invece si tratta di risposte lente o di un determinato servizio di backend, sono necessari dati relativi alla latenza e all’upstream corrispondenti al periodo in questione. La pagina di stato può fornire uno spunto per l’analisi, ma non è in grado di effettuare l’attribuzione da sola.

Le soglie di allarme dovrebbero basarsi sul comportamento normale della rispettiva istanza e sugli obiettivi del servizio, non su un valore generico relativo ai tempi di attesa o di scrittura. Confronta le anomalie con le latenze, gli errori e le risorse disponibili e verifica se un allarme richiede effettivamente un intervento. In questo modo, un singolo valore di conteggio diventa lo spunto per un'analisi mirata anziché una diagnosi affrettata.

Nella pianificazione degli allarmi, tieni conto anche del malfunzionamento del canale di acquisizione: la mancanza di dati non equivale a zero richieste o zero connessioni. Una verifica separata dell’accessibilità aiuta a distinguere un’interruzione della raccolta dati da un’effettiva bassa attività. Stabilisci inoltre chi deve gestire un allarme e quali ulteriori dati devono essere disponibili per la diagnosi.