Monitoring des serveurs web NGINX avec la Suite Elastic
Dans cet article, nous allons voir comment nous pouvons monitorer NGINX à l’aide des différents composants de la Suite Elastic. Pour collecter des données, nous nous servirons de Metricbeat et de Filebeat. Ces données seront transférées vers Elasticsearch et y seront stockées. Nous les consulterons ensuite avec Kibana.
Metricbeat collectera des données en rapport avec les connexions (actives, prises en charge, acceptées etc.) et le nombre total de requêtes client. Filebeat recueillera des données concernant les logs d'accès et les logs d'erreur. Leur utilisation variera selon les configurations. Néanmoins, ces informations serviront généralement pour effectuer des déductions, par exemple :
- Si l'on constate un pic dans les logs d'erreur par rapport à une certaine ressource, c'est que nous avons peut-être supprimé une ressource qui est toujours nécessaire.
- Les logs d'accès, quant à eux, peuvent indiquer les heures auxquelles les services sont les plus utilisés (et de là, donner des indications sur les heures auxquelles il serait préférable d'effectuer certaines tâches, comme la maintenance).
- Un pic brusque dans les requêtes client peut être synonyme d'une attaque malveillante (par déni de service par exemple).
Dans cet article, nous nous concentrerons sur la fonctionnalité de monitoring. Nous passerons donc très rapidement sur les autres points (comme la configuration d'Elasticsearch par exemple). Pour ma part, j'utilise un Mac. Je me servirai donc des versions d'Elasticsearch, de Metricbeat, de Filebeat et de Kibana pour Mac. Les versions pour les autres plateformes sont disponibles sur la page des téléchargements.
Installation d'Elasticsearch
Metricbeat et Filebeat (pour ne pas dire tous les Beats) ont besoin d'un cluster Elasticsearch pour stocker les données. Nous allons configurer un cluster Elasticsearch simple en local. Étant donné qu'Elasticsearch ne sera pas mis en contact avec l'extérieur, inutile de configurer la sécurité.
1ère étape : Télécharger Elasticsearch
curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.0-darwin-x86_64.tar.gz
2e étape : Extraire le dossier d’archive
tar -xvf elasticsearch-7.1.0-darwin-x86_64.tar.gz
3e étape : Passer au répertoire bin
cd elasticsearch-7.1.0/bin
4e étape : Démarrer notre cluster à nœud unique
./elasticsearch
Par défaut, votre cluster s’exécutera sur localhost:9200.
Exécution de NGINX
Plusieurs options s'offrent à nous pour exécuter NGINX : de manière autonome sur l'hôte, via un conteneur Docker, au sein d'une configuration Kubernetes, etc. Beats dispose d'une fonctionnalité Autodiscover qui peut écouter les événements d'API de conteneur pour suivre nos conteneurs de serveur au fur et à mesure qu'ils sont déployés ou supprimés.
Les possibilités qui s'offrent à nous pour configurer NGINX sont donc légion, mais nous ne les étudierons pas toutes. Ici, nous donnerons des exemples de configuration sur l'hôte et de la fonctionnalité Autodiscover (Docker, dans le cas présent).
Configuration de Metricbeat et de Filebeat
Nous allons maintenant configurer Beats pour commencer à collecter et transférer nos données.
Metricbeat
Nous nous servirons de Metricbeat pour collecter des indicateurs.
1ère étape : Télécharger Metricbeat :
curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-7.1.0-darwin-x86_64.tar.gz
2e étape : Extraire le dossier d’archive
tar -xvf metricbeat-7.1.0-darwin-x86_64.tar.gz
3e étape : Changer de répertoire
cd metricbeat-7.1.0-darwin-x86_64
Et c’est parti pour la configuration !
Par défaut, notre fichier de configuration (metricbeat.yml) recherchera un cluster Elasticsearch s'exécutant sur localhost:9200, que nous avons configuré précédemment.
4e étape : Activer les modules Metricbeat nécessaires
Par défaut, seuls les indicateurs au niveau du système sont collectés :
./metricbeat modules enable nginx
5e étape : Changer les propriétés du fichier
Nous devons changer quelques propriétés du fichier, car nous allons exécuter Metricbeat en tant que root (vous pouvez aussi choisir d’utiliser l’option --strict.perms=false de la ligne de commande pour désactiver les contrôles stricts d’autorisation) :
sudo chown root metricbeat.yml sudo chown root modules.d/system.yml sudo chown root modules.d/nginx.yml
6e étape : Activer les ensembles d’indicateurs
Si nous ouvrons notre fichier modules.d/nginx.yml, nous pouvons activer l’ensemble d’indicateurs stubstatus, qui permet de supprimer les éléments suivants :
#metricsets: # - stubstatus
Cet ensemble d’indicateurs collecte des données depuis le module NGINX ngx_http_stub_status. Il est donc important que ce module NGINX soit configuré de sorte à ce que l’ensemble d’indicateurs fonctionne.
Vous pouvez également modifier les hôtes monitorés ici. Par défaut, <a href="http://127.0.0.1">http://127.0.0.1</a> est monitoré. Pour les configurations basées sur l’hôte, c’est tout ce dont nous avons besoin.
7e étape : Configurations Autodiscover (autre option)
Pour les configurations Autodiscover, la configuration équivalente variera selon le fournisseur utilisé : Docker, Kubernetes ou Jolokia. Prenons Docker. Voici à quoi cela ressemblerait si nous utilisions Docker : nous ajouterions metricbeat.autodiscover à la fin du fichier de configuration metricbeat.yml.
metricbeat.autodiscover:
providers:
- type: docker
templates:
- condition:
contains:
docker.container.image: nginx
config:
- module: nginx
metricsets: ["stubstatus"]
hosts: "${data.host}:${data.port}"
Avec cette configuration, une correspondance sera établie avec tous les conteneurs Docker utilisant une image dont le nom contient NGINX (correspondance par rapport à une sous-chaîne, et non pas correspondance exacte), et ces conteneurs utiliseront une configuration faisant fonctionner le module NGINX avec l’ensemble d’indicateurs "stubstatus".
8e étape : Exécuter Metricbeat
Bien ! Maintenant que notre configuration est terminée, nous pouvons exécuter Metricbeat avec un indicateur qui envoie les logs vers stderr et qui désactive la sortie syslog/fichier :
sudo ./metricbeat -e
Si tout fonctionne bien, vous devriez voir apparaître les sorties initiales, puis des sorties à chaque fois que Metricbeat publie des données dans votre cluster.
Filebeat
Nous nous servirons de Filebeat pour collecter des logs.
1ère étape : Télécharger Filebeat
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.1.0-darwin-x86_64.tar.gz
2e étape : Extraire le dossier d’archive
tar -xvf filebeat-7.1.0-darwin-x86_64.tar.gz
3e étape : Changer de répertoire
cd filebeat-7.1.0-darwin-x86_64
4e étape : Activer le module NGINX
./filebeat modules enable nginx
Par défaut, les logs collectés seront les logs d’accès et les logs d’erreurs. Filebeat essayera de déterminer les chemins de ces logs en fonction de votre système d'exploitation. Si vous avez explicitement besoin de chemins différents, vous pouvez les paramétrer dans le fichier de configuration modules.d/nginx.yml.
5e étape : Changer les propriétés du fichier
sudo chown root filebeat.yml sudo chown root modules.d/nginx.yml sudo chown root module/nginx/access/manifest.yml sudo chown root module/nginx/error/manifest.yml
Pour les configurations basées sur l’hôte, c’est tout ce dont nous avons besoin.
6e étape : Configurations Autodiscover (autre option)
Comme précédemment, une configuration supplémentaire est nécessaire pour utiliser Autodiscover. Reprenons l’exemple de Docker. En ajoutant cette section Autodiscover à la configuration, le fichier filebeat.yml se présenterait comme suit :
filebeat.autodiscover:
providers:
- type: docker
templates:
- condition:
contains:
docker.container.image: nginx
config:
- module: nginx
access:
input:
type: docker
containers.ids:
- "${data.docker.container.id}"
error:
input:
type: docker
containers.ids:
- "${data.docker.container.id}"
Ici, nous configurons les options d’accès et d’erreur pour utiliser une entrée Docker. Une entrée Docker recherchera les logs de conteneur se trouvant dans son répertoire (le chemin de base où se situent les logs Docker ; par défaut /var/lib/docker/containers). Pour containers.ids, nous utilisons les identifiants des conteneurs correspondant aux critères de notre modèle. Les logs rassemblés (par défaut) proviennent de /var/lib/docker/containers/ac29b98ad83ca43bb4c15ae8f0d03aff8c7d57bf5dee9024124374b92b14b0f2/ (identifiants différents).
7e étape : Exécuter Filebeat
sudo ./filebeat -e
Installation de Kibana
Maintenant que Metricbeat et Filebeat transfèrent des données concernant nos serveurs NGINX, nous devons trouver un moyen de consulter ces données. C'est là que Kibana entre en jeu.
1ère étape : Télécharger Kibana
curl -O https://artifacts.elastic.co/downloads/kibana/kibana-7.1.0-darwin-x86_64.tar.gz
2e étape : Extraire le dossier d’archive et changer de répertoire
tar -xzf kibana-7.1.0-darwin-x86_64.tar.gz
cd kibana-7.1.0-darwin-x86_64
3e étape : Exécuter Kibana
./bin/kibana
Par défaut, Kibana utilisera un hôte Elasticsearch de http://localhost:9200, et sera accessible sur http://localhost:5601.
Si vous accédez à http://localhost:5601, vous devriez voir s’afficher l’écran suivant :
Si vous le souhaitez, vous pouvez vous amuser à manipuler les données échantillon. Pour ma part, je vais simplement cliquer sur Explore on my own (Découvrir par moi-même).
Visualisation des données NGINX dans Kibana
Nous allons voir à présent comment utiliser Kibana pour consulter et analyser nos données.
Infrastructure
Si nous accédons à l'application Infrastructure sur la barre latérale de Kibana, nous aurons la possibilité de voir une vue instantanée (dernière minute) de notre infrastructure. Pour les configurations ne se basant pas sur Autodiscover, les données seront accessibles sous Hosts (Hôtes). Pour les configurations basées sur Autodiscover, utilisez le bouton Docker ou Kubernetes (selon le fournisseur utilisé) pour accéder à l’ensemble de données approprié :
Étant donné que j’ai utilisé une configuration basée sur un hôte, je peux cliquer sur le bouton Hosts (Hôtes) et voir les données suivantes être transférées depuis Metricbeat :
Si nous sélectionnons l’un des nœuds et que nous choisissons View Metrics (Voir les indicateurs), une page contenant le détail des indicateurs de ce serveur NGINX s’affiche.
Logs
Si, à la place, nous accédons à l’application Logs, nous verrons les logs d’accès et d’erreur ayant été transférés à partir de Filebeat.
Tableaux de bord NGINX pré-configurés
Maintenant que nous disposons d'une instance fonctionnelle et accessible de Kibana, nous pouvons charger certains tableaux de bord pré-configurés.
Pour charger les tableaux de bord pré-configurés, exécutez la commande suivante dans votre répertoire Metricbeat :
sudo ./metricbeat setup --dashboards
Répétez l’opération pour Filebeat :
sudo ./filebeat setup --dashboards
Maintenant, si nous naviguons vers l’onglet Dashboards (Tableaux de bord) dans Kibana, voici ce que nous devrions obtenir :
Si nous affinons notre recherche en indiquant "nginx", voici les tableaux de bord disponibles :
À titre d’exemple, voici à quoi ressemble le tableau de bord [Filebeat NGINX] Access and error logs ECS (Logs d’accès et d’erreur ECS [Filebeat NGINX]) :
![Logs d’accès et d’erreur ECS [Filebeat NGINX]](https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt51e7d57d2a6b575d/5d2d38f88e6f797b0da30462/nginx-monitoring-image8.jpg)
Voilà ! Nous venons d’apprendre à utiliser la Suite Elastic pour monitorer les serveurs NGINX. À partir des éléments que nous avons vus, différentes options s'offrent à nous (en termes de regroupement et de filtrage par exemple) pour explorer les informations réellement importantes.