Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Du 22 au 24 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Prometheus et Grafana
  3. Surveillance blackbox, SNMP et Push Gateway
Extrait - Prometheus et Grafana Surveillez vos applications et composants système
Extraits du livre
Prometheus et Grafana Surveillez vos applications et composants système
2 avis
Revenir à la page d'achat du livre

Surveillance blackbox, SNMP et Push Gateway

Objectifs du chapitre et prérequis

1. Contexte et prérequis

Les chapitres précédents ont été consacrés à la surveillance de composants qui disposaient nativement d’un point d’entrée Prometheus (Docker, Prometheus, Grafana) ou qui disposaient d’un exporteur permettant de faire cette communication (exporteur système, PostgreSQL ou MySQL/MariaDB).

Toutefois, il n’est pas toujours possible de disposer d’un point d’entrée direc-tement compatible. Ci-dessous une liste d’exemples courants :

  • Un système embarqué (type IoT).

  • Un composant non personnalisable (routeurs, switchs réseau program-mables, etc.) uniquement joignable à l’aide du protocole SNMP.

  • Un service externe (serveur web, serveur de messagerie, etc.).

Chacun de ces trois exemples réclame la mise en place de modules spécifiques :

  • L’exporteur blackbox pour les services externes.

  • L’exporteur SNMP pour les composants réseaux compatible.

  • Le composant PushGateway pour les services ayant une durée de vie courte.

2. Fichiers téléchargeables

Vous pouvez récupérer des exemples sur le dépôt de code source GitHub suivant : https://github.com/EditionsENI/prometheus-grafana

Vous pouvez également récupérer ces fichiers dans l’archive chapitre-15.tar.gz depuis la page Informations...

Surveillance par boîte noire (black box)

1. Contexte

Un exporteur récupère des informations qui permettent de surveiller le fonctionnement interne d’un produit (consommation mémoire, activité CPU, nombre d’appels, etc.).

Dans le cas d’une surveillance par boîte noire (black box en anglais), le but est de prendre un point de vue externe au système. Ce suivi est intéressant pour :

  • Les dépendances externes, comme un service web d’un partenaire par exemple.

  • Le suivi global d’une application.

2. Mise en place de l’exporteur Blackbox

a. Présentation de l’exporteur

L’exporteur Blackbox a été créé pour prendre en charge cette fonction. Il est principalement conçu pour tester les points d’entrées HTTP. Par défaut, l’exporteur récupère les informations suivantes :

  • Le temps de connexion global.

  • Le temps de résolution des entrées DNS.

  • Le temps lié au fonctionnement du protocole TLS.

  • Les informations concernant la validité du certificat TLS.

Pour réaliser un test, l’exporteur doit être lancé et appelé à l’aide d’une requête à laquelle l’utilisateur doit donner les paramètres suivants :

  • Le module permettant de réaliser le test.

  • L’adresse à tester.

L’exporteur blackbox est disponible sous la forme d’une archive contenant le binaire. Il se télécharge à l’adresse suivante : https://github.com/prometheus/blackbox_exporter

Dans le cas de la version 0.19.0 (dernière version au moment de la rédaction de ce livre) pour Linux sur architecture AMD64, l’archive prend le nom suivant : blackbox_exporter-0.19.0.linux-amd.tar.gz.

b. Installation de l’exporteur

Récupérez la dernière version de l’exporteur puis décompressez l’archive à l’aide de cette commande :

$ tar xfvz blackbox_exporter-0.19.0.linux-amd64.tar.gz

Pour placer l’exporteur dans le répertoire /opt/blackbox_exporter, utilisez l’instruction suivante :

$ sudo tar xfvz blackbox_exporter-0.19.0.linux-amd64.tar.gz \ 
      -C /opt --transform='s/exporter-.*-amd64/exporter/'

Voici la sortie renvoyée...

Support du protocole SNMP

1. Contexte

Le protocole SNMP (Simple Network Management Protocol, soit en français protocole simple de gestion réseau) a pour but d’administrer, de surveiller et de diagnostiquer des problèmes sur des équipements réseau.

Ce protocole est souvent présent sur les composants suivants :

  • Les éléments réseaux classiques (switchs, ponts, routeurs).

  • Les baies de disques.

  • Les composants de distribution d’énergie (PDU soit Power Distribution Unit).

Il permet d’obtenir des informations sous forme arborescente des caractéristiques d’un composant matériel comme par exemple la température d’un capteur  la vitesse d’une interface réseau, l’occupation CPU du système, etc.

Le sujet est relativement vaste et réclame d’avoir quelques connaissances préliminaires aussi bien pour la mise en place que pour l’utilisation. Pour en savoir plus sur le sujet, n’hésitez pas à consulter l’article Wikipedia : https://fr.wikipedia.org/wiki/Simple_Network_Management_Protocol

L’avantage de ce protocole (dont la première itération remonte à 1989) est qu’il est très répandu et supporté par de nombreux constructeurs. Il s’agit d’une excellente solution pour surveiller des éléments réseau qui ont peu de chance d’avoir un point d’entrée Prometheus natif.

L’exporteur fait le pont entre Prometheus et ce mécanisme de surveillance historique. Au niveau mise en œuvre, son fonctionnement est relativement similaire à celui du Blackbox.

2. Mise en place de l’exporteur

a. Présentation de l’exporteur

L’exporteur SNMP est disponible sous la forme d’une archive. Il se télécharge à l’adresse suivante : https://github.com/prometheus/snmp_exporter

La dernière version disponible est la version 0.20.0. Pour Linux sur architecture AMD64, l’archive porte le nom suivant : snmp_exporter-0.20.0.linux-amd64.tar.gz.

b. Installation de l’exporteur

Décompressez l’exporteur à l’aide de la commande suivante :

$ tar xfvz snmp_exporter-0.20.0.linux-amd64.tar.gz

Pour placer l’exporteur directement dans le répertoire...

Surveillance à l’aide du module Push Gateway

1. Contexte

Jusqu’à maintenant, la surveillance mise en œuvre avec Prometheus s’est toujours appuyée sur la consultation directe des différents éléments à surveiller. Toutefois, ce modèle n’est pas toujours applicable :

  • Interdiction de consulter des composants pour des raisons de sécurité (équipements derrière un pare-feu).

  • Le composant à consulter n’est pas allumé en permanence.

Pour les problématiques de sécurité, il est recommandé de déployer Prometheus au plus près des composants à surveiller et d’éviter d’intercaler des composants de sécurité. Il reste ensuite à utiliser un mécanisme de fédération des données pour centraliser ces dernières (cf. chapitre Agrégation et archivage sur le sujet).

En revanche, pour un système qui ne fonctionne pas tout le temps, Prometheus devra forcément changer de mode de fonctionnement.

On retrouve ce type de problème avec les exemples typiques suivants :

  • Un traitement de données (on parle généralement de batch) lancé à intervalle régulier.

  • Une sonde autonome de type IoT (Internet of Things) qui se réveille à intervalle régulier.

Un traitement de données (ou batch) est par nature éphémère : il n’est pas possible de le surveiller à l’aide de Prometheus. En revanche, il est intéressant de disposer du résultat de son lancement.

Dans le cas d’une sonde, on cherche à obtenir des valeurs de l’environnement (température, taux d’humidité, etc.) tout en consommant le moins possible de ressource électrique ; en mettant les sondes d’acquisition en veille profonde par exemple. Ces dernières se réveillent à intervalle régulier (toutes les minutes, heures ou tous les jours), envoient leurs données puis replongent aussitôt en attente.

Le composant de Push Gateway est spécialement conçu pour répondre à ce type de besoin : accepter des métriques de l’extérieur pour ensuite les mettre à disposition de Prometheus.

2. Limitations...