Centreon

  • Règle de nommage des services Windows

    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.

     

    Lire la suite« Règle de nommage des services Windows »

  • Mise en place de la réplication des bases

    Préparation du compte Mysql

    Sur les 2 serveurs Mysql

    • Arrêter les bases de données
    • Modification du compte mysql
    • Génération des clés ssh
    • Echange des clés ssh entre les serveurs bases de données
    • Copier le contenu de la clé publique du serveur DB1 sur DB2 et inversement dans le fichier ~/.ssh/authorized_keys
    • Modifier les droits du fichier
    • Tester les connexions

    Configuration de MariaDB

    • Ajouter les lignes suivantes dans le fichier /etc/my.cnf.d/centreon.cnf
    • Penser à mettre 1 pour le master et 2 pour le slave
    • Laisser le read_only commenté

    Redémarrer le services sur les 2 serveurs

    Lire la suite« Mise en place de la réplication des bases »

  • Installation d’un cluster à 4 nœuds

    Prérequis

    Compréhension

    Connaissances Indispensables :

    • Linux
      • Shell
      • Gestion des utilisateurs
      • LVM
    • Fonctionnement de centreon

    Avant de suivre cette procédure, il est recommandé d’avoir un niveau de connaissance satisfaisant du système d’exploitation Linux, de Centreon et des outils de clustering Pacemaker-Corosync pour bien comprendre ce qui va être fait et savoir résoudre un éventuel incident. En pointillé sur les schémas ci-dessous les flux en attente.

    Fonctionnement initial de la plateforme ( Site A)

    Bascule sur le site secondaire (Site B)

    Lire la suite« Installation d’un cluster à 4 nœuds »

  • Centreon Auto-discovery

    Présentation

    Centreon autodiscovery est un module centreon permettant la détection des disques, FS,interfaces réseau des équipements physiques.

    Fonctionnement

    • Un crontab sur le serveur central lance toutes les règles actives
    • Centreon lance une commande snmpget pour déterminer les éléments à superviser
    • Applique la règle de découverte :
    • Rattache le bon template (Host ou Service) en fonction des éléments découverts
    • Applique les différents filtres en fonction des paramétrages de la règle
    Lire la suite« Centreon Auto-discovery »

  • Règle de nommage des services Linux

    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 😀

     

    Lire la suite« Règle de nommage des services Linux »

  • Règle de nommage des services

    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

     

    Lire la suite« Règle de nommage des services »

  • Règles de nommage des objets

    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
    Lire la suite« Règles de nommage des objets »