Statut NGINX Stub : surveiller en temps réel l'activité du serveur web

Ce qu'indique le statut « Stub » de NGINX

État du stub NGINX fournit les métriques de base du serveur web sous forme de texte via un point de terminaison HTTP configuré. La réponse décrit l'activité du groupe de processus NGINX interrogé : notamment les connexions client et le nombre total de requêtes comptabilisées. Vous pouvez la consulter localement et la comparer à plusieurs reprises sans avoir à déployer pour cela un système de surveillance complet.

Pour cela, tu dois distinguer deux types de valeurs : une Instantané indique, par exemple, le nombre de connexions client actives au moment de la consultation. Les compteurs globaux tels que requests indiquent en revanche le nombre total de requêtes enregistrées. Seule la comparaison de plusieurs relevés effectués à des intervalles connus permet de se faire une idée du taux de requêtes.

Ces valeurs ne constituent pas une mesure directe de l'utilisation du processeur ou de la mémoire, et ne correspondent pas non plus à un pourcentage de la capacité disponible du serveur web. Un nombre élevé de connexions ouvertes peut avoir différentes causes et entraîner des coûts variables. Pour évaluer la charge réelle, tu as donc besoin de métriques supplémentaires sur les ressources, ainsi que d'informations sur les temps de réponse et les erreurs.

Le statut « Stub » ne ventile pas les chiffres par site web virtuel ou par URL demandée. Si une installation héberge plusieurs sites, ce point de terminaison ne permet pas à lui seul de déterminer lequel est à l'origine d'une augmentation. En cas d'instances NGINX multiples, vous devez enregistrer leurs valeurs séparément et les attribuer de manière univoque.

La consultation de la page d'état constitue elle-même une requête HTTP et influence légèrement les compteurs observés. Il convient d'en tenir compte lors de l'interprétation de faibles volumes de requêtes ou de requêtes très fréquentes. Une seule consultation ne fournit de toute façon qu'un aperçu ; seule l'évolution dans le temps permet de déterminer si l'activité a changé.

Distinguer les connexions et les requêtes

La valeur Connexions actives englobe les connexions client actives, y compris celles en attente. Il ne comptabilise donc pas uniquement les connexions sur lesquelles une réponse est en cours de transmission. Les états « Reading », « Writing » et « Waiting » permettent de contextualiser ce chiffre global, mais ne renseignent ni sur la consommation du processeur ni sur le nombre d'applications en cours d'exécution.

Lorsqu'une requête est en cours de réception, la connexion se trouve dans l'état « Reading » pendant que NGINX lit l'en-tête de la requête. Elle peut ensuite passer à l’état « Writing » lorsque NGINX traite ou écrit la réponse. Cela ne signifie pas pour autant que des octets sont effectivement transmis au client pendant toute cette durée : l’attente d’une réponse en amont peut également faire partie de ce processus.

Si une connexion reste ouverte après une réponse à d'autres requêtes, elle peut être considérée comme Waiting apparaissent. Cet état regroupe les connexions clientes inactives qui attendent une prochaine requête. Une valeur élevée de « Waiting » ne prouve donc pas à elle seule une surcharge ; elle peut également correspondre à un fonctionnement avec de nombreuses connexions réutilisables.

Les connexions et les requêtes sont des entités distinctes : plusieurs requêtes peuvent être traitées successivement via une connexion « keepalive ». Avec HTTP/2, plusieurs requêtes peuvent être transmises via une seule connexion. Le nombre de connexions ouvertes ne permet donc pas de déterminer un nombre fixe de requêtes, et le compteur de requêtes n'augmente pas nécessairement dans les mêmes proportions que les compteurs de connexions.

Pour une évaluation concrète, il est utile de comparer plusieurs requêtes : si le temps d'attente augmente alors que les temps de réponse et les erreurs restent dans la norme, il s'agit dans un premier temps d'une simple observation et non d'un signe d'alerte. L'article consacré à ce sujet explique comment configurer la réutilisation et ses limites : Requêtes Keepalive NGINX.

Vérifier le module et la version

Pour utiliser Stub Status, tu dois disposer d'une installation NGINX avec le module ngx_http_stub_status_module, l'accès à sa configuration et, ultérieurement, la possibilité d'interroger le point d'extrémité protégé à partir de l'espace réseau prévu. Ce module n'est pas intégré par défaut dans la version NGINX. Sa présence dans un paquet de distribution dépend du paquet concerné et doit être vérifiée localement.

Dans le terminal, vérifiez la version et les paramètres de configuration du fichier binaire NGINX effectivement utilisé par le service. La commande suivante affiche ces informations ; parmi les paramètres, --with-http_stub_status_module en sélectionnant l'option de compilation correspondante.

nginx -V

Ce qui est décisif, c'est la fichier binaire correct: Un programme lancé via le chemin de recherche nginx Il peut s'agir d'une installation différente de celle utilisée par le service. En cas de doute, vérifie la configuration du service et le programme de démarrage qui y est utilisé. Si nécessaire, lance ensuite explicitement le fichier binaire concerné, au lieu de déduire le service de production à partir de la sortie d'une autre installation.

La version a également une incidence sur la syntaxe de la directive. Depuis NGINX 1.7.5, on utilise stub_status utilisée sans argument ; les anciennes versions nécessitaient un argument quelconque, par exemple on. La limite de version est une information relative à la compatibilité, et non une supposition quant à la version installée sur votre système.

Si l'option de compilation n'est pas présente dans l'installation vérifiée, tu dois, avant de modifier la configuration, déterminer quel paquet ou quelle version est prévu(e) dans ton environnement. Un emplacement de statut ne suffit pas à lui seul à remplacer un module manquant. Les modifications apportées aux paquets et à la configuration des services doivent respecter la procédure d'exploitation et de validation en vigueur.

Configurer un point de terminaison d'état protégé

Pour consulter l'état local, tu peux utiliser un Écouteur de boucle Configurer. L'exemple suivant est un fichier de configuration pour le http-Contexte, pas de commande de terminal. Cela suppose que le module « Stub-Status » soit disponible et que le port d'exemple 8088 à l'adresse en question ne soit pas déjà occupé par un autre service.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

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

Le lien avec 127.0.0.1 limite cet écouteur à l'interface de bouclage IPv4 locale. L'emplacement exact n'attribue que le chemin spécifié ; la directive stub_status y fournit les données d'état. Le listener n'est donc pas accessible via d'autres interfaces IPv4, que les autres sites Web soient publics ou non.

Le Règles d'accès complètent la règle de liaison : NGINX les vérifie les unes après les autres jusqu’à ce qu’il trouve la première qui corresponde. L'adresse IPv4 locale est autorisée, toutes les autres adresses sont rejetées. Comme cet emplacement contient ses propres règles, les règles d'accès d'un contexte de niveau supérieur ne sont pas héritées en plus. Vérifie donc la configuration complète avant de reprendre cet exemple.

Dans le cas des conteneurs, l'espace réseau est déterminant : un exportateur situé dans un conteneur distinct accède, via son propre localhost En règle générale, ce n'est pas l'interface de bouclage du conteneur NGINX. Pour effectuer une requête à distance, tu dois disposer d'un chemin de connexion privé spécialement prévu à cet effet et de contrôles d'accès adaptés. Ne rends pas la page d'état accessible au public ; elle contient des informations d'exploitation.

Vérifier la configuration et consulter l'état

Après la saisie, vérifie d'abord la configuration dans le terminal. La commande suivante vérifie la syntaxe et tente d'ouvrir les fichiers référencés. Utilise pour cela le fichier binaire NGINX correspondant au service et, le cas échéant, son chemin de configuration spécifique ; une vérification réussie n'active pas encore la modification.

nginx -t

A Reload validé Il s'agit d'une étape productive à part entière. N'effectuez cette opération qu'après validation et conformément aux procédures d'exploitation de votre environnement. Lors d’un rechargement, NGINX recharge la configuration, lance de nouveaux workers avec la nouvelle configuration et arrête les anciens workers de manière ordonnée. Vérifie ensuite que l’opération a bien abouti et consulte les journaux, plutôt que de conclure à une modification effective sur la seule base d’un contrôle de syntaxe réussi.

Une fois l'activation validée, tu peux accéder localement au point de terminaison au sein du même espace réseau à l'aide de curl interroger. Le commutateur -i affiche, outre le corps de la réponse, le statut HTTP et les en-têtes. L'exemple suivant suppose que l'écouteur et le chemin d'accès ont été définis dans le fichier de configuration.

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

On s'attend à une réponse HTTP réussie avec des données d'état sous la forme de Texte, et non au format JSON. En cas d'erreur, le code d'état et les journaux NGINX permettent de cerner le problème. Cependant, une requête locale réussie indique uniquement que cette voie d'accès fonctionne : elle ne prouve pas qu'aucune autre configuration ne rend le point de terminaison accessible depuis l'extérieur.

Lire les valeurs d'état et calculer les débits

Le résultat combine les états actuels des connexions et les valeurs cumulées. Pour l'interprétation, cette distinction est plus importante que la valeur absolue d'une valeur individuelle : un valeur instantanée décrit l'état au moment de la consultation, tandis qu'un compteur global indique le nombre d'événements enregistrés jusqu'à ce moment-là. Le tableau répertorie les différents champs et les erreurs de conclusion courantes.

Du compteur requests on peut calculer une moyenne Taux de demandes Pour calculer la valeur sur un intervalle : soustrais la première valeur de la seconde et divise la différence par le nombre de secondes écoulées. Exemple de calcul à titre illustratif, sans mesure : si la valeur passe de 12 000 à 12 600 en 60 secondes, 600 divisé par 60 donne une moyenne de 10 requêtes par seconde.

Cette moyenne ne reflète ni le pic le plus élevé à court terme, ni les URL qui ont été consultées. Pour chaque consultation, note l'heure et l'instance consultée. Si le compteur diminue ou si tu changes d'instance, tu ne dois pas interpréter la simple différence comme un taux sans vérification préalable ; commence une nouvelle série de comparaisons pour l'instance concernée.

Si tu compares des intervalles de durée différente, prends en compte le temps réellement écoulé plutôt que l'intervalle prévu entre les lectures. Une interrogation différée de deux minutes nécessite par exemple un diviseur différent de celui d'une interrogation après une minute. Une période d'observation plus longue atténue davantage les fluctuations à court terme ; les intervalles courts rendent les changements plus visibles, mais augmentent la proportion d'interrogations d'état.

La requête de statut elle-même est également une requête HTTP et a un impact minime sur les compteurs surveillés. Cela prend toute son importance notamment lorsque le trafic est très faible ou que les requêtes sont fréquentes. Un intervalle de requête régulier et documenté permet de prendre plus facilement en compte ces éléments de surveillance lors de l'interprétation des données.

S'il y a plusieurs instances, tu calcules d'abord le taux à partir des valeurs successives de chaque instance. Ce n’est qu’ensuite que les taux correspondant à des périodes comparables peuvent être regroupés. Si un enregistrement manque ou si l’affectation d’une instance change, l’écart qui en résulte doit rester visible, au lieu de simuler une courbe apparemment continue.

Analyser les erreurs et les limites

Si le point de terminaison d'état renvoie un code HTTP 403, vérifiez d'abord l'adresse source effectivement reçue par NGINX et les règles d'accès de la location. allow et deny sont évaluées les unes après les autres jusqu’à ce qu’une correspondance soit trouvée. Les règles propres au lieu remplacent, le cas échéant, les règles héritées ; elles ne les complètent pas automatiquement.

En cas d'erreur HTTP 404, il faut d'abord chercher ailleurs : le port et le listener, le chemin d'accès demandé et le bloc de serveurs sélectionné sont-ils corrects ? Vérifiez également si la configuration prévue est bien active après le rechargement. Un appel local réussi sur un autre port ou un autre chemin d'accès ne prouve pas que l'emplacement souhaité a été atteint.

Si aucune réponse HTTP n'est renvoyée, il convient de distinguer l'accessibilité du listener d'une réponse avec un code d'erreur. Vérifie d'abord l'adresse, le port et l'espace réseau du processus qui effectue la requête, ainsi que l'état du service. Ce n'est que lorsqu'une connexion au bon écouteur est établie que le statut HTTP et l'emplacement sélectionné permettent d'affiner davantage le diagnostic.

Pour l'analyse continue des erreurs, il est utile de comparer les compteurs globaux accepte et traite. En temps normal, ces valeurs sont identiques. Si leur écart augmente, cela peut indiquer qu’une limite de ressources a été atteinte ; toutefois, la comparaison des compteurs ne permet à elle seule ni d’identifier la cause précise, ni de déterminer le nombre de requêtes HTTP rejetées. Il convient donc d’inclure les journaux d’erreurs et la configuration dans l’analyse.

Une différence déjà existante indique dans un premier temps uniquement l'écart entre les deux compteurs totaux. Pour déterminer si la situation a évolué au cours de la période d'observation, compare cet écart lors de plusieurs consultations de la même instance. Note bien la période concernée afin de pouvoir rechercher les entrées de journal et les événements d'exploitation correspondants.

La directive worker_connections limite le nombre de connexions par worker, et pas uniquement les connexions client. Cela inclut, par exemple, les connexions vers des serveurs proxy ; de plus, les limites des descripteurs de fichiers peuvent également imposer des restrictions. Calculé en divisant le nombre de connexions actives par le nombre de workers, multiplié par worker_connections Il n'est donc pas possible d'obtenir un taux d'utilisation fiable des capacités. Vérifie plutôt les limites réelles et la consommation des autres ressources dans ce contexte.

Une modification des limites de connexion ne doit pas reposer uniquement sur une valeur de statut élevée. Vérifiez d'abord si une limite est effectivement atteinte et quelles autres ressources ou connexions en amont sont concernées. Planifiez les modifications éventuelles tout en surveillant les erreurs et les temps de réponse, puis validez-les conformément à la procédure d'exploitation prévue.

Contextualiser les évolutions et les problèmes en amont

Une simple consultation d'état ne reflète qu'un instant donné. En revanche, des requêtes répétées à intervalles réguliers permettent de détecter si les états de connexion dépassent un niveau normal ou s'ils redescendent après un pic. Enregistrez plusieurs instances NGINX séparément et notez quelle instance correspond à chaque série chronologique ; sinon, les changements entre les points de terminaison risquent de fausser l'évolution.

Un haut Valeur « Waiting » décrit les connexions client en attente, actuellement inactives. En soi, ce n'est pas un signe de surcharge : lorsque les connexions sont réutilisées, les clients peuvent attendre d'autres requêtes. Une augmentation devient plus significative si tu la compares aux temps de réponse, aux erreurs et aux indicateurs de ressources sur la même période.

Reste Écriture Si ce niveau reste élevé pendant une période prolongée, examinez à la fois les temps de transmission en amont et le comportement des clients. Cet état ne signifie pas que des octets sont envoyés en continu ; il peut également s'agir du temps d'attente d'une réponse en amont. L'état « Stub » n'indique ni le service backend concerné, ni la cause d'un retard.

Des données complémentaires facilitent l'identification : les journaux d'accès et les temps d'upstream enregistrés indiquent quelles requêtes et quels backends présentent des anomalies ; les journaux d'erreurs fournissent des indications sur les connexions ayant échoué. En cas de pression sur le processeur ou la mémoire, vous aurez besoin des métriques système correspondantes. Si l'enquête porte sur des tentatives répétées d'établissement de connexion vers le backend, l'article consacré à Keepalive en amont de NGINX la configuration de connexions en amont réutilisables.

Du statut au suivi

Pour un diagnostic ponctuel, une requête d'état locale sécurisée peut suffire. Elle indique quelles valeurs de base l'instance interrogée signale à ce moment-là, mais ne stocke pas elle-même d'historique. Si vous devez comparer des évolutions ou être averti en cas d'anomalies persistantes, vous avez besoin d'un enregistrement régulier et d'un système de séries chronologiques et d'alertes.

Le site officiel Exportateur NGINX vers Prometheus Il existe pour cela un composant distinct : il récupère l'état du stub et met les données à disposition sous forme de métriques Prometheus. Prometheus interroge ensuite le point de terminaison de l'exportateur. Prévoyez la disponibilité et les restrictions d'accès pour les deux voies, c'est-à-dire aussi bien pour le point de terminaison d'état que pour la sortie des métriques de l'exportateur.

Lors de la configuration, notez quel exportateur interroge quelle instance NGINX et d'où Prometheus accède à l'exportateur. Surtout dans le cas de conteneurs séparés, il s'agit de deux chemins réseau différents. Le simple fait qu'un point de terminaison d'exportateur soit accessible ne remplace donc pas la vérification consistant à s'assurer que l'exportateur, de son côté, parvient bien à récupérer la page d'état correcte.

Cette collecte supplémentaire ne permet pas de transformer les valeurs de base en métriques détaillées sur les temps de réponse ou les classes d'état HTTP. Pour identifier les URL lentes, les réponses d'erreur ou les connexions en amont individuelles, il est nécessaire de disposer de journaux d'accès adaptés et d'autres données de télémétrie. De même, la collecte plus complète API NGINX Plus Il convient de distinguer le statut « Stub » de celui de NGINX Open Source ; leur disponibilité et leur configuration ne sont pas interchangeables.

Sélectionnez des données supplémentaires en fonction de la question posée : pour évaluer une augmentation du nombre de requêtes, il suffit dans un premier temps de comparer les valeurs du compteur dans le temps. En revanche, s'il s'agit de réponses lentes ou d'un service backend spécifique, vous aurez besoin de données de latence et de débit montant correspondant à la période concernée. La page d'état peut fournir un élément déclencheur pour une analyse, mais elle ne permet pas à elle seule d'identifier la cause.

Les seuils d'alerte doivent être définis en fonction du comportement normal de l'instance concernée et des objectifs de service, et non en fonction d'une valeur générale relative aux opérations d'attente ou d'écriture. Comparez les anomalies avec les latences, les erreurs et les ressources disponibles, et vérifiez si une alerte justifie réellement une intervention. Ainsi, un simple compteur devient le point de départ d’une analyse ciblée plutôt que d’un diagnostic précipité.

Lors de la planification des alertes, tiens également compte d'une éventuelle défaillance du canal de collecte : l'absence de données n'est pas synonyme d'absence de requêtes ou de connexions. Un contrôle séparé de l'accessibilité permet de distinguer une requête ayant échoué d'une activité réellement faible. Déterminez également qui est chargé de traiter une alerte et quelles autres données doivent être disponibles pour le diagnostic.