Superviser sa supervision – part 2

This post is also available in: Anglais

Nous avons vu au courant de l’été la théorie : Superviser sa supervision – partie 1, il est temps de passer à la pratique !!! Et oui, les vacances sont bien loin et il est grand temps de reprendre en main sa plate-forme de supervision.

Un peu de lecture

Avant de commencer la pratique, une bonne lecture des différents articles précédents est nécessaire :

Théorie

La supervision de la plate-forme de supervision doit être au minimum croisée.
Dans le cas d’une architecture distribuée, l’un des collecteurs distant doit superviser les processus du serveur central, tandis que le serveur central supervisera l’ensemble des processus des collecteurs distants.

Note : Pour ceux qui désireraient avoir la plate-forme de supervision la plus sûre, le must serait d’avoir une plate-forme de supervision déportée supervisant la plate-forme de supervision. Ce système permettrait de garantir le bon fonctionnement de la plate-forme de supervision nominale. Le niveau ultime (c’est-à-dire au-dessus du must ;)) serait en plus d’avoir cette seconde plate-forme redondée garantissant ainsi le bon taux de disponibilité des données supervisées.

Pour ceux qui ne disposent que d’un serveur central simple, il est recommandé de ne superviser que les points suivants :

  • Un multiplexeur de flux (Centreon Broker, NDOutil, …);
  • Un serveur de présentation Web (Apache, ….);
  • Une interface de configuration et de présentation de la collecte (Centreon Web);
  • Un serveur de bases de données MySQL (déporté ou non);
  • Des bases de données : « centreon », « centreon_storage »;
  • Des bases de données de type RRD pour la génération de graphiques de performance;
  • • Des processus de traitement Centreon (workflow);
  • • L’état du système d’exploitation (CPU, Mémoire, espace disque, …);

Pour ceux qui disposent d’un environnement distribuée, la liste est la suivante :

  • Pour le serveur central depuis un collecteur :
    • Un moteur de supervision (Centreon Engine, Nagios, …) ;
    • Un multiplexeur de flux (Centreon Broker, NDOutil, …) ;
    • Un serveur de présentation Web (Apache, ….) ;
    • Une interface de configuration et de présentation de la collecte (Centreon Web) ;
    • Un serveur de bases de données MySQL (déporté ou non) ;
    • Des bases de données : « centreon », « centreon_storage » ;
    • Des bases de données de type RRD pour la génération de graphiques de performance ;
    • Des processus de traitement Centreon (workflow) ;
    • Des journaux d’évènements (logs) ;
    • Des processus de notifications ;
    • L’état du système d’exploitation (CPU, Mémoire, espace disque, …) ;
  • Pour les collecteurs depuis le serveur central :
    • Un moteur de supervision (Centreon Engine, Nagios, …) ;
    • Un multiplexeur de flux (Centreon Broker, NDOutil, …) ;
    • Une interface de configuration et de présentation de la collecte (Centreon Web) ;
    • Des journaux d’évènements (logs) ;
    • Des processus de notifications ;
    • L’état du système d’exploitation (CCPU, Mémoire, espace disque, …) ;

Dans la pratique

Dans la pratique, cela est un peu plus complexe. En effet, nous n’allons pas installer d’agent de supervision sur les collecteurs afin de contrôler les journaux d’évènements et autre processus demandant l’exécution de commandes locales. Pour cela, nous allons utiliser des protocoles simples tels que SNMP, HTTP, SQL.

Contrôle d’accès à l’interface Web Centreon

Nous allons contrôler l’état du serveur apache via le module ‘mod_status’. La configuration du chargement du module est disponible sur internet et nous ne nous y attarderons pas. De même pour la mise en place du contrôle ‘check_apache_status’, disponible sur le site Monitoring Exchange.

Créez la commande suivante :

  • Nom de la commande : APP-Apache-Status
  • Ligne de commande : $USER1$/check_apache_status.pl -H $HOSTADDRESS$

commandapache_uec1

Puis créez le service associé à l’hôte représentant votre serveur Centreon (cet hôte doit être contrôlé par un collecteur distant si possible) :

  • Nom du service : Apache-status
  • Modèle de service : generic-service
  • Commande de contrôle : APP-Apache-Status

serviceapache_uec2

Le résultat du contrôle sera le suivant :

resultatapache_uec3

Remarque : vous pouvez contrôle en plus l’accès à l’interface Centreon via la sonde ‘check_http’ et créer une dépendance de service sur celui précédemment créé ; permettant ainsi de générer un rapport de disponibilité à l’interface web Centreon.

Contrôle de l’état du serveur de bases de données MySQL

Nous allons utiliser le plugin communautaire ‘check_mysql’ disponible dans les plugins standards de Nagios©.

Créez la commande suivante :

  • Nom de la commande : DB-MySQL
  • Ligne de commande : $USER1$/check_mysql -H $HOSTADDRESS$ -u $_HOSTMYSQLUSER$ -p $_HOSTMYSQLPASSWD$

commanddemysql_uec4

Note : cette commande utilise des macros personnalisées (custom macro).

Puis créez le service associé à l’hôte représentant votre serveur Centreon (cet hôte doit être contrôlé par un collecteur distant si possible) :

  • Nom du service : MySQL-status
  • Modèle de service : generic-service
  • Commande de contrôle : DB-MySQL

servicemysql_uec5

Note : ajoutez les macros suivantes et leur valeur associée à votre hôte :

  • MYSQLUSER
  • MYSQLPASSWD

Le résultat du contrôle sera le suivant :

resultatsql_uec6

Remarque : il est tout à fait possible de superviser de manière plus approfondi le SGBD ainsi que les bases de données hébergées par ce dernier.
La sonde communautaire ‘check_mysql_health’ permettra en autre de tester :

  • Les buffers et caches MySQL/InnoDB ;
  • Les requêtes lentes (slow queries) ;
  • L’usage des index ;
  • Le temps de connexion au SGBD ;

Note : N’oubliez pas d’ajouter les droits de lecture distante sur le SGBD au collecteur exécutant le test.

Contrôles systèmes du serveur

Nous allons ici utiliser les plugins standards de Nagios© et Centreon.

Créez les commandes suivantes :

  • Nom de la commande : OS-Linux-SNMP-CPU
  • Ligne de commande : $USER1$/check_centreon_snmp_cpu -H $HOSTADDRESS$ -C $_HOSTSNMPCOMMUNITY$ -v $_HOSTSNMPVERSION$ -w $_SERVICEWARNING$ -c $_SERVICECRITICAL$

commandserveurcpu_uec7

  • Nom de la commande : OS-Linux-SNMP-Load
  • Ligne de commande : $USER1$/check_centreon_snmp_loadaverage -H $HOSTADDRESS$ -C $_HOSTSNMPCOMMUNITY$ -v $_HOSTSNMPVERSION$ -w $_SERVICEWARNING$ -c $_SERVICECRITICAL$

commandserveurload_uec8

  • Nom de la commande : OS-Linux-SNMP-Memory
  • Ligne de commande : $USER1$/check_centreon_snmp_memory -H $HOSTADDRESS$ -C $_HOSTSNMPCOMMUNITY$ -v $_HOSTSNMPVERSION$ -w $_SERVICEWARNING$ -c $_SERVICECRITICAL$

commandserveurmemory_uec9

  • Nom de la commande : OS-Linux-SNMP-FS
  • Ligne de commande : $USER1$/check_centreon_snmp_remote_storage -H $HOSTADDRESS$ -C $_HOSTSNMPCOMMUNITY$ -v $_HOSTSNMPVERSION$ -d $_SERVICEFSNAME$ -n -w $_SERVICESNMPWARNING$ -c $_SERVICECRITICAL$

commandserveurfs_uec10

  • Nom de la commande : OS-Linux-SNMP-Traffic
  • Ligne de commande : $USER1$/check_centreon_snmp_traffic -H $HOSTADDRESS$ -C $_HOSTSNMPCOMMUNITY$ -v $_HOSTSNMPVERSION$ -i $_SERVICEINTERFACENAME$ -n -w $_SERVICESNMPWARNING$ -c $_SERVICECRITICAL$

commandserveurtraffic_uec11

Puis créez les services associés :

  • CPU :

servicecpu_uec12

  • Load :

serviceload_uec13

  • Mémoire :

servicememory_uec14

  • Trafic :

servicetraffic_uec15

  • File System :

servicefs_uec16

Note : Ne pas oublier de renseigner les champs « SNMP Community & Version » sur la définition de votre hôte.
Le résultat sera celui-ci :

resultatserveur_uec17

Supervision des processus

La supervision des processus se fera au moyen du plugin Centreon ‘check_centreon_snmp_process’ disponible en standard dans Centreon.
Créez les commandes suivantes :

  • Nom de la commande : OS-Linux-SNMP-Process
  • Ligne de commande : $USER1$/check_centreon_snmp_process -H $HOSTADDRESS$ -C $_HOSTSNMPCOMMUNITY$ -v $_HOSTSNMPVERSION$ -p $_SERVICEPROCESSNAME$

commandprocess_uec18

Puis créez le service suivant :

serviceprocess_uec19

Faites de même pour les processus :

  • Processus Apache : httpd
  • Processus Centcore : centcore
  • Processus Centreon Broker : cbd
  • Processus CRON : crond
  • Processus MySQL : mysqld
  • Processus NTP : ntpd
  • Processus Rsyslog : rsyslogd
  • Processus traps SNMP : snmptrapd

Le résultat est le suivant :

resultatprocess_uec20

Contrôler les collecteurs distants

Pour les collecteurs distants, reprenez les contrôles précédemment créés :

  • OS :
    • CPU ;
    • Load ;
    • Memory ;
    • FS-<nom de la partition> ;
    • Traffic-<nom de l’interface> ;
  • Processus :
    • Centreon Engine ;
    • Cron ;
    • NTP ;
    • Rsyslog ;
    • Traps SNMP ;

Contrôles additionnels

De nombreux contrôles supplémentaires pourraient être rajoutés afin de vérifier plus en profondeur le serveur Centreon :

  • Contrôler chaque partition du serveur (/var/log, /var/lib/mysql, /var/lib/centreon, …) ;
  • Contrôler les erreurs présentes dans les journaux d’évènements de Centreon Engine, Centreon Broker, processus Centreon (/var/log/centreon/*.log) ;
  • Contrôler les erreurs de paquets des interfaces réseau du serveur ;
  • Contrôles d’accès au(x) serveur(s) de mails (POP, IMAP, SMTP, …) ;

Les résultats

Une fois le paramétrage en place, vous devriez avoir une supervision ressemblant à celles-ci pour le serveur Centreon :

resultatserveurcentral_21

Pour les collecteurs :

resultatspollers_22

Alors, vous vous en êtes sorti ?

Incoming search terms:

  • superviser apache avec shinken

Leave a Reply