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

Read More

Nouvelle donne pour la métrologie ?

Posted by on 6 Avr 2012 in Planet, Stratégies IT | 5 comments

J’avais rédigé l’année dernière un article sur les nouvelles approches apparaissant dans la gestion des logs. Je vais continuer dans cet article ce qui est en train de devenir une série sur les nouvelles approches de la supervision avec la métrologie.

Jusqu’à maintenant, un outil règne en maître quand il s’agit de stocker et grapher les données de performance issues de la collecte Nagios (et autres) : RRDTool. Certes, RRDTool est un excellent logiciel qui nous a rendu (et continue de nous rendre) de loyaux services. Pourtant, ceux qui l’utilisent au quotidien pourront peut-être souscrire avec moi aux quelques griefs qui vont suivre:

Read More

La supervision pilotée par le comportement

Posted by on 24 Mar 2011 in Planet, Stratégies IT | 11 comments

J’ai découvert avec cucumber-nagios bien plus qu’un simple plugin supplémentaire pour Nagios. Celui-ci prétend en effet nous amener vers le nirvana de ce que les anglophones appellent « Behaviour Driven Infrastructure » que nous pouvons traduire approximativement par Infrastructure piloté par le comportement. Que cache ce terme, en quoi peux-t’il s’appliquer au domaine de la supervision sont quelques unes des questions auxquelles nous allons tenter d’apporter sinon des réponses; au moins des éclaircissements.

La représentation traditionnelle d’un SI en supervision

Aujourd’hui, tous les systèmes de supervision représentent un système de supervision comme un ensemble de serveurs sur lesquels tournent des services. C’est une représentation technique des choses qui associe la notion de santé d’une système d’informations …. Beaucoup de clients aujourd’hui souhaitent vérifier le matériel, les processus,

Cette représentation traditionnelle d’un système d’informations, au moins dans le domaine de la supervision, semble de plus en plus poussée vers l’obsolescence dû à quelques évolutions majeures intervenues dans nos SI depuis 5 ans.

Quelques problèmes

  • La redondance et la haute disponibilité qui rendent la représentation traditionnelle plus lourde à modéliser.
  • La virtualisation massive des systèmes d’informations des entreprises, que ce soit avec Xen, VMware, KVM… amenant une distinction supplémentaire entre serveurs physiques et serveurs virtuels dépendant d’un serveur physique.
  • Le Cloud qui est en train de faire exploser la notion même de matériel puisque vous ne savez plus à un instant temps « T » quels sont les composants de votre infrastructure qui sont sollicités.

Du coup, les systèmes de supervision actuels souffrent de plus en plus pour représenter la complexité des interactions entre serveurs actifs, non actifs, physiques, virtuels… Les conséquences en exploitation sont nombreuses avec des difficultés croissantes à pouvoir décider ce qui ressort d’un problème, d’un incident, ce qui devrait être notifié, escaladé. Certains nous promettent le nirvana (encore 😉 en portant la notion de corrélation à un niveau jamais atteint et difficilement exploitable. Ils nous fournissent des moteurs de corrélation de plus en plus complexe à paramétrer et configurer. Impasse ?

La représentation comportementale de votre SI

Les auteurs de Cucumber qui est à la base du plugin préfère ouvrir une autre voie en partant du principe qu’un système doit se comporter d’une certaine façon pour rendre le service attendu.

Quelques bénéfices

  • Vous n’avez plus à modifier les paramètres de chaque sonde à chaque modification de votre infra. Le comportement observé devant en toute logique resté le même.
  • Vous êtes directement orienté vers l’impact métier du problème.
  • Vous n’êtes pas alerté au moindre problème, seulement pour ceux impactant l’activité ou le service rendu.
  • Vous prenez en compte l’expérience utilisateur. C’est bien là le principal non ?

Les outils pour le faire

La trousse à outils pour arriver à ce type de supervision est train de se mettre en place au niveau du monde de la supervision Open Source et nous vous avons déjà présenté ici Watir et Cucumber, pierres angulaires de ce type de supervision à venir… ou non

Alors à vous de me dire si ces idées sont intéressantes et/ou se contentent de suivre une nouvelle mode comme nous en connaissons régulièrement. À vos commentaires 🙂

Read More

Supervision 2010 : Les forces en présence

Posted by on 13 Jan 2010 in Planet, Stratégies IT | 3 comments

Il m’a paru intéressant avec l’année 2009 que nous venons de vivre en supervision Open Source de faire le point sur les forces en présences en début de cette année 2010.

Read More

Uptime : Mesure universelle ?

Posted by on 17 Sep 2009 in Planet, Stratégies IT | 0 comments

Il est admis que la mesure de base qui compte en supervision est le Uptime (temps de disponibilité d’un service et Nagios est prévu pour ce genre de réponse. Mais est-il intéressant, voir utile de rapporter à votre direction informatique sur ce type d’indicateur ? La réponse est clairement non.

Read More