Automatisation de la supervision : exemple avec Centreon et Ansible (2)
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 :
- agir uniquement sur les membres du groupe « nouveaux »
- utiliser l’utilisateur « root » pour nous connecter en SSH
- réaliser deux tâches :
- mettre à jour le cache des paquets Debian si celui-ci n’a pas été mis à jour depuis 3600 secondes
- 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 :
- installation de l’agent Net-SNMP
- configuration de Net-SNMP
- installation des plugins de supervision
- création d’un utilisateur dédié à la supervision
- 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 :
- ici, le nom d’hôte et l’alias sont identiques.
- 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.
- 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.
- 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 MoreAutomatisation de la supervision : exemple avec Centreon et Ansible (1)
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 :
- 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.
- 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.
- 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.
- 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.
- 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 :
Bon, #Shinken, c’est un poil rugueux au départ, mais je commence à m’y faire. Plus qu’à écrire les formules #salt 🙂
— Luc (@framasky) 15 Mai 2015
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 :
- choisir un domaine de supervision (exemple : « MySQL », qui est la supervision de tous les indicateurs liés à MySQL).
- déclarer des modèles de supervision complets.
- 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.
- travailler au couplage avec l’outil de gestion de configuration.
- tester ce couplage sur un environnement restreint, sur un serveur de supervision de test.
- une fois la validation terminée, déployer tout l’environnement, sur le serveur de production.
- 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
Comment faire suivre les messages Nagios vers logstash
Tout ceux qui ont utilisé un Nagios like un jour se sont retrouvés confrontés à ce problème.
Les logs de Nagios ne sont pas vraiment sympas à lire pour un humain et il est très difficile d’en sortir des statistiques sauf à écrire soi-même le « parser » qui va bien.
Alors pourquoi ne pas utiliser un logiciel qui en a plein justement des « parsers », à savoir Logstash ? Voici une approche possible parmi d’autres, enfin j’imagine. Ce sera aussi l’occasion de découvrir par l’exemple la nouvelle version de Kibana, quatrième du nom.
Read MoreUn cocktail de rentrée pour bien superviser votre site web
Après la gueule de bois des vacances, je vous propose de reprendre en douceur avec une recette de cocktail dont vous me direz des nouvelles ! 😉
Interne ou externe, telle est la question ?
Aujourd’hui, bon nombre d’entreprises confient l’hébergement de leurs sites web à des professionnels de la toile et de plus en plus externalisent certaines de leurs applications dans le cloud. L’avantage est que l’entreprise ne porte plus la responsabilité de l’interruption de service et le cloud peut avoir un attrait financier. D’un autre côté, elle perd en maîtrise de la surveillance, mesure de performance de ses applications externalisées. Le « hic » à tout ça, c’est que les entreprises sont obligés de faire confiance aux rapports fournis par leurs fournisseurs de service. Est-ce bien objectif ?
Des moyens pour les challengers existe avec de la supervision provenant de son propre S.I (check http via proxy, du robot scénarisé avec cucumber, watir, sélénium, …) mais ceci n’est pas ce qu’il y a de plus fiable. Ce contrôle n’est réalisé que d’un seul point et est biaisé par rapport à l’expérience de vos utilisateurs.
Et oui, il faut passer par le proxy, la connexion internet de l’entreprise qui peuvent eux-mêmes avoir une interruption de service et ainsi perturber les SLA. De plus, ceci ne correspond pas toujours au chemin réel pris par vos visiteurs ou utilisateurs.
Le moyen le plus sûr est l’abonnement à un service de supervision « Cloud »; gratuit éventuellement si les besoins sont modestes. Ce service va jouer un rôle d’arbitre entre le ressenti de l’entreprise et les données fournies par un professionnel de la toile. Ceci vous permettra de le challenger afin de contrôler si les engagements sont bien tenus.
Mais là, autre « hic », comme tous services cloud, une console de Supervision en ligne vous apportera l’inconvénient de ne toujours pas avoir une maîtrise totale sur les données produites par celle-ci. Vous bénéficiez de rapports « standardisés » fournit par ce service et qui ne correspondent pas forcément à votre besoin ou même votre métier.
Vous allez me dire : « Je veux avoir la maîtrise de mes données afin de pouvoir les traiter, corréler et représenter avec les solutions interne de mon entreprise !!! »
Et je vous réponds, maintenant c’est possible !
Comme certains d’entre vous ont pu le voir passer sur la toile ou les réseaux sociaux, l’équipe de Check My Website a publié il y a quelques temps un plugin de supervision pour plateforme « Nagios-like » (Nagios, Centreon, Icinga, Shinken), disponible sur github en libre téléchargement.
Check my We’bsite est un service en ligne de supervision de sites, applications web se trouvant dans le cloud. Je vous laisse faire connaissance avec eux sur cet article
La console étant à l’heure actuelle en bêta ouverte au public avant la commercialisation du service, j’ai réalisé un test d’intégration d’une sonde « Check my Website » sur ma plateforme Nagios/Centreon.
S’abonner à Check my Website
Premièrement, il faut que créer un compte sur la console CheckMyWebsite.
Après, il vous suffit en 2/3 clics d’ajouter l’URL à superviser.
Une fois que la supervision de votre site est effective, direction votre plateforme de supervision « Nagios-like »
Installation & configuration de votre Supervision interne
Une fois le plugin « Check my Website » installé sur votre plateforme, vous n’avez plus qu’à configurer une commande Nagios qui appelle votre plugin et de mettre en place votre sonde.
Vous avez maintenant vos données d’incidents et de performance qui remontent dans votre console interne. Le plugin remontent comme données de performance :
- Temps de réponse des différentes « locations » d’où est interrogé le site Web
- Temps de réponse moyen du site web
- Temps de chargement de la page web (Mesure YSlow)
- Notation YSlow
La cerise sur le gâteau
On pourrait se contenter déjà de ce qui a été fait, mais j’ai été poussé le vice plus loin encore. Utilisant CANOPSIS comme solution de dashboard, je me suis dit, « Pourquoi pas me faire un tableau de bord représentant l’activité de mon site sous surveillance ? »
Voici un résultat possible que j’ai produit avec les données de ma sonde Check my Website
Alors convaincu ?
Read MoreInstaller shinken ? c’est facile !
Shinken commence à bien faire parler de lui. Seul problème, l’installation est relativement ardue pour les « non initiés ». C’est à partir de ce constat que les équipes du projet shinken ont décidé de simplifier autant que possible cette étape. Il existe dans les dépôts (et ce sera officiel pour la version 1) un script prenant en charge tous les aspects de l’installation de shinken (voir même plus).
Read Moremod_gearman : Nagios distribué 2.0
Jusqu’à présent, pour gérer Nagios en mode distribué, c’est à dire avec un serveur central et plusieurs pollers (satellites) qui sont chargés de l’exécution des contrôles, vous aviez le choix entre le setup « officiel » de la documentation, vieux et au nombreux goulets d’étranglements ou Centreon et sa capacité à marquer certains hôtes, services comme devant être vérifié par tel ou tel poller. La solution avec Centreon étant quand même beaucoup plus conviviale. Citons encore Merlin de chez OP5 mais le projet ne semble pas très utilisé dans le monde francophone et ne présente pas de réelles nouveautés par rapport à un setup distribué Centreon.
Read MoreLicence
Sauf mention spéciale, le contenu de ce site est distribué sous licence Creative Commons version BY 3.0.