FAMEL Yoan 02/12/2015 PAYET Yoann BTS SIO – SISR
SISR5 Supervision des réseaux Mise en place d'un outil de supervision – Deuxième partie
Table des matières Introduction...... 2 Infrastructure réseau...... 3 Supervision de serveurs sous Windows...... 4 Mise en place de contrôles (sondes) de supervision d'un serveur sous Windows...... 4 Configuration de Shinken...... 10 Supervision de matériels...... 15 Supervision d'une imprimante réseau...... 15 Supervision d'un routeur...... 16 Supervision d'un commutateur...... 20 Utilisation d'indications métrologiques graphiques...... 24 Notifications des alertes...... 34
1 / 44 Introduction
Dans la deuxième partie TP nous allons nous intéresser à l'utilisation du service de supervision Shinken, cette application permet la surveillance système et réseau y compris les hôtes et les services spécifiés, évoluant sous une licence libre de type GNU AGPL (licence publique générale Afero) cette dernière est complètement compatible avec le logiciel Nagios.
« Elle a pour but d'apporter une supervision distribuée et hautement disponible facile à mettre en place. Démarrée comme une preuve de concept pour Nagios sur les architectures distribuée, le programme a rapidement démontré des performances et une flexibilité bien plus importantes que son aîné Nagios. »
Source : https://fr.wikipedia.org/wiki/Shinken_(logiciel)
Nous nous placerons donc en contexte professionnel en supposant qu'une entreprise ai besoin de nos services afin d'effectuer une meilleure supervision de ses matériels, entre autre, deux serveurs virtualisés et les services qu'ils hébergent, une imprimante réseau, un serveur de virtualisation ainsi que des outils d'interconnexions tel qu'un routeur et un commutateur Cisco Systems.
Dans cette partie nous traiterons plus précisément la supervision des matériels de couche 2 et 3 (commutateur, routeur) ainsi qu'un Windows serveur et une imprimante.
2 / 44 Infrastructure réseau
Nous allons donc mettre le réseau suivant en place et nous ferons un rappel des différents adressages du matériel à la suite.
Adresse IP Masque Passerelle
RTR S0/0 FE0/0 S0/0 FE0/0 172.16.193.3 172.16.193.254 255.255.255.0 255.255.0.0
COMM (VLAN1) 172.16.193.253 255.255.0.0 172.16.193.254 ServeurShinken 172.16.193.1 255.255.0.0 172.16.193.254 SRV1-Linux 172.16.193.10 255.255.0.0 172.16.193.254 SRV2-W2012 172.16.193.40 255.255.0.0 172.16.193.254
L'accessibilité via Internet ne sera pas démontrée dans ce TP.
3 / 44 Supervision de serveurs sous Windows
Mise en place de contrôles (sondes) de supervision d'un serveur sous Windows
Nous allons à présent nous intéresser au monitorage de notre serveur évoluant sous Windows avec l'aide de WMI.
Qu'est ce que WMI ? « Windows Management Instrumentation (WMI) est l’implémentation de Microsoft du Web-Based Enterprise Management (WBEM), le standard du Distributed Management Task Force (DMTF). Il prend en charge le modèle de données CIM (Common Information Model), qui décrit les objets d'un environnement de gestion. »
WMI est donc un système de contrôle interne et propre à Microsoft qui prendra en charge la surveillance et le contrôle des ressources systèmes.
Les contrôles nécessitent en effet d'avoir une interaction avec le système (un peu comme les requêtes ICMP en quelque sorte), pour cela notre Windows server devra en être au courant.
Nous devrons donc activer et autoriser l'accès aux informations présentes sur notre serveur.
Dans un premier temps, nous ajoutons un rôle à notre serveur, dans fonctionnalités nous implantons le service SNMP (le protocole simple de gestion de réseau) et le fournisseur WMI SNMP :
4 / 44 Nous passons ensuite les étapes de manière à valider le redémarrage de notre serveur.
5 / 44 La progression de l'installation s'affiche alors, le serveur redémarrera une fois celle-ci terminée :
Nous allons ensuite y créer un nouvel utilisateur se nommant wmiagent spécifique pour la supervision du serveur du serveur en l'associant à WMI, pour cela nous nous placerons dans le dossier Utilisateurs et dans le menu Action nous choisirons Nouvel utilisateur :
Cet utilisateur obtiendra le mot de passe SIO2pass.
Nous cocherons les choix de gestion de mot de passe.
Puis nous cliquons sur Créer.
6 / 44 Le nouvel utilisateur apparaît alors dans le dossier les concernant :
Nous affecterons ensuite cet utilisateur à un groupe supplémentaire afin qu'il puisse accéder à tous les indicateurs Windows, nous double-cliquons sur cet utilisateur, puis dans l'onglet Membre de nous l'ajoutons :
7 / 44 Nous sélectionnerons ensuite Avancé en bas de l'interface puis nous rechercherons le groupe Utilisateurs de l'Analyseur de performances.
Nous cliquerons trois fois sur OK afin de revenir à la liste des utilisateurs.
En cliquant de droite sur contrôle WMI dans la liste se trouvant à gauche de l'écran, nous choisissons propriétés, puis dans l'ongelt Sécurité nous sélectionnons CIMV2 puis nous cliquons sur Sécurité, nous saisirons le nom de wmiagent puis vérifier les noms et enfin nous cliquerons sur OK.
Dans la fenêtre qui suit nous sélectionnons les cases comme suit :
Notre utilisateur doit également pouvoir accéder à DCOM (Distributed Component Object Model) pour permettre l'accès aux informations du système.
8 / 44 Nous ouvrons donc un terminal de Windows PowerShell et nous lançons la commande DCOMCnfg.exe comme suit :
Puis, dans Service de composants/Ordinateurs nous cliquons de droite sur Poste de travail et nous sélectionnons Propriétés.
Dans l'onglet Sécurité COM puis dans Autorisations d’exécution et d'activation nous choisissons Modifier les limites, sur la fenêtre d'autorisation nous choisissons Ajouter puis, nous saisissons wmiagent et nous vérifions les noms. Pour terminer nous cliquons sur OK :
Dans la fenêtre suivante nous cochons les cases comme suit :
Puis nous cliquons sur OK et nous confirmons les paramètres.
Nous fermons ensuite la fenêtre des composants et de Microsoft PowerShell.
9 / 44 Nous devons enfin paramétrer le pare-feu afin de laisser entrer les requêtes WMI, dans le gestionnaire de serveur et dans le menu Outils nous sélectionnons Pare-feu Windows avec fonctions avancées de sécurité.
Enfin dans les règles de trafic entrant nous activons les règles suivantes :
(Nous activerons la règle WMI-In et non Async-In comme précisé ci-dessus).
Configuration de Shinken
Il ne nous reste donc plus qu'à configurer notre serveur Shinken.
Nous passons sur le compte root et nous paramétrons le compte d'accès au domaine que nous avons choisi plus tôt en éditant le fichier suivant :
Nous remplaçons les valeurs par défaut par celles que nous avons pu créer.
On relance ensuite le processus arbiter qui va faire une re-lecture des fichiers :
10 / 44 Nous allons maintenant corriger une erreur liée au wmic (client WMI), notre fichier téléchargé en première partie intervient donc.
Nous nous plaçons dans le dossier des commande python et nous effaçons wmic à l'aide des commandes suivantes :
cd /var/lib/shinken/libexec rm wmic
Puis nous nous plaçons dans le dossier de Téléchargements afin de dézipper le fichier et d'extraire l'archive avec les commandes suivantes :
Puis nous configurerons et compilerons le wmic avec les commandes suivantes :
./autogen.sh ./configure make proto bin/wmic
En voici un exemple :
11 / 44 Puis nous copions wmic dans le dossier Shinken, nous nous plaçons dans le dossier des commandes et nous attribuons la propriété de wmic à l'utilisateur Shinken comme suit :
Il ne reste maintenant plus qu'à tester le fonctionnement de notre client WMI.
Nous repassons donc sur le compte shinken grâce à la commande su – shinken et nous repassons dans le dossier des commandes python :
cd /var/lib/shinken/libexec
Nous testons ansuite l'accès aux données de WMI en saisissant la commande :
Les données récupérées via WMI ressemble à cela :
12 / 44 Nous retournons sur le compte root.
Puis nous éditons le fichier de configuration de l'hôte que nous surveillerons, autrement dis, notre serveur Windows :
Nous avons donc ajouté notre modèle de supervision à la déclaration de notre hôte. Nous enregistrons et quittons.
Puis nous relançons arbiter pour une re-lecture des fichiers :
13 / 44 Une fois retourné dans l'interface web de notre serveur Shinken, nous filtrons l'affichage de manière à n'avoir uniquement notre serveur Windows :
Une vision synoptique est également possible grâce à la Minemap :
Nous avons donc réussis avec succès à superviser notre serveur Windows.
14 / 44 Supervision de matériels
Supervision d'une imprimante réseau
Dans la console administrateur nous nous replaçons en tant que Shinken puis nous créons le fichier de configuration de l'imprimante qui sera à surveilller :
Nous enregistrons et quittons. Ici le modèle printer précisé envoi un ping à l'imprimante et mesure le délai d'attente.
Nous relions ensuite notre imprimante à notre commutateur. Puis nous relançons le processus arbiter. Dans l'interface web et dans le menu All nous attendons que la sonde passe à UP :
15 / 44 Supervision d'un routeur
Pour la supervisions de notre routeur, nous devrons au préalable installer la commande check_nwc_health qui servira à monitorer les matériels réseau. Le fichier téléchargé en première partie nous sera nécessaire.
Nous nous plaçons donc le dossier des Téléchargements et nous extrayons le fichier avec les commandes suivantes :
Puis, nous entrons le dossier extrait et nous configurons et compilons check_nwc_health grâce aux commandes qui suivent :
./configure make make install
En voici un extrait :
Enfin, nous copions check_nwc_health dans le dssier Shinken avec la commande :
Cp plugins-scripts/check_nwc_health /var/lib/shinken/libexec
16 / 44 Nous nous plaçons ensuite dans le dossier des commandes :
cd /var/lib/shinken/libexec
Et nous attribuons la propriété de check_nwc_health à l'utilisateur Shinken à l'aide d'un chown :
Chown shinken:shinken check_nwc_health
Puis nous revenons ensuite à Shinken.
Nous créons le fichier de configuration du routeur à surveiller :
Nous enregistrons et quittons.
Les sondes que nous utilisons utiliserons le protocole SNMP nous allons donc devoir activer cette fonctionnalité sur notre routeur Cisco, sans cela il ne répondrait pas.
17 / 44 Sur notre routeur donc, nous passons en mode configuration globale et nous créons une access-list restreignant l'accès au seul serveur de supervision et nous activons le service SNMP en lecture seule sur la communauté public et pour le serveur déclaré dans l'access- list 1 :
Puis nous vérifions la configuration en mode enable :
18 / 44 Sur le serveur Shinken nous relançons le service avec service-arbiter restart, une fois retourné dans l'interface web, nous attendons que les sondes passent en statut UP :
le statut de l'interface est critical parce que toutes les cartes du routeur ne sont pas actives, Shinken pense qu'il y a un problème grave, nous verrons par la suite comment ne surveiller qu'une seule carte :
On va donc tester la commande, nous passons sur le compte de Shinken, placer dans le dossier des commandes comme suit :
cd /var/lib/shinken/libexec
Et nous lançons la commande suivante pour tester l'usage de la mémoire du routeur :
19 / 44 Supervision d'un commutateur
Nous allons à présent superviser un commutateur, pour cela nous repassons sur le compte Shinken et nous retournons dans la console administrateur afin de nous placer dans le fichier hosts de Shinken afin de créer le fichier de configuration de notre commutateur :
Nous enregistrons et quittons l'éditeur de texte.
Les sondes utiliseront le protocole de contrôle SNMP nous allons donc activer ce service et le configurer sur notre commutateur à la même manière que notre précédent routeur.
Nous passons donc en mode configuration globale et nous tapons les commandes qui suivent :
20 / 44 Puis, nous vérifions la configuration :
En tant que Shinken sur ce même serveur nous relançons ensuite le processus arbiter.
21 / 44 Enfin dans l'interface web voici ce qu'il s'affiche lorsque le commutateur et ses composants sont fonctionnels :
Nous constatons que les interfaces sont considérés comme CRITICAL puisque seul trois sont reliées à un matériel, les autres sont éteintes.
Par défaut le statut des ports du commutateur est contrôlé par le script check_nwc_health.
Sur notre serveur Shinken nous repassons sur le compte Shinken, et nous nous plaçons dans le dossier des commandes et nous testons manuellement la sonde d'état des interfaces avec la commande qui suit :
Les états des interfaces s'affichent alors, la plupart sont down car non-reliées.
22 / 44 Nous allons donc essayer d'obtenir uniquement l'interface FastEthernet0/1 à laquelle est relié le serveur Esxi.
Nous testons donc dan un premier temps manuellement la sonde d'état des interfaces avec la commande suivante :
Seule l'interface apparaît alors et nous notifie qu'elle est bien en service.
Nous allons maintenant essayer de modifier la commande executée par le modèle switch en conséquence, nous repassons donc sur le compte root.
Et nous éditons les commandes définies pour le modèle switch en ajoutant l'attribut –- name au prototype de la commande check_switch_interfaces_status sur le premier define command :
Puis nous enregistrons et quittons l'éditeur de texte.
Nous éditons ensuite le fichier appelant la commande et l'attribue au modèle switch :
Nous modifions ici le nom du contrôle en ajoutant 1 derrière, puis nous enregistrons et quittons l'éditeur de texte et nous relançons arbiter.
23 / 44 En allant dans l'interface web nous pouvons alors observer le résultat :
A partir de maintenant, seule l'interface Fa0/1 sera supervisée par un contrôle dédié.
Utilisation d'indications métrologiques graphiques
Par défaut, Shinken nous présente graphiquement l'état de fonctionnement des composants, nous allons dans cette partie nous occuper de l'état des différents services grâce à des interfaces graphiques plus élaborées.
Les mesures faites sur notre serveur seront représentées graphiquement, pour cela, l'interface graphique PNP4Nagios basée sur un serveur web apache2 affichera au fur et à mesure les différentes mesures, cette interface recquière une base de données spécifique nommée RRD Tool (Round Robin Databases).
Nous relions donc notre serveur Shinken à internet afin de pouvoir installer les différents paquet dont nous aurons besoin par la suite, nous passons sur le compte root.
24 / 44 Nous installons dans un premier temps la base de données RRD Tool et ses librairies PERL grâce à la commande suivante (nous vérifions au préalable notre accès internet) :
Puis nous installons le service web Apache2 :
Nous rejoignons ensuite le site de Nagios :
25 / 44 Nous activons ensuite le module rewrite d'Apache qui sera utilisé par PNP4Nagios et nous redémarrons le service Apache :
service apache2 restart
Nous téléchargeons ensuite la dernière version stable de PNP4Nagios sur le site, cette dernière sera placée dans le répertoire des Téléchargements.
Dans ce même répertoire nous faisons ensuite une extraction du fichier récupéré en nous plaçant à l'intérieur :
Nous entrons ensuite dans le dossier décompressé et nous lançons la configuration :
Puis nous lançons les commandes de compilation et d'installation :
make all make install
26 / 44 Il faudra également nous occuper du service NPCD (Nagios-Perfdata-C-Deamon) qui se chargera du traitement des données de PNP4Nagios.
Nous configurons le démarrage automatique du service NPCD avec la commande suivante et nous le démarrons :
Nous changeons ensuite d'utilisateur en revant sur Shinken, puis nous installons les modules de NPCD et de PNP4Nagios :
Nous repassons sur l'utilisateur root pour terminer la configuration.
Nous éditons le fichier du module NPCD comme suit :
Nous vérifions ici que le chemin du dossier de configuration soit bien déclaré comme ci
27 / 44 dessus.
Nous éditons ensuite le fichier de configuration du module PNP4Nagios :
Nous modifions la ligne concernant l'url en remplaçant la valeur par l'IP de notre serveur de supervision. Nous enregistrons le fichier.
Nous éditons maintenant le fichier de l'interface graphique Webui2 et nous déclarons le module PNP4Nagios de la manière qui suit :
Nous enregistrons la configuration.
Puis, nous éditons enfin le fichier de configuration du processus broker :
28 / 44 Nous ajoutons ici le module de traitement des données, puis nous enregistrons.
Nous relions ensuite à nouveau notre serveur Shinken à notre réseau en lui rétablissant son adressage IP, puis nous relançons Shinken.
Nous allons maintenant passer à la phase finale avec quelques réglage de plus nécessaires au fonctionnement de PNP4Nagios. Nous désactiverons les paramètres d'authentification propre à cette nouvelle interface, mais il est conseillée de les remettre dans un cas réel.
Nous effaçons donc les fichiers d'installation de l'interface PNP4Nagios avec la commande suivante :
rm -f /usr/local/pnp4nagios/share/install.php
Puis nous ouvrons le fichier de configuration de PNP4Nagios :
Nous supprimons ici l’authentification en commentant les lignes ci dessus.
Puis, nous redméarrons le service NPCD.
Après ce quelques configurations nous avons ajouté une interface graphique à Shinken ainsi que des fonctionnalité graphiques avancées.
Dans l'interface graphique nous pouvons repérer le nouvel élément de menu :
29 / 44 Nous parcourons donc l'affichage en attendant que les données s'affichent.
Puis, notre nouvelle interface graphique apparaît :
Il est possible de déterminer un laps de temps, ici notre choix se porte sur 4 heures. Il est également possible de choisir un élément à surveiller (ici le cpu) :
30 / 44 Les statistiques internes au fonctionnement de PNP4Nagios sont également possible (graphique ci dessus).
Nous pouvons d'ailleurs exporter nos données au format PDF pour des conventions ou réunions :
31 / 44 On peut également de façon détaillée observer un graphique en faisant défiler les périodes de temps avec une échelle plus ou moins précise :
Nous pouvons filtrer en inscrivant le nom d'un des éléments du réseau dans la barre de recherche comme suit :
32 / 44 Un des avantages est que nous pouvons observer les graphiques au sein même de Shinken en survolant les indicateurs de mesures :
Puis dans l'onglet graphs du serveur Shinken :
33 / 44 Ainsi qu'en ajoutant un widget sur le dashboard :
34 / 44 Notifications des alertes
Notre objectif va être maintenant de surveiller le fonctionnement et de réagir en cas de problème. Il va donc nous falloir être prévenu par notre superviseur en cas de comportement anormal de notre système, il va donc nous notifier.
Shinken permet de notifier de nombreuses façons en cas de problème.
Nous ne disposons ici que de l'envoi de mails. Il nous faut donc un serveur de mails, nous en installerons un de ne recquièrant pas beaucoup de ressources afin de comprendre l'envoi des notifications.
Nous passons sur le compte root, et nous installons les fonctionnalités de message en html pour les scripts d'envoi de message Shinken avec la commande suivante :
Puis nous installons le serveur de messagerie Postfix :
apt-get install postfix
35 / 44 Nous indiquerons « site internet » par la suite :
Puis nous relions notre serveur Shinken à l'infrastructure et nous lui rétablissons son adressage IP.
Notre installation est cependant minimaliste, normalement notre service de mail attend un serveur DNS pour pouvoir gérer les noms de messagerie. Dans notre cas et pour des raisons de simplification, nous utiliserons le fichier /etc/hosts pour résoudre localement les noms, le serveur DNS cherchera donc dans ce fichier.
Nous éditons le fichier de configuration de Postfix comme suit :
36 / 44 Nous ajoutons ici la dernière ligne en fin de fichier puis nous relançons le service postfix avec la commande qui suit :
service postfix restart
Nous créons ensuite un utilisateur qui sera destinataire des notifications :
Notre test va consister en l'envoi en console d'un mail à destination de notre utilisateur adminShinken.
Nous envoyons donc un mail avec la commande suivante :
Nous faisons ctrl+D afin de sortir du message.
37 / 44 Dans un autre onglet nous nous connectons avec l'utilisateur adminshinken.
Puis nous relevons les mails et listons le contenu avec la commande :
Le message étant bien reçu, la messagerie est fonctionnelle. Nous faisons q afin de quitter la messagerie.
Ce type de messagerie en console est spécifique à Linux, elle sert pour les notifications du système. Cela nous évite donc d'avoir à installer une interface lourde surchargeant notre serveur.
Nous devons donc maintenant configurer les notifications de Shinken.
Ces dernières sont définies dans /etc/shinken/notificationways.
38 / 44 Nous affichons donc le contenu du fichier de configuration des courriels avec un cat :
Les emails sont donc envoyés 7 jours sur 7 et 24h sur 24 (24 x 7).
Les notifications sont envoyées pour les états c, w, r des hôtes et d, u, r, f, s des services.
Il existe donc plusieurs créneaux de notifications hormis celui de 24x7 ;
None jamais workhours Uniquement durant les heures de bureau us-holidays Uniquement les jours fériés étatsuniens
Afin de comprendre la période 24x7 nous allons vérifier son fichier de configuration. On affiche donc le contenu du fichier de configuration des périodes de notification 24x7 :
39 / 44 Ici les notifications sont constantes.
Il nous faut ensuite déclarer le contact adminshinken dans Shinken.
On créer donc un nouveau fichier de configuration de contact :
Il nous donc les contacts notifiés dans Shinken.
On remarque ici qu'il existe un groupe admins :
Il faut donc ajouter notre contact adminshinken à ce groupe à ce groupe afin qu'il puisse recevoir les notifications. On édite donc le groupe admins comme suit :
On relance ensuite Shinken.
40 / 44 Il nous reste maintenant à savoir quand nous allons être notifiés et à quelle fréquence. Il va donc falloir examiner les fichiers de configuration des commandes de supervision.
On affiche donc le monitorage des disques via snmp comme suit :
On comprend ici que le service de monitorage des disques utilise le modèle de notification 1hour_long.
On affiche ensuite les différents modèles de notification comme ceci :
41 / 44 Trois principaux paramètres vont nous intéresser ici :
max_check_attempts Nombre de checks renvoyant une erreur avant l'envoi de notification normal_check_interval Temps entre deux checks renvoyant une erreur retry_interval Temps entre deux checks ne renvoyant pas d'erreur
Ce modèle nous intéressera donc pour avoir des notifications assez rapidement.
On édite ensuite le fichier de monitorage des disques via SNMP comme suit :
On va donc provoquer une panne en insérant un disque dans le serveur, cela aura pour effet de provoquer une erreur critique « disque plein », les disques ne pouvant être inscriptibles donc limités en tailles.
On insère donc une image .iso dans le lecteur de notre serveur virtuel.
42 / 44 L'erreur suivante va donc nous être remontée :
Dans un nouvel onglet, on se connecte ensuite avec l'utilisateur approprié et nous relevons les mail avec la commande mail. La messagerie nous est remplie d'alertes concernant cette même erreur :
43 / 44 Il est également possible de configurer Shinken avec sa propre boite mail grâce au tutoriel présent ci dessous :
https://marouanromualdo.files.wordpress.com/2015/06/tutoriel-shinken2.pdf
44 / 44