Retour sur le Centreon Camp #6 du 18 juin 2016

Posted by on 27 Juin 2016 in Centreon, Conférences & Salons, Interviews, Planet, Supervision, Vie des sociétés | 0 comments

Voici le compte-rendu du Centreon Camp #6 du samedi 18 juin 2016. Le Centreon Camp est un événement communautaire organisé par Centreon pour informer ses utilisateurs et clients des nouveautés de leurs produits (Centreon, Centreon Web/Engine/Broker/MBI) et accueillir des présentations des membres de la communauté. Cette année, c’est Éric Coquard et Charles Judith qui ont présenté :

  • Les paquets Debian (non officiels) pour Centreon et un projet de déploiement de Centreon sur des Raspberry (Éric Coquard). Sa présentation est disponible en ligne.
  • Les TimeSeries Databases – NextGen Monitoring (Charles Judith)

Nous avons profité de l’événement pour filmer, avec l’aimable autorisation de Centreon et des participants et réalisé un montage. La vidéo est un peu longue (plus d’une heure), mais vous pouvez cliquer sur les liens ci-dessous pour voir la partie que vous souhaitez:

  • 00:00:00 : Introduction
  • 00:01:28 : interview de Julien Mathis, CTO de Centreon, sur la nouvelle stratégie produits de Centreon
  • 00:08:17 : interview de Julien Mathis, CTO de Centreon, sur la version 3.4 de Centreon et les nouveautés autour de Centreon Web/Engine/Broker
  • 00:22:27 : interview de Laurent Pinsivy, Product Manager, sur les projets communautaires Centreon Open Tickets et Centreon Plugins
  • 00:35:07 : déjeuner
  • 00:37:08 : interview d’Éric Coquard : Les paquets Debian (non officiels) pour Centreon et un projet de déploiement de Centreon sur des Raspberry
  • 00:50:57 : interview de Charles Judith : Les TimeSeries Databases – NextGen Monitoring

Musiques d’illustration disponibles sur Youtube Audio Library :

  • 00:00:00 : Locally sourced de Jason Farnham
  • 00:35:07 : Modus operandi (M.O.) de Wes Hutchinson
Read More

Appel à présentation pour le CentreonCamp #6 du samedi 18 juin 2016

Posted by on 30 Mai 2016 in Centreon, Conférences & Salons | 0 comments

L’équipe de Centreon organise son 6e CentreonCamp le samedi 18 juin 2016, dans ses nouveaux locaux du 46-52 rue Albert à Paris. Dans le programme, en dehors des sujets habituels sur les nouveautés et les prochaines versions, trois slots sont disponibles : les utilisateurs de Centreon qui souhaitent faire un retour, présenter un cas d’usage particulier, montrer l’architecture mise en place dans leur entreprise ou tout autre sujet qu’ils jugent pertinents sont invités à contacter l’équipe : community@centreon.com.

 

Read More

Sorties mineures : Centreon 2.6.1 et CES 3.2

Posted by on 17 Juin 2015 in Centreon, Interviews, Supervision | 0 comments

Le 27 mai 2015, l’équipe de développement de Centreon a annoncé la sortie de deux versions :

Monitoring-fr a interviewé Julien Mathis, Directeur technique de Centreon pour l’interroger sur ces deux sorties. Vous pouvez retrouver l’enregistrement audio en fin d’article.

Points principaux de la version 2.6.1 de Centreon

Cette version 2.6.1 de Centreon est une version de maintenance. Comme souvent chez Centreon, la version 2.x.1 sort quelques jours ou quelques semaines après la version 2.x afin d’intégrer les principaux retours de bug formulés par les utilisateurs. C’était notamment le cas pour :

  • la 2.1.1 sortie le 25/09/2009, 4 jours après la 2.1 sortie le 21/09/2009
  • la 2.3.1 sortie le 17/10/2011, 4 jours après la 2.3 sortie le 13/10/2011
  • la 2.4.1 sortie le 26/02/2013, 8 semaines après la 2.4 sortie le 07/01/2013

Peu de nouveautés dans cette version mais si vous avez mis à jour votre plate-forme vers la version 2.6, il est conseillé de passer à la version 2.6.1 pour corriger les bugs introduits dans la version 2.6.0.

Dans les nouveautés, il y a un point qui pourra perturber les utilisations. Il s’agit de [#6228] : lorsqu’un utilisateur ne disposera que du droit « Re-schedule the next check for a service (Forced) » et pas du droit « Re-schedule the next check for a service », le « (Forced) » ne sera pas affiché dans son interface. Cela pourra être perturbant pour l’administrateur qui configure les droits. En effet, l’administrateur supervision active un point et désactive un autre mais c’est celui qui est désactivé qui apparaît. Non, ce n’est pas un bug mais une fonctionnalité! Attention donc!

Un autre point qui pourra faire polémique : [#6392 : Block choice of Nagios and NDO in installation processus]. Centreon ne demande plus si vous disposez de Nagios et NDOUtils lors de l’installation. Par défaut, il considère que vous avez installé Centreon Engine et Centreon Broker. On peut se poser la question : comment va faire un administrateur lors de l’installation de Centreon lorsqu’il aura installé Nagios et NDOUtils?

Points principaux de la version 3.2 de CES

La version 3.2 de CES, Centreon Enterprise Server, est sortie le même jour que la version 2.6.1 de Centreon. Deux changements sont intégrés dans cette version :

  1. une amélioration de la documentation
  2. CES ne demande plus si vous préférez installer Nagios+NDOUtils ou Centreon Engine + Centreon Broker.

Les deux sorties semblent donc coordonnées dans le but de ne plus supporter Nagios+NDOUtils lors de l’installation. La question posée précédemment trouve sa réponse : la pile Centreon ne supporte plus l’installation de Nagios et NDOUtils.

Début de l’arrêt du support de Nagios dans la pile Centreon

Le message est clair de la part des développeurs de Centreon : Nagios (et NDOUtils) ne seront plus supportés à plus ou moins long terme. Cela commence par l’arrêt du support lors de l’installation. Puis progressivement, les fonctionnalités permettant de gérer Nagios dans l’interface Centreon seront supprimées. Cela se fera au fur et à mesure, en fonction des retours des utilisateurs. Il faut remarquer que la personne qui a fait la demande de supprimer le support de Nagios durant l’installation n’est pas un développeur de Centreon, ni un employé de la société Centreon, mais bien un utilisateur, il y a près d’un an et demi.

Que faire si ma plate-forme de supervision utilise Nagios?

Il est à noter que seul le support de l’installation de Nagios est supprimé : les fonctionnalités de gestion de Nagios de l’interface Centreon sont toujours présentes. Vous pouvez donc toujours utiliser Nagios. Si vous disposez d’une plate-forme CES avec Nagios et NDOUtils, cette plate-forme fonctionnera correctement encore quelques temps. Si vous avez une plate-forme CES composée de plusieurs serveurs et que vous avez besoin d’installer un nouveau serveur pour suivre la montée en charge, c’est un peu plus compliqué. Il vous faudra installer CES avec centreon-engine et centreon-broker. Puis remplacer ces paquets par nagios et ndoutils.

Cependant, à terme, il va vous falloir planifier ce changement. Le support complet de Nagios sera très probablement supprimé dans les prochaines années. Sera-ce dans la version 3.0 de Centreon? C’est une des questions que nous avons posé à Julien Mathis, Directeur Technique de Centreon? Nous vous invitons à écouter cette interview :

mp3mp3

Il est à noter que cette interview a été faite le 04/06/2015, à l’occasion du Meetup Monitoring Paris. Avant cette interview, l’équipe de Centreon n’avait pas et n’avait pas prévu de communiquer ouvertement sur ce point. C’est dorénavant chose faite sur leur blog

Read More

Automatisation de la supervision : exemple avec Centreon et Ansible (2)

Posted by on 21 Mai 2015 in Astuces, Centreon, Stratégies IT, Supervision | 0 comments

Dans l’article précédent, une introduction a été faite sur l’automatisation de la supervision. Dans cet article, des cas pratiques sont présentés, afin d’illustrer le sujet. Pour rappel, les outils utilisés (Centreon et Ansible) ne servent que de base à cet article, d’autres outils pouvant être utilisés, selon le besoin fonctionnel, la maîtrise des outils en interne, le besoin d’assistance ou de formation et l’offre disponible. Les cas pratiques présentés dans cet article ne servent, encore une fois, que de base. Ceux-ci sont assez génériques pour pourvoir être utilisés dans tous les cas. D’autres points seront à mettre en œuvre pour terminer l’automatisation de la supervision.

Paramétrage d’Ansible

L’installation d’Ansible est parfaitement couverte par la documentation officielle, nous n’allons pas y revenir. Cependant, il est nécessaire d’expliquer quelques points afin de comprendre l’article.

Fichier d’inventaire

Ansible a besoin d’un fichier d’inventaire. Ce fichier liste les équipements et les paramètres de ces équipements. Les équipements sont ensuite regroupées dans des groupes. Voici un exemple de fichier d’inventaire :

[serveurs-prod] 
srv-prod-01
srv-prod-02
srv-prod-03

[serveurs-RetD]
srv-retd-01
srv-retd-02
srv-retd-03

[nouveaux]
srv-nouveau-01
srv-nouveau-02

Dans ce fichier, trois groupes ont été créés : serveurs-prod, serveurs-RetD et nouveaux. En-dessous de chaque groupe sont listés les serveurs. Un groupe spécifique nouveau est utilisé pour déclarer les nouveaux éléments afin de réaliser sur ces nouveaux éléments les déploiements nécessaires.

 Recette Ansible

Une recette Ansible est un fichier listant les tâches devant être réalisées sur un équipement. Un exemple permettra d’expliquer plus facilement :

---
- hosts: nouveaux
  remote_user: root
  tasks:
  - name: update Debian packages cache
    apt: update_cache=yes cache_valid_time=3600
  - name: PKG debian-keyring is at the latest version
    apt: pkg=debian-keyring state=latest

Dans l’exemple ci-dessus, nous allons :

  1. agir uniquement sur les membres du groupe « nouveaux »
  2. utiliser l’utilisateur « root » pour nous connecter en SSH
  3. réaliser deux tâches :
    1. mettre à jour le cache des paquets Debian si celui-ci n’a pas été mis à jour depuis 3600 secondes
    2. installer le paquet debian-keyring si celui-ci n’est pas installé et s’il est installé, vérifier qu’il est dans la dernière version, sinon installer cette dernière version.

Pour faire simple : les tâches sont déclarées les unes après les autres et disposent d’un nom et d’une ligne d’action. Bien entendu, Ansible est plus puissant que cela mais il n’est pas nécessaire de lister toutes ses possibilités pour comprendre la suite.

Réalisation des actions

Pour réaliser les actions, on lance la commande ansible-playbook en passant en paramètre le fichier d’inventaire et la recette Ansible :

ansible-playbook -i hosts fichier-recette.yml

 

Déploiement automatique des « agents de supervision »

Lors de l’ajout d’un équipement informatique au système d’information, il est nécessaire de l’intégrer au système de supervision. Pour cela, il est nécessaire de déployer sur ce nouvel équipement des « agents de supervision ». Le terme « agent de supervision doit être pris au sens large. Dans le cas d’exemple, les éléments seront automatiquement réalisés sur le nouvel équipement :

  1. installation de l’agent Net-SNMP
  2. configuration de Net-SNMP
  3. installation des plugins de supervision
  4. création d’un utilisateur dédié à la supervision
  5. association de la clé SSH de l’utilisateur centreon-engine du serveur Centreon à l’utilisateur dédié à la supervision

D’autres tâches peuvent être réalisées et les tâches ci-dessous ne sont que des exemples. Si vous préférez utiliser « NRPE » ou « NSCA » en lieu et place de SSH, il vous suffit de changer les tâches. Voici un fichier de « recette Ansible » convenant à cet exemple :

---
- hosts: nouveaux
  remote_user: root
  tasks:
  - name: PKG snmpd is at the latest version
    apt: pkg=snmpd state=latest
  - name: snmpd.conf file configuration
    copy: content='rocommunity public <ipsuperviseur>' dest=/etc/snmp/snmpd.conf
  - name: restart snmpd
    service: name=snmpd state=restarted
  - name: PKG nagios-plugins-standard is at the latest version
    apt: pkg=nagios-plugins-standard state=latest
  - name: User superviseur created
    user: name=superviseur shell=/bin/bash
  - name: Superviseur key deployed
    authorized_key: user=superviseur key="{{ lookup('file', '~/GIT/ansible/ssh-key-superviseur.pub') }}"

Les noms des tâches sont faites pour être naturellement comprises. Quelques points à noter :

  • <ipsuperviseur> doit être remplacé par l’adresse IP du serveur de supervision.
  • ce fichier de configuration SNMP est simple, pour ne pas dire simpliste. Il mériterait un travail plus poussé, qui n’est pas le sujet de cet article.
  • la clé SSH doit se trouver au chemin indiqué. D’autres techniques fournies par Ansible permettent d’utiliser un chemin relatif (voir la notion de « rôle » dans Ansible).

Ajouter automatiquement un hôte à Centreon

Pour ajouter automatiquement l’hôte à Centreon, il suffit d’utiliser cette tâche :

- name: centreon add host
   shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a add -v "{{ inventory_hostname }};{{ inventory_hostname }};{{ ansible_default_ipv4.address }};generic-host;central;ALL_HOST"
   delegate_to: superviseur.company.lan

L’hôte est ajouté à Centreon en faisant appel à Centreon CLAPI. La commande n’est pas exécutée sur l’équipement correspondant mais est déléguée (delegate_to) à notre serveur de supervision.

Attention :

  1. ici, le nom d’hôte et l’alias sont identiques.
  2. ici, l’adresse IPv4 par défaut est utilisée. Si vous souhaitez une autre adresse, il faudra passer par d’autres variables d’inventaire d’Ansible.
  3. ici, l’hôte est automatiquement associé au modèle d’hôte generic-host, au poller central et au groupe d’hôtes ALL_HOST.
  4. il est indispensable que l’hôte superviseur.company.lan soit déclaré dans le fichier d’inventaire.

Associer cet hôte à un groupe d’hôtes

Il est possible d’associer un hôte à un groupe d’hôte en fonction de son OS. Pour cela, il est nécessaire de détecter l’OS et la version d’OS à l’aide de la directive when et des variables d’inventaire puis de lancer la commande Centreon CLAPI correspondante.

 - name: centreon add to group Debian Wheezy
   shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HG -a addmember -v "Debian-Wheezy;{{ inventory_hostname }}"
   when: ansible_os_family == "Debian" and ansible_distribution_major_version == "7"
   delegate_to: superviseur.company.lan
 - name: centreon add to group Debian Jessie
   shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HG -a addmember -v "Debian-Jessie;{{ inventory_hostname }}"
   when: ansible_os_family == "Debian" and ansible_distribution_major_version == "8"
   delegate_to: superviseur.company.lan

Attention : les groupes d’hôtes doivent préalablement exister. De nouveau, l’appel à Centreon CLAPI doit être délégué à l’hôte sur lequel se trouve CLAPI.

Associer un modèle de supervision à cet hôte en détectant l’OS

De la même manière, on peut associer un modèle de supervision automatiquement en détectant le système d’exploitation :

 - name: centreon add to group Debian Jessie
   shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a addtemplate -v "{{ inventory_hostname }};Linux_template"
   when: ansible_os_family == "Debian"
   delegate_to: superviseur.company.lan

Déclarer un modèle de supervision en détectant un paquet installé

Enfin, il est possible d’associer un modèle de supervision en détectant si un paquet est installé :

 - name: Verification presence mysql-server
   shell: dpkg-query -s mysql-server 2>&1 | grep "install ok installed" | wc -l
   register: debian_check
 - name: centreon add host template mysql-server
   shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a addtemplate -v "{{ inventory_hostname }};MySQL_template"
   when: debian_check.stdout == "1"
   delegate_to: superviseur.company.lan

Application du modèle de supervision

Petite subtilité de Centreon CLAPI, les modèles de service associés à un modèle d’hôte ne sont pas automatiquement déployés lorsqu’un hôte est associé à ce modèle d’hôte. Une action complémentaire est nécessaire. Dans le cas présenté, il suffit d’ajouter une tâche :

   - name: Deploy templates
     shell: /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p admin -o HOST -a applytpl -v "{{ inventory_hostname }}"
     when: debian_check.stdout == "1"
     delegate_to: centreon

Démonstration

Rien de mieux qu’une vidéo pour démontrer l’intérêt de coupler un outil de supervision à un outil de gestion de configuration :

Reste à faire

Un grand nombre de tâche reste encore à réaliser :

  • Demander à Centreon, par l’intermédiaire de CLAPI de générer la configuration et de redémarrer le moteur de supervision.
  • Automatiser un peu plus son système d’informations.
  • Détecter les VHosts Apache grâce à Ansible et les ajouter à la supervision.
  • Automatiser encore un peu plus son système d’informations.
  • Déclarer dans MySQL un utilisateur dédié à la supervision du serveur de base de données.
  • Automatiser toujours peu plus son système d’informations.
  • Automatiser encore et toujours son système d’informations.

Conclusion

Automatiser son système d’information est l’une des tâches les plus importantes de l’administrateur système. Aujourd’hui, les outils de supervision comme les outils de gestion de configuration sont suffisamment matures pour automatiser efficacement la supervision. En passant un peu de temps sur les deux types  d’outil, il est possible de faire en sorte qu’un serveur ajouté au système d’informations soit automatiquement ajouté à l’outil de supervision, sans que l’administrateur n’ait besoin de réaliser une tâche spécifique. Dès lors, il n’y aura plus d’oubli et l’administrateur système pourra se concentrer sur d’autres tâches.

Pour arriver à ce résultat, l’administrateur système doit maîtriser son outil de gestion de configuration comme son outil de supervision. La configuration de modèle de supervision comme les recettes de déploiement et de configuration doivent être poussées le plus loin possible. Cette tâche est nécessaire et un des facteurs clés de réussite du projet d’intégration. Les outils, si leur périmètre fonctionnel est bien évidemment à prendre en compte, ne sont qu’un point d’appui : la méthode de travail est l’élément le plus important.

Comme toujours, une amélioration continue doit être mise en place, pour améliorer l’utilisation des outils et faire évoluer la gestion de configuration.

Read More

Automatisation de la supervision : exemple avec Centreon et Ansible (1)

Posted by on 18 Mai 2015 in Astuces, Centreon, Supervision | 0 comments

L’automatisation de l’intégralité de la chaîne de production informatique est l’une des techniques permettant aux administrateurs systèmes d’être plus efficaces, d’augmenter la qualité, la performance et la résilience du système d’information. La supervision fait partie de la chaîne de production information et, à ce titre, doit être elle aussi automatisée au maximum. Une des solutions possibles est d’automatiser la mise en supervision des équipements informatiques, préalablement déclarés dans un outil d’inventaire. Une autre solution est de se servir de l’outil de gestion de configuration pour installer automatiquement les agents de supervision puis de déclarer les nouveaux éléments dans l’outil de supervision. C’est ce que nous allons voir dans cet article.

Enjeux et avantages

Les avantages de passer par un outil de gestion de configuration sont multiples :

  1. déploiement automatisé des agents de supervision : grâce à l’outil de gestion de configuration, il est possible d’automatiser l’installation des agents de supervision. Dès le déploiement de la machine virtuelle ou du serveur physique, les outils considérés comme standards sont installés par défaut. Les agents de supervision peuvent être installés et configurés.
  2. ajout de tout nouvel équipement dans l’outil de supervision dès le déploiement. En effet, en mettant en place la connexion entre l’outil de gestion de configuration et la solution de supervision, dès qu’un équipement est ajouté dans le système d’information, il est automatiquement ajouté dans l’outil de supervision. Cela évite l’oubli accidentel.
  3. ajout de tous les modèles de supervision. Grâce à l’outil de déploiement de configuration, il est possible de savoir quels sont les éléments applicatifs installés sur les serveurs. Dès lors, les modèles de supervision peuvent être automatiquement appliqués à cet équipement. Il n’est plus nécessaire de faire remplir une fiche aux utilisateurs du SI pour pouvoir ajouter l’équipement correctement à la supervision.
  4. application automatique des « bonnes pratiques » définies en interne. Là encore, en automatisant, il est plus facile de s’assurer que les bonnes pratiques sont bien suivies. Il suffit de vérifier que les bonnes pratiques sont correctement définies dans la configuration de l’outil de gestion de configuration.
  5. mise à jour de la supervision selon la vie des des équipements. Lors de l’ajout d’un nouveau composant logiciel sur l’équipement en passant par l’outil de gestion de configuration, ce nouveau composant sera automatiquement supervisé, quand bien même cet ajout est fait plusieurs mois après la création du serveur. Cela impose bien entendu de passer par la gestion de configuration pour ajouter le composant logiciel mais c’est le but de la gestion de configuration.

Des outils pour illustrer

Ce sujet pourrait être totalement théorique mais il ne serait alors pas très amusant. Nous allons donc illustrer les différents points avec deux outils spécifiques : Ansible et Centreon. Pourquoi ces outils en particulier? Tout simplement parce qu’ils sont les outils les mieux maîtrisés par l’auteur de l’article : tout autre outil de supervision et tout autre outil de déploiement ou de gestion de configuration peuvent être utilisés. Par exemple, il existe plusieurs modules Zabbix pour Ansible. Rudder peut aussi être connecté à Centreon comme l’explique Nicolas Charles de Normation. Enfin, Luc « Framasky » va connecter Shinken à Salt :

Bien entendu, des adaptations du propos de cet article peuvent être nécessaire pour les différents outils mais elles devraient se faire à la marge. Les outils choisis ici ont aussi l’avantage de respecter une bonne partie des pré-requis nécessaires.

Pré-requis

La tâche permettant de relier son outil de supervision à son outil de gestion de configuration peut être très complexe. Elle peut être facilitée si des pré-requis sont en places. Voici une liste de pré-requis qui permettent de se faciliter le travail et de s’assurer de la maintenance.

Maîtrise de son outil de supervision.

Ce pré-requis est un pré-requis humain : il est nécessaire de connaître relativement bien les capacités de son outil de supervision afin de se simplifier la tâche. Dans le cas contraire, il sera très ardu d’automatiser. En effet, pour automatiser une série de tâches, il est nécessaire de bien maîtriser chaque tâche mais aussi l’enchaînement de celles-ci, les cas d’erreur, les exceptions, … Un point important : il est nécessaire de bien maîtriser aussi l’organisation des modèles de supervision, comme ce sera indiqué un peu plus loin.

Maîtrise de son outil de gestion de configuration.

Là encore, il est nécessaire de bien maîtriser son outil de gestion de configuration sous peine de passer beaucoup de temps à tester, à partir dans une mauvaise direction, à chercher la fonctionnalité nécessaire au besoin. Si l’outil de gestion de configuration fournit déjà des ponts avec votre outil de supervision, c’est un grand pas en avant. Dans le cas contraire, il va vous falloir maîtriser l’appel à des commandes externes ou l’appel au langage de template de l’outil de gestion de configuration.

Gestion de modèles de supervision

Si votre outil de supervision vous permet de déclarer des « modèles de supervision », votre tâche sera grandement facilitée. Un modèle de supervision vous permet de reprendre une configuration pré-établie et commune à tous les éléments d’un même type. Exemple : « la supervision du port 12000 » est un modèle permettant de s’assurer que le port 12000 est ouvert et qu’il répond suffisamment rapidement.

Gestion de modèles de supervision de haut niveau.

Le modèle précédent est relativement basique, simpliste. Si votre outil de supervision vous permet de disposer de modèles de plus haut niveau, vous permettant de déclarer simplement un modèle regroupant plusieurs points de contrôle, vous vous simplifierez encore plus la tâche. Exemple : « la supervision MySQL est un modèle de supervision de haut niveau permettant de superviser un serveur MySQL, regroupant une dizaine d’indicateurs de supervision spécialisés ».

Modèles de supervision préalablement configurés

Le but n’est pas que l’outil de gestion de configuration déclare lui-même les modèles de supervision et chaque point de supervision. Cette tâche serait trop complexe à lui déléguer et, surtout, ce n’est pas son rôle. L’outil de supervision est le plus à même de gérer cela : il doit disposer de toutes les méthodes et techniques nécessaires.

C’est à vous de déclarer des modèles pertinents, correspondant à une logique d’implémentation la plus proche possible de votre système d’information. Ce travail doit être préalable, sans quoi il sera impossible de l’automatiser avec votre outil de gestion de configuration.

API disponible dans l’outil de supervision

Pour ajouter simplement des éléments à votre outil de supervision, il est plus efficace de passer par une API fournie par votre outil de supervision plutôt que d’insérer, par exemple, directement des éléments dans une base de données. En effet, il vous serait alors nécessaire de faire du reverse engineering sur la base de données car, en général, la documentation de cette base de données n’est pas fournie. De plus, polluer une base de données en ajoutant la moitié des données nécessaires au fonctionnement de l’outil de supervision peut aboutir à des incohérences très complexes à analyser. Les logiciels ne sont généralement pas développés avec la capacité de vous indiquer ce qui ne fonctionne pas lorsque vos données sont polluées. Il est alors courant d’obtenir des pages blanches, des doublons, voire des plantages complets ou une impossibilité de se connecter à l’outil. Ceci est très risqué. Il est préférable de passer par l’API de l’outil. Dans le cas de Centreon, CLAPI est l’outil qui permet de déclarer des éléments à superviser.

Configuration de l’outil de supervision par fichiers

Si vous ne disposez pas d’une API, il vous faudra des fichiers de configuration. Le mieux étant de disposer d’un outil vous permettant une grande flexibilité pour organiser vos fichiers de configuration (plusieurs répertoires, plusieurs fichiers) afin de vous simplifier la tâche et vous éviter de devoir écraser systématiquement l’intégralité de votre configuration de supervision. Dans le cas d’Ansible, Jinja2 est le langage qu’il faut faudra utiliser si vous disposez d’un outil de supervision travaillant avec des fichiers de configuration.

Flux de travail

Le flux de travail, dans le cas où l’on part de zéro, est le suivant :

  1. choisir un domaine de supervision (exemple : « MySQL », qui est la supervision de tous les indicateurs liés à MySQL).
  2. déclarer des modèles de supervision complets.
  3. faire le test de ces modèles sur un environnement restreint (deux ou trois serveurs MySQL), uniquement sur l’outil de supervision. L’idée est de valider que ces modèles fonctionnent parfaitement sur l’outil de supervision avant de passer au couplage avec l’outil de gestion de configuration.
  4. travailler au couplage avec l’outil de gestion de configuration.
  5. tester ce couplage sur un environnement restreint, sur un serveur de supervision de test.
  6. une fois la validation terminée, déployer tout l’environnement, sur le serveur de production.
  7. revenir à l’étape 1 avec un autre domaine de supervision.

Bien entendu, lorsque l’on part d’un outil de supervision existant, ce flux de travail est à adapter. Il est peut être inutile de revoir les modèles de supervision.

Dans le prochain article

Dans le prochain article, nous verrons des cas concrets de couplage entre Centreon et Ansible.

 

Read More