Nginx est un serveur web très populaire, il se positionne 2e au classement derrière l’incontournable Apache (Web server ranking).

Globalement aujourd’hui, plus de 98% des utilisateurs d’Nginx utilisent sa version 1.


On remarque aussi qu’il est bien souvent utilisé en mode load balancing du fait de ses excellentes capacités et performances.


On va du coup voir comment le superviser vu l’importance qu’il peut avoir dans la construction de vos infrastructures.


Nginx status: interne et facile


De quoi s’agit-il?

La page d’état Nginx procure des informations en temps réel sur la santé du moteur. C'est un module directement intégré au package nginx-full.

On y retrouve les informations suivantes: 

  • les connexions actives

  • les demandes traitées

  • les lectures: Nginx lit les en-têtes des demandes

  • les écritures: Nginx lit les corps de requêtes, procède aux requêtes, écrit les réponses aux clients

  • les attentes: cette valeur est calculée comme ceci: cnx actives - (lectures + écritures). Il faut noter que cette valeur dépend du “keepalive_timeout”.


On est plus face à de la métrologie qu'à de la supervision à vocation d'alerting pure, mais cette solution permet néanmoins d'appréhender un premier niveau d'état global.


Que faire pour y accéder?

Pour y avoir accès, Nginx doit être compilé avec  ce module: HttpStubStatusModule.

Afin de vérifier si votre installation le comporte, vous pouvez taper cette commande:


nginx -V 2>&1 | grep -o with-http_stub_status_module


Si vous voyez la ligne suivante, tout est ok. Sinon il faut installer complètement votre Nginx (en gros #sudo apt-get install nginx-full).


with-http_stub_status_module


Une fois présent, le module se configure simplement avec l’ajout de configuration sur un de vos sites nginx, à l’intérieur d’un bloc “server {...}”.

Par exemple:

location /nginx_status {
          stub_status on;
          access_log   off;
          allow @ip de votre serveur de supervision;
          deny all;
        }

Il est toujours conseillé de ne pas publier ces informations à tout le monde, surtout si votre site est accessible depuis Internet.


Intégration PRTG rapide!

Rien de plus simple pour l'intégrer dans votre plateforme PRTG, il existe un script mis à disposition par Paessler (KB60186).

Tout y est décrit, où poser le script et comment configurer le capteur, mais pour toute question, nous sommes là pour vos aider.




Syslog: old school


On ne présente plus Sylog, protocole pour la journalisation des messages, mais il faut donc savoir que la connexion à syslog dans Nginx se configure dans les directives error_log et access_log.


De façon classique, et c’est bien ce qui nous intéresse pour industrialiser notre supervision, c’est que les messages peuvent naturellement être envoyés à un serveur.

Il ne restera “que” la configuration côté collecteur de filtres et autres règles afin d’en obtenir les alertes souhaitées.


Je n'en parle ici qu'à titre de mémoire, si l'on a la possibilité de faire autrement, autant ne pas se frotter avec la lourdeur du traitement et de la gestion du syslog.


Ngxtop: un peu de boulot pour aller plus loin


De quoi s’agit-il?

Il existe d’autres moyens pour aller plus loin dans la supervision de son Nginx, et ngxtop en est un.

Tout est disponible ici: https://github.com/lebinh/ngxtop


L’intérêt et la puissance de cet outil proviennent sans doute sa simplicité et de sa flexibilité. Mais ce qu'il faut avoir à l'esprit, c'est que cet outil va nous permettre d'avoir une approche beaucoup plus précise dans l'alerting sur des comportements particuliers.

On peut bien évidemment avoir des stats génériques facilement, on peut aussi lui appliquer tout un tas de filtres pour ne remonter que les informations ciblées qui pourraient nous intéresser, mais on peut également travailler des fichier de log pour entrer dans des analyses très complètes.

Cet outil peut aussi interpréter les logs Apache. What else?! :-)


Entre autres, et à titre d'exemple (ngxtop pourra faire l'objet d'un billet dédié tant il est complet), on peut traquer facilement le nombre de codes 2xx, 3xx, 4xx, 5xx afin de surveiller le comportement et l'intégrité du site.

On peut aussi sortir le top des adresses sollicitant le site... 


Intégration dans sa supervision

Pour l'interfaçage avec un outil de monitoring, il faudra passer par du scripting avancé. 

Nos équipes sont en mesure de vous accompagner pour réaliser ce genre d'intégration.



Amplify: enfin une solution interne intéressante!


Le hasard du calendrier est tel, qu'au moment où je décide de publier cet article, Nginx communique de façon officielle sur Nginx Amplify

Nginx Amplify est issu d'un projet de longue date, en bêta pendant plus d'un an, des milliers de testeurs, des quantités astronomiques de données collectées...


L'objectif d'Amplify est de combler les lacunes reconnues chez Nginx de suivi de performances et d'alerting pour leurs serveurs web. C'est une solution SaaS qui procure globalement trois services:

  • des données de monitoring et d'analyse pour comprendre ce qui se passe
  • un aperçu de la configuration de votre Nginx
  • un système d'alerte proactif


Nous prendrons le temps de décrire cet outil plus en détail au sein d'un article dédié, car il offre de belles perspectives pour la supervision Nginx. Tout l'enjeu est  de voir comment intégrer ceci facilement à votre outil de monitoring préféré afin d'éviter de vous multiplier les consoles de supervision et consolidant ainsi son rôle capital d'hyperviseur.




Conclusion


D’une manière globale, quelle que soit la solution retenue, il faut bien comprendre que ce ne sont que des moyens techniques pour obtenir des métriques de votre Nginx. Nulle part je n'ai parlé de seuils, de valeurs standards pour déclencher les alertes, parce que tout simplement cela dépend de votre contexte.


Il s’agit de comprendre et de voir quel type de trafic passe par votre application pour ensuite positionner des seuils cohérents à votre contexte.


C’est là où le machine learning proposé par PRTG avec ses capteurs “unusual” se révèle très intéressant, en laissant passer une phase d’apprentissage afin d’ensuite positionner les valeurs jugées pertinentes.

Une autre approche, sans être pour autant opposée à la précédente, serait de faire des tests de montée en charge sur votre Nginx afin d’en déterminer les niveaux de rupture. On peut ainsi assez facilement en déduire les valeurs à ne pas dépasser pour éviter tout problème.



Nicolas Jançon

Co-fondateur et associé chez Sensor Factory