Préambule

Pour moi la supervision des serveurs linux est des plus intéressantes :

• C’est un système ouvert
• L’Os est suffisamment robuste pour permettre de prendre la main sur le serveur même si un service est défaillant
• Il n’y a pas ou très peu de boite noires
• Les fichiers de logs sont suffisamment parlant pour connaitre le hic 😀
• Avec une gestion par fichier, la gestion du serveur est relativement simple

La supervision d’un serveur Linux peut paraître simple.

Pour paraphraser la première phrase de « Linux pour les nuls » : Tout est fichier 😀

Une fois que l’on a dit cela, on a tout dit et rien dit non plus 😛

Essayons de comprendre le fonctionnement d’un serveur Linux.

Plusieurs aspects sont à prendre en compte :

• Le noyau de linux (je ne parlerais que des Os rencontrés en entreprise) :
  • Façon Debian
  • Façon RedHat
  • Façon SuSe (même si c’est assez proche de RedHat)
• Gestion du démarrage du serveur en fonction de la version de l’OS
  • Debian
    • Depuis Debian 9 : systemD
    • Avant Debian 8 : initD ou systemD
    • Avant debian 8 : initD
  • RedHat
    • Depuis RedHat7 : SystemD
    • Avant RedHat7 : initD

Il faut prendre en compte également ces différents.

Par exemple :

• iptables est devenu firewalld
• Le nom des interfaces à changer
• Les outils de gestion des paquets diffèrent
  • Debian : apt-get
  • RedHat : yum
  • SuSe : zipper ou yast2
• Et ce ne sont pas les seuls différences et ce n’est pas le sujet de l’article 😀

La supervision doit être capable de prendre en compte ces différents aspect, sans rendre la maintenance de la supervision plus complexe.

Dans la suite de l’article nous allons donc mettre en place les templates nécessaires pour la supervision d’un serveur linux en fonction du noyaux et de la version.

NB : Je ne parlerais donc pas des distributions « Exotiques » dans cet article 😀

Préambule

Nous pouvons dire merci à Mr Bill 😀 de nous avoir pondu un Os ayant des services dépendants de la langue choisie lors de l’installation ( et ça me donne du travail 😀 ).

Les conséquences un service SNMP s’appelera :

• Service SNMP en Français
• SNMP service en Anglais
• Je vous laisse imaginer dans les autres langues 😀

Cela à un impacte non négligeable dans la mise en supervision d’un serveur Windows.

Il va falloir créer un template Windows en fonction de la langue d’installation de l’Os. Et là on se dit WhouAAAAAA, il va falloir créer un template pour chaque langue ?

Et là, on se dit que cela va être galère si il faut gérer toutes les langues que Windows parle, mais c’est que la partie émergée de l’iceberg.

En effet ce n’est pas tout. En fonction de la version de ce super Os, certains services ont disparu, d’autres sont apparus.

L’expérience m’a monté que la supervision d’un serveur ZINDOWS (pour ceux qui auraient leur clavier en QWERTY 😀 ) nécessite de prendre en compte non seulement la version de l’Os mais aussi la langue dans laquelle il a été installé.

Merci de ne pas habité en Serbie ou en république Tchèque (gérer une langue en mode latin avec des caractères que je n’ai pas sur mon clavier et en cyrillique en plus 😀 ), j’ai que l’anglais et le français à gérer 🙂

Arrêtons les digressions et attaquons nous au vif du sujet.

Nous allons donc faire en sorte de prendre en compte les OS de la version 2000 à 2012 en français et en anglais ( j’ai eu des clients en NT4 même au 21ème siècle 😀 mais c’est pas le sujet).

Comment allons nous créer des Templates simple a maintenir et suffisamment flexibles pour ne pas avoir a faire des modifications dans tous les Templates afin d’avoir le résultat voulu.

Préambule

Nous allons voir dans cet article comment oraginiser ses templates de service et les indicateurs présentés dans la vue monitoring.

Règles de nommage des indicateurs

Comprendre les indicateurs

Règles de Nommage pour les services :

Les indicateurs sont organisés de la façon suivante de manière générale :

• Brique
• Famille
• Type
• Domaine
• Nom Indicateur

ci-dessous nous aurons :

• Le nom du template de service utilisé
• Le nom du service présenté dans la supervision

Un exemple lié à l’OS (Pour Linux)

TS_OS-Linux-Disk-/var-Usage –> Linux-Disk-/var-Usage

• Brique : OS
• Famille : Linux
• Type : Disk
• Domaine : <Nom du FS>
• Type Indicateur : Utilisation

TS_OS-Linux-Process-sshd-Status –> OS-Linux-Process-sshd-Status

• Brique : OS
• Famille : Linux
• Type : Process
• Domaine : <Nom du Process>
• Type Indicateur : Etat

TS_OS-Linux-SYS-Memory-Usage –> OS-Linux-SYS-Memory-Usage

• Brique : OS
• Famille : Linux
• Type : System
• Domaine : <Composant système>
• Type Indicateur : Utilisation

Un exemple applicatif

TS_App-DB-Oracle-Process-ora_pmon –> App-DB-Oracle-Process-ora_pmon

• Brique : APP(aplicatif)
• Famille : DB ( Database )
• Type : Oracle
• Domaine : Process(us)
• Nom Indicateur : ora_pmon

Liste des forces en présence

Préambule

Il n’est pas rare d’avoir des pages Centreon avec une liste interminable d’indicateur.

Quand nous utilisons l’ascenseur de notre indicateur et que nous sommes en bas de la page le menu disparaît et c’est la cata 😀

Je vais donc vous présenter un méthode perfectible mais simple d’identifier l’objet que vous êtes en train de manipuler.

Le chois de préfixer les objets est simple.

Cela permet :

• De ne pas modifier les templates fournis par centreon ( facilitant les mise à jours de Centreon)
• De faire dépendre nos templates préfixés des templates Centreon en les surchargeant selon nos besoins et en prenant en compte les correctifs que les mises à jours pourraient apporter.
• De faciliter la maintenance des objets structurant permettant de déploiement des indicateurs