Un bon outil évolue en fonction de ses retours utilisateurs. Certaines fonctionnalités demandées sont généralement très structurantes pour l’outil : nécessité de refaire une partie du code pour augmenter les performances, revoir totalement l’architecture, … Les développeurs adorent travailler sur ces sujets. C’est très motivant car humainement valorisant. Parfois, ils oublient de travailler sur les fondamentaux : ces petites améliorations qui sont bien pratiques et qui facilitent la vie des utilisateurs. Ho, ce n’est pas grand chose, des « petits riens » comme on dit… mais qui apportent tellement dans l’utilisation journalière. Centreon n’est pas de ces outils. Voyons quelles sont les nouvelles « petites » fonctionnalités de Centreon 2.3.x qui apportent finalement beaucoup.

Centreon est une interface web de supervision. Une partie de l’interface web est dédiée à la supervision : voir les status des équipements supervisés, diagnostiquer plus finement un problème en analysant les graphiques, disposer d’un reporting basique de la supervision, … Une autre partie de l’interface web de Centreon est dédiée à la saisie des éléments à superviser : ajouter un équipement à superviser, déclarer un processus système à superviser, mettre en place la supervision du CPU ou de la mémoire d’un équipement, … Cette saisie se fait au travers de formulaire: un formulaire permet de saisir tous les champs nécessaires à Centreon pour superviser efficacement l’élément. Les fonctionnalités du moteur de supervision étant nombreuses (principes d’ordonnancement, de notification, groupes, contacts, …) les formulaires sont conséquents. Ils reposent sur plusieurs onglets avec de nombreux champs à saisir. La très large majorité des utilisateurs de Centreon utilise principalement 2 onglets sur les 4 disponibles. Même si les modèles/templates de supervision permettent de simplifier et d’accélérer la saisie des champs des onglets, on est très loin de l’automatisation. Par exemple, comment saisir rapidement 300 hôtes? En utilisant l’interface web, c’est très fastidieux. Surtout, cette étape est source de très nombreuses erreurs.

Heureusement, Centreon CLAPI (« Centreon Command Line API » ou « CLAPI » pour les intimes) permet d’automatiser la saisie des éléments grâce… à la ligne de commande. La bonne vieille ligne de commande qui gagnera toujours lors de la saisie de nombreuses informations redondantes. Nous allons voir dans cet article quelques fonctionnalités bien pratiques de CLAPI.

Installation sur Centreon Enterprise Server

Je pars du principe que vous avez installé Centreon Enterprise Server (« CES« ). Si ce n’est pas le cas, télécharger CES sur le site officiel de Centreon et installer la. CES, pour rappel, est une distribution Linux dédiée à Centreon : elle permet d’installer rapidement et simplement Centreon et tous les logiciels associés. Si vous avez installé CES, alors… CLAPI est déjà installé. C’est magique non? Si tel n’était pas le cas:root@ces # rpm -qa centreon-clapi
root@ces # yum update
root@ces # yum install centreon-clapi

Vérifications de base

Quelques vérifications pour s’assurer que tout fonctionne:

root@ces # ls -l /usr/share/centreon/www/modules/centreon-clapi/core/centreon
-rwxr-xr-x 1 root root 3971 jui  8 14:33 /usr/share/centreon/www/modules/centreon-clapi/core/centreon
root@ces # /usr/share/centreon/www/modules/centreon-clapi/core/centreon -u admin -p centreon -a POLLERLIST
1       Central
L’interpréteur de commande de CLAPI est le fichier « /usr/share/centreon/www/modules/centreon-clapi/core/centreon ». Celui-ci doit être exécutable pour pouvoir envoyer les commandes à Centreon. La seconde commande a permis de vérifier qu’il y avait bien au moins un poller.

Description du cas « théorique« 

Prenons un cas théorique pour expliciter l’utilisation de CLAPI. Ce cas est en réalité très pratique car c’est le cas que l’on retrouve dans de nombreux projets de supervision. Lorsqu’un projet de supervision est de taille importante, que le nombre de ressources à superviser dépasse 100, il est nécessaire d’industrialiser la configuration de la supervision. Pour cela, on réalise les actions suivantes:

1. identification des équipements « types » : les équipements qui sont présents de nombreuses fois (exemple : « serveur Windows », « serveur Linux », « switch Cisco », …)
2. création des modèles/templates pour superviser parfaitement ces équipements
3. test sur un environnement restreint (3 à 4 équipements de chaque type)
4. déploiement.

Les 3 premières étapes doivent être réalisées dans l’interface de supervision. La dernière peut être faite en ligne de commande, grâce à CLAPI. Donc, lorsqu’on utilise CLAPI, les modèles sont déjà définis et « parfaits » : il n’est plus nécessaire de revenir dessus, de les corriger. Nous allons voir maintenant comment bien se servir de CLAPI.

Utilisation de CLAPI pour le déploiement

Tout d’abord, il faut se créer un fichier sous LibreOffice Calc. Ce fichier va contenir tous les équipements à déclarer. Ensuite, un export CSV sera réalisé grâce à LibreOffice pour pouvoir le passer à un script. Ce script aura pour but de lire toutes les lignes du fichier CSV et de réaliser les appels à CLAPI pour ajouter les équipements dans la base Centreon.

Exemple de fichier LibreOffice:

L’algorithmie du script est donc:

•  pour chaque ligne CSV (sauf la première, correspondant généralement au titre)
• Découper la ligne selon le caractère de séparation (le caractère ‘;’ dans l’exemple ci-dessus)
• le nom de l’hôte est la première colonne
• l’adresse de l’hôte est la deuxième colonne
• le poller est dans la troisième colonne
• les hostgroups sont tous dans la quatrième colonne
• les templates d’hôte sont tous dans la cinquième colonne
• ajouter l’hôte grâce à la commande CLAPI
• Lister tous les pollers
• Pour chaque poller
• Lancer la génération des fichiers de configuration
• Lancer le test de vérification des fichiers de configuration
• Redémarrer le poller

C’est donc très simple et très rapide à développer.

Les commandes CLAPI

Les commandes CLAPI permettant de lancer les actions ci-dessus sont notées dans la documentation officielle de Centreon CLAPI. Je les résume ici pour faciliter la lecture de l’article.

Globalement, pour la suite de l’article :

1. l’utilisateur s’est placé dans le répertoire « /usr/share/centreon/www/modules/centreon-clapi/core »
2. le compte utilisateur « admin » (paramètre de l’option -u) est un compte administrateur de Centreon et il a pour mot de passe (paramètre de l’option -p) « centreon »
3. une action est faite après l’option « -a »
4. les arguments passés à l’action sont fournis par l’option « -v »
5. une action est faite sur le type d’objet passé en argument à l’option « -o »

Traitement des pollers

Lister les pollers avec leur identifiant :

root@ces # ./centreon -u admin -p centreon -a POLLERLIST
1       Central

Générer la configuration d’un poller, en passant l’identifiant du poller (1 pour le poller Central) :

root@ces # ./centreon -u admin -p centreon -a POLLERGENERATE -v 1
Configuration files generated for poller 1
Return code end : 0


Tester la configuration d’un poller, en passant l’identifiant du poller :

root@ces # ./centreon -u admin -p centreon -a POLLERTEST -v 1
OK: Nagios Poller 1 can restart without problem...
Return code end : 0


Redémarrer un poller, en passant l’identifiant du poller :

root@ces # ./centreon -u admin -p centreon -a POLLERRESTART -v 1
Starting nagios: done.Return code end : 0


Ajouter un hôte

root@ces # ./centreon -u admin -p centreon -o HOST -a ADD -v "Linux1;Linux1;192.168.0.1;Linux,Apache;central;Linux" Les paramètres sont:

• le nom de l’hôte
• l’alias de l’hôte (remarque : je définis l’alias de l’hôte comme identique à son nom pour éviter d’alourdir le propos. Dans les faits, il est préférable de mettre un alias différent et significatif)
• son adresse IP
• la liste des modèles d’hôtes dont il hérite. Les membres de cette liste sont séparés par des virgules.
• le nom du poller sur lequel il doit être attaché (le nom du poller, non son identifiant)
• la liste des groupes d’hôtes dont il fera parti. Les membres de cette liste sont séparés par des virgules.

Conclusion

Centreon CLAPI permet d’accélérer grandement le déploiement. Grâce à une bonne méthode d’implémentation des modèles d’hôtes, un fichier LibreOffice Calc bien écrit et un peu de scripting, on peut accélérer grandement l’étape de déploiement. Je vous invite à voir toutes les autres commandes dans documentation officielle de Centreon CLAPI.

Dans le cas d’erreurs systèmes ou de configuration, les serveurs Linux/Unix écrivent des messages dans des « logs ». Ce sont des fichiers textes contenant la date de l’erreur, sa criticité, le programme l’ayant généré et le message lui-même. C’est le fameux système syslog, généralement remplacé par ses successeurs rsyslog ou syslog-ng. Étant donné que ce sont des fichiers textes, ils sont lisibles par tous les outils systèmes comme sed/grep/awk/less/tail… L’enchaînement des commandes permet de filtrer et de rechercher le message d’erreur à une date et une heure précise et contenant le mot clé recherché. Les applications installées sur le système génèrent elles-aussi des messages d’erreur. Une bonne application doit envoyer ses messages à syslog afin qu’il les stocke dans ses fichiers.

Cependant, pour faire ces recherches, un compte administrateur est nécessaire sur le système. Admettons qu’un responsable d’application ait besoin de rechercher des messages dans les journaux, doit-il disposer d’un compte administrateur sur le serveur? Dans les services informatiques de taille moyenne, ce n’est pas problématique : les personnes installant les applications et les administrateurs sont les mêmes. Dans les services informatiques de taille plus importante, le responsable d’application n’a pas forcément les connaissances système suffisantes. Il ne doit pas avoir un compte administrateur pour éviter toute erreur de manipulation. De plus, si le serveur est partagé et pour des raisons de sécurité, ce responsable d’application ne doit pas non plus accéder à toutes les logs. La problématique est qu’il doit être suffisamment autonome pour éviter de solliciter les administrateurs systèmes… sans avoir accès à toutes les logs ni toutes les commandes systèmes. Comment lui donner un accès aux logs? La commande sudo, si bien configurée, est une première réponse. Mais elle ne sera pas simple à configurer.

Une autre solution est de centraliser la collecte de toutes les logs et de les présenter dans une application dédiée. Le mieux est encore d’intégrer cette interface directement dans l’outil de supervision. C’est possible avec Centreon et son module Centreon-Syslog. Cet article détaille l’utilisation de Centreon-Syslog.

Description du module

Centreon-Syslog permet d’afficher dans l’interface Centreon les messages syslog stockés dans une base de données. Il suffit de configurer tous les équipements réseaux et les serveurs pour qu’ils transfèrent leurs logs au serveur Centreon. Ce dernier, avec le module installé et correctement paramétré, stockera tous les événements syslog dans sa base de données et permettra de les visualiser grâce à son interface.

Installation

L’installation du module est beaucoup plus simple si vous utilisez Centreon Enterprise Server (CES). La version « Standard » suffit pour disposer du module. Je vous invite à télécharger la dernière version de CES afin de profiter de tous les avantages de cette distribution Linux dédiée à la supervision Centreon. Une fois CES installée, la vie est beaucoup plus simple:

yum install centreon-syslog-server centreon-syslog-frontend

Ensuite, vous devez vous rendre dans l’interface Centreon, dans le menu « Administration –> Modules » et cliquer sur l’icône tout à droite du module Centreon-Syslog et ensuite valider l’installation.

Configuration basique

Dans ce premier article, nous allons voir une configuration basique. Nous allons juste faire en sorte que le serveur de supervision stocke ses logs dans la base de données créée par le module Centreon-Syslog. Avantage de Centre Enterprise Server : c’est déjà fait! RSyslog est déjà configuré pour stocker toutes ses logs dans la base de données.

Cependant, il est nécessaire de modifier le mot de passe permettant l’accès à la base de données dans l’interface du module. Pour ce faire, toujours dans le menu « Administration –> Modules » , il faut cliquer sur le lien « Configuration » en dessous du titre « Syslog ». Ce lien se trouve dans le menu gauche. Pour identifier plus facilement, je l’ai encadré de rouge dans la capture d’écran ci-dessous:

Menu de configuration pour Centreon Syslog

Ensuite, il est nécessaire de modifier le mot de passe. Par défaut, il est vide. Or un mot de passe a été généré pour l’utilisateur MySQL « centreon-syslog ». Pour le connaître, il suffit de regarder la dernière ligne du fichier /etc/rsyslog.conf:
[root@ces ~]# tail -n 1 /etc/rsyslog.conf
*.* >127.0.0.1,centreon_syslog,centreon_syslog,Btjh1203;sysMysql
Le mot de passe créé automatiquement par Centreon Syslog est en rouge. Il suffit de saisir le même mot de passe pour le champ « Password of Database user » et sauvegarder.

Utilisation de l’interface

Ci-dessous, une vidéo présentant rapidement l’utilisation de l’interface temps-réel de Centreon-Syslog.

Une deuxième vidéo présentant l’interface de recherche de Centreon-Syslog.

Interface vide?

Si jamais vous vous demandez pourquoi la partie « Search » est vide, c’est parce que vous êtes… impatient! En fait, une tâche cron est lancée toutes les nuits et archive les messages dans des tables spécifiques afin d’accélérer la recherche et le filtrage. Comme ce script n’a jamais été lancé, la page de recherche ne fonctionne pas. Bref, « ça ira mieux demain! ».

Suite de l’article précédent sur La découverte de Centreon-Syslog. Si vous redémarrez RSyslog, vous trouverez ces messages d’erreur dans /var/log/messages:

rsyslogd: WARNING: rsyslogd is running in compatibility mode. Automatically generated config directives may interfer with your rsyslog.conf settings. We suggest upgrading your config and adding -c3 as the first rsyslogd option.
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad immark
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: MarkMessagePeriod 1200
rsyslogd: Warning: backward compatibility layer added to following directive to rsyslog.conf: ModLoad imuxsock


Pour supprimer ces erreurs, il faut modifier le fichier /etc/sysconfig/rsyslog et remplacer la ligne suivante:

SYSGLOD_OPTIONS="-c3"

Par:

SYSLOGD_OPTIONS="-c3"

La correction est mise en évidence en rouge. Sauvegarder le fichier et redémarrer rsyslog:

/etc/init.d/rsyslog restart

Bien entendu, j’ai prévenu le responsable de Centreon-Syslog pour qu’il corrige ce problème.

On continue notre série d’articles sur Centreon-Syslog. Après avoir découvert Centreon-Syslog et comment supprimer les messages d’erreur générés au démarrage de RSyslog, nous allons voir comment faire parvenir les messages syslog d’un serveur Linux au serveur Centreon-Syslog. Cependant, pour éviter de saturer le réseau ou le serveur Centreon-Syslog, nous filtrerons les messages envoyés. Seuls ceux considérés comme intéressants seront envoyés. Les autres seront uniquement stockés en local. Dans cet article, je ne parle que de RSyslog et je pars du principe que Centreon-Syslog est installé et configuré par défaut sur un serveur Centreon Enterprise Server (CES) dont l’adresse IP est 192.168.0.11. Je nomme sender le serveur qui doit envoyer les messages syslog sur le serveur Centreon-Syslog.

Envoyer tous les messages à un serveur Centreon-Syslog

Pour envoyer tous les messages à un serveur Centreon-Syslog, il suffit d’ajouter la ligne suivante au fichier /etc/rsyslog.conf sur le sender:

*.* @@192.168.0.11:514

Dans la ligne ci-dessus:

• *.* signifie « tous les messages »
• @@192.168.0.11 : signifie « seront envoyés à l’adresse IP 192.168.0.11
• :514 signifie « sur le port 514″

Remarque: chaque serveur (le serveur Centreon-Syslog comme le serveur envoyant les messages) doivent avoir un nom d’hôte réel. Si ces deux serveurs possèdent le même nom d’hôte, vous ne pourrez savoir quel est le serveur qui a envoyé le message. Cette configuration se fait par la commande setup puis « Configuration du Réseau », « Edit DNS Configuration » et en modifiant la première ligne. Pensez à sauvegarder la configuration par la bouton « Save » et à modifier le fichier /etc/hosts.

Enfin, il faut redémarrer rsyslog sur le sender :

/etc/init.d/rsyslog restart

Aucune action n’est nécessaire sur le serveur Centreon-Syslog (c’est la magie CES ).

 Filtrer les messages : où réaliser cette action?

Dans la configuration ci-dessus, tous les messages sont envoyés. Cela n’est pas forcément négatif si:

• le réseau est capable d’encaisser cette charge supplémentaire
• le serveur Centreon-Syslog est correctement dimensionné pour intégrer tous ces messages dans la base de données
• l’espace disque du serveur hébergeant la base de données n’est pas limité

Dans tous les autres cas, il faut filtrer les messages pour éviter de les envoyer. Ce filtrage peut se faire à deux endroits. Le choix ne se fait pas à pile ou face mais selon la stratégie définie. Le filtrage peut être fait :

• soit sur le serveur Centreon-Syslog : tous les messages sont reçus, seuls les messages considérés comme importants sont stockés en base. Les autres sont stockés dans les fichiers textes uniquement. Cela évite de surcharger la base de données tout en centralisant le stockage des logs.
• soit sur chaque sender : chaque sender filtre les messages à envoyer pour éviter de saturer le réseau ou le serveur Centreon-Syslog.

Aucune des deux stratégies n’est la meilleure! Il faut choisir selon les critères suivants:

1. performances du réseau et du serveur Centreon-Syslog
2. besoin de centraliser ou non les messages syslog
3. capacité de stockage du serveur Centreon-Syslog

Filtrer les messages selon leur « facilité » et/ou leur criticité

Dès que le choix est fait, il faut maintenant définir quelles données vont être stockées. Pour cela, il est possible de filtrer par:

• « facilité » : cela correspond à l’origine du message, au type de programme l’ayant généré. Exemples : le kernel, les news, les mails, les crons, … Attention : ce n’est pas le nom du programme mais son type (« mail » est utilisé en lieu et place de postifx/exim/sendmail).
• « criticité » : la gravité du message.

Le filtre se fait de la façon suivante:

facilité.criticité

Le caractère « . » est utilisé pour séparer la facilité de la criticité. Il est possible d’utiliser le caractère « * » pour définir « tous ». Exemples:

• kern.* : tous les messages du kernel
• *.err : tous les messages de criticité « err » ou supérieure

Exemple de configuration: modifier le fichier /etc/rsyslog.conf en ajoutant les deux directives suivantes:

kern.* @@192.168.0.11:514
*.notice @@192.168.0.11:514


Penser à redémarrer rsyslog après cette modification!

J’ai décidé de faire une série d’articles sur les fonctions mal connues de Centreon. Le premier de cette série est les méta services de Centreon.

Définition d’un méta service Centreon

Un méta service Centreon agrège les données de performance de plusieurs services Centreon pour effectuer sur celles-ci des calculs mathématiques et fournir un nouvel objet (appelé méta service Centreon), équivalent à un service.

Cette définition n’étant pas simple à comprendre, nous allons l’illustrer par des cas d’utilisation. Les cas d’utilisation permettent de mieux exprimer la fonctionnalité apportée par les méta services.

Cas d’utilisation du méta service Centreon

1. Vous disposez d’une application 3-Tiers avec 2 serveurs frontaux Apache, 2 serveurs MySQL en maître-esclave et 5  serveurs d’application JBoss. Sur chaque serveur JBoss, vous supervisez le taux d’occupation du CPU. Avec Centreon, vous pouvez créer un méta service qui sera la moyenne des taux d’occupation du CPU des serveurs JBoss. Vous pouvez alors désactiver les notifications sur chaque service « CPU » des serveurs JBoss et ne l’activer que sur le méta-service.
2. Autre exemple, toujours sur le même contexte (Apache/JBoss/MySQL). Vous avez configuré un service sur chaque serveur JBoss qui mesure le nombre de connexions. Vous pouvez créer un méta service correspondant au nombre total de connexions : c’est la somme de toutes les connexions.
3. Vous disposez d’imprimantes sur lesquelles vous mesurez le nombre de pages imprimées. Grâce au méta service, vous pouvez connaître le nombre total de pages imprimées. Vous pourrez alors vérifier l’impact des recommandations faites aux utilisateurs de ces imprimantes et même communiquer avec eux sur ce graphique.

D’autres exemples, plus concis :

1. connaître la bande passante totale consommée lorsque vous disposez de plusieurs connexions internet
2. disposer du nombre total de connexions sur les 2 pare-feux en cluster
3. obtenir la consommation électrique totale de tous les serveurs
4. temps moyen de connexion sur plusieurs frontaux web

Fonctionnalités du méta-service

Le méta service se base sur des services existants. Il ne permet pas d’inventer des chiffres : des données doivent exister avant la création du méta service. Dans tous les cas ci-dessus, le méta service ne fait qu’effectuer des calculs sur des données pré-existantes. Les services doivent donc exister mais leurs données de performance doivent aussi être identiques. Par exemple, il n’est pas logique d’effectuer la moyenne d’un taux d’occupation du cpu et du taux d’occupation de la mémoire. Le type de donnée de performance doit être exactement le même quelques soient les services sur lesquels seront effectués le calcul.

En créant un méta service, vous choisissez les services sur lesquels seront effectués les calculs, la donnée de performance et la fonction (somme, moyenne, minimum et maximum) à appliquer sur les données de performance. De ce fait, vous choisissez l’expression de votre méta service. A vous de définir quelle expression vous souhaitez obtenir. Les exemples ci-dessus peuvent vous aider.

Un méta service se comporte comme un service. Il a donc:

1. un état : ok/warning/unknown/critical
2. une période de supervision, un intervalle de test et de retry, un nombre maximum de tentatives, …
3. des valeurs seuils : si le résultat du calcul dépasse la valeur seuil critical alors le méta service sera en état critical
4. des notifications : le(s) contact(s) ou le(s) groupe(s) de contact(s) à notifier, un intervalle de notification, une période de notification, …
5. un graphique permettant de tracer au cours du temps le résultat de la fonction de calcul sur les données de performance
6. un modèle de graphique

Configuration d’un méta service

La configuration d’un méta service impose les réflexions préalables suivantes :

1. quels sont les services sur lesquels effectués mon calcul?
2. quelle est la donnée de performance sur laquelle le calcul sera effectué? C’est ce que l’on appelle aussi « metric »
3. quelle est la formule de calcul?

Les réponses aux questions 2 et 3 sont très évidentes dès que l’on a identifié l’expression que l’on souhaite représentée à l’aide d’un méta service. La réponse à la question 1 est soit:

1. « tous les services identiques ». Dans ce cadre, la configuration du méta service se fera par un « matching SQL ». Il s’agit d’identifier tous les services portant le même nom. Exemple : tous les services portant le nom « pages_imprimees » pour traduire « la somme des pages imprimées de toutes les imprimantes »
2. « une liste identifiée de services ». C’est le cas du groupe de machines ayant un même rôle dans une grappe (exemple : les serveurs JBoss). Ce sera traduit par la sélection précise des services dans une liste lors de la configuration du méta service.

Configuration d’un méta service par matching SQL

Pour configurer un méta service, il faut se rendre dans le menu « Configuration –> Services –> Meta Services –> Add ». Le formulaire suivant apparaît:

Centreon méta service : configuration par SQL Matching

Les paramètres sont les suivants:

• Meta Service Name : le nom que vous choisissez pour le méta service
• Output format string (printf-style) : l’affichage du statut lorsque vous parcourez l’interface de supervision. C’est « l’output » d’un service. En général, la donnée est décrite et affichée à l’aide d’un appel équivalent à la commande « printf ». Par exemple: « Load15 is : %f ». Le « %f » représente la valeur calculée par l’opération mathématique et affichée sous forme d’un nombre flottant.
• Warning Level : la valeur seuil warning
• Critical Level : la valeur seuil critique
• Calculation Type : la fonction de calcul
• Selection Mode : le type de sélection des services. Dans notre cas, SQL Matching.
• SQL LIKE-clause expression : l’expression SQL permettant de filtrer les services. Dans notre cas, nous mettons le nom du service tel que nous l’avons défini dans notre configuration. Il est possible d’utiliser les filtres SQL (% par exemple)
• Metric : le nom de la donnée de performance (metric) sur laquelle le calcul sera effectué.

Les autres paramètres non présentés ici sont identiques à ceux présents pour un service. Je vous laisse les remplir puis sauvegarder.

Attention : le méta service ne sera créé que lorsque la configuration Nagios sera générée et Nagios redémarré.

Représentation dans l’interface de Supervision

Le résultat de la configuration apparaît dans le menu « Monitoring –> Services –> Meta-Services »:

Centreon méta service : résultat obtenu dans l'interface de supervision

Configuration d’un méta service par sélection unitaire dans une liste

La création d’un méta service par sélection unitaire des services dans une liste se fait en deux étapes:

1. création du méta service en sélectionnant le type « Service list » et sauvegarde
2. sélection unitaire des services

Pour simplifier la compréhension, une vidéo est meilleure qu’une série de screenshots:

Enfin, penser à générer la configuration Nagios et à redémarrer Nagios!

Introduction

Google Docs permet de partager des documents entre plusieurs personnes. Les avantages sont nombreux:

• pas de problème de synchronisation avec des répertoires partagés (du style « arf, il y a un conflit dans mes fichiers, lequel est la dernière version? » ou « t’as modifié quoi dans le document? il faut qu’on le resynchronise »)
• tout le monde voit les modifications se faire en « live »
• un historique permet de revenir en arrière (il manque un peu de souplesse cependant)
• accès aux fichiers depuis tout ordinateur ayant accès à Internet et un navigateur web
• …

Il y a aussi quelques désavantages:

• pas d’accès au document sans connexion internet
• lenteur relative inhérent aux « applications web » (lors de clicks dans l’interface, par comparaison à LibreOffice par exemple)
• sauvegarde des données (je n’ai pas encore trouvé de solution à ce sujet)
• sécurité des données (thème très à la mode dans le « cloud ») : ma solution est de faire attention aux données que j’y stocke .

La partie « Feuille de Calcul » de Google Docs est la plus intéressante pour moi. Voici une partie de mon utilisation de ces feuilles de calcul : l’import de données d’une feuille de calcul dans une autre feuille de calcul.

Import de données d’une feuille de calcul Google Docs depuis un autre document

L’import de données se fait à l’aide de la fonction « Importange » :

ImportRange(clé du document; Feuille!plage)

Ici, nous avons:

• clé du document : la valeur du paramètre « key » de l’URL. Cette clé identifie de manière unique un document.
• Feuille : le nom de la « feuille », ce qui correspond au nom de l’onglet dans lequel se trouve les données (« Feuille1″/ »Feuille2″ dans le bas du document)
• Plage : la plage de données de type. Par exemple : « A1:B5″ correspond à la plage qui va de la case A1 à la case B5.

Exemple d’utilisation :

=importrange("abcdjdgkdelkgeiudneleodjeqkjfie";"Feuille1!A1:AK1")

Dès lors, dans le document courant, toutes les données de cette plage A1->AK1 de la feuille « Feuille1″ seront récupérées et stockées dans la feuille courante.

Quelques informations à connaître :

1. pour identifier la clé du document, il est nécessaire de regarder l’URL du document. Je n’ai pas trouvé de fonction permettant de récupérer cette information. Un copier/coller est nécessaire.
2. une fois cette clé de document identifiée, elle peut être placée dans une autre cellule et la fonction « importrange » peut utiliser la valeur de cette cellule. Admettons que cette clé soit placée dans la cellule « A3″, la fonction devient : importrange(A3; »Feuille1!A1:AK1″)
3. la plage doit obligatoirement être placée entre double quotes (le caractère « ) sinon la fonction tente de récupérer une information indiquée dans cette plage du document en cours
4. un document est limité à 50 importrange
5. le rafraîchissement n’est pas réalisé dès qu’une information est modifié mais toutes les N minutes, N étant un paramètre que je ne connais pas. Je n’ai pas trouvé comment forcer ce rafraîchissement.
6. les styles (couleurs, polices et surtout « formatage conditionnel ») ne sont pas récupérés
7. l’accès en lecture du document source est obligatoire

Mon utilisation

J’utilise cette fonction pour agréger les données et limiter la visibilité sur ces données. J’ai le mode de fonctionnement suivant:

1. plusieurs documents différents, construits exactement pareil. Ces documents contiennent les informations précises d’un sujet très particulier. Ces documents constituent mon premier niveau de la pyramide. Les personnes qui remplissent ces documents ont chacune un accès à un document.
2. importrange de tous ces documents dans un second niveau : le document contient l’agrégation brute de toutes les données de tous ces documents. Des calculs sont faits sur ces données brutes. Une partie de ce document est dédié au reporting. Je suis seul à avoir accès en écriture à ce document.
3. un document fait office de 3e niveau de ma pyramide et est à destination du reporting final. Ce document se veut une présentation simple de toutes les données.

Grâce à cela, je simplifie l’utilisation (pas de nombreux onglets dans un seul document), je limite les accès (seules les informations courantes d’un sujet sont connues) et j’effectue un reporting global.

Exemple de reporting agrégé avec ImportRange

Deuxième vidéo sur les ACLs de Centreon : les contrôles d’accès aux ressources. Ces contrôles d’accès permettent de spécifier « qui voit quelles ressources supervisées ».

Tout d’abord, il est important de partir d’une excellente organisation. Pour cela, je vous recommande d’utiliser les groupes d’hôtes. Dans cette vidéo, j’ai paramétré les groupes d’hôtes suivants:

• Windows : groupe d’hôte Centreon contenant tous les hôtes Windows
• Linux : groupe d’hôte Centreon contenant tous les hôtes Linux
• Network : groupe d’hôte Centreon contenant tous les hôtes réseau (switch, routeurs, parefeu, …)

Les serveurs Windows doivent être visibles par les administrateurs Windows. Il en est de même pour les autres groupes : ils ne doivent être visibles que pour les administrateurs qui en ont la responsabilité. On en déduit la deuxième partie de la configuration : on crée des groupes de contacts par compétence.

• Windows : groupe de contacts Centreon contenant tous les utilisateurs administrant des équipements Windows
• Linux : groupe de contacts Centreon contenant tous les utilisateurs administrant des équipements Linux
• Network : groupe de contacts Centreon contenant tous les utilisateurs administrant des équipements réseau (switch, routeurs, parefeu, …)

Ensuite, il suffit de relier les groupes de contact au groupe d’hôtes correspondant. Voici la démonstration en vidéo. Je vous invite grandement à cliquer sur l’icône en bas à droite de la vidéo afin de la voir en plein écran. Celle-ci a été prise en haute définition (1280×720) pour qu’elle soit la plus lisible possible. Vous pourrez alors voir plus précisément les actions réalisées afin d’obtenir la même configuration que moi. L’inconvénient est que cette vidéo est relativement lourde : la lecture peut se couper à intervalle régulier. N’hésitez pas à mettre la vidéo sur pause afin que le téléchargement se fasse en tâche de fond. Une fois la moitié du fichier téléchargée, vous pouvez reprendre la lecture.