Centreon

  • 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 »

  • Organiser ces indicateurs dans la vue monitoring

    But de cet article

     

    Le but de cet article est de vous présenter comment vos indicateurs seront :

    • Plus compréhensibles
    • Regroupés par périmètre de supervision
    • Plus visibles pour vos équipements que vous superviser

    Dans mon travail de tous les jours, j’avoue que les règles que je vais vous présenter m’aident grandement.

    Elles permettent :

    • Pour novice en supervision, de comprendre l’objet de configuration qu’il est en train de manipuler sans ambiguïté.
    • Faciliter la gestion des ACLs
    • dans l’exploitation de la supervision :
      • D’optimiser la compréhension des indicateurs qui sont présentés
      • De comprendre le domaine d’application de l’indicateur

     

    Lire la suite« Organiser ces indicateurs dans la vue monitoring »