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

Posted by Cédric Temple 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 ' 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 :

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