Manuel utilisateur¶

Installation¶

Pré-requis logiciels¶

Afin de pouvoir faire fonctionner VigiConf, l’installation préalable des logiciels suivants est requise :

python (>= 2.5), sur la machine où VigiConf est installé
postgresql-server (>= 8.2), éventuellement sur une machine distante

Reportez-vous aux manuels de ces différents logiciels pour savoir comment procéder à leur installation sur votre machine.

VigiConf requiert également la présence de plusieurs dépendances Python. Ces dépendances seront automatiquement installées en même temps que le paquet de VigiConf.

Installation du paquet RPM¶

L’installation de VigiConf se fait en installant simplement le paquet RPM “vigilo-vigiconf”. La procédure exacte d’installation dépend du gestionnaire de paquets utilisé. Les instructions suivantes décrivent la procédure pour les gestionnaires de paquets RPM les plus fréquemment rencontrés.

Installation à l’aide de urpmi:

urpmi vigilo-vigiconf        # sur la machine d'administration
urpmi vigilo-vigiconf-local  # sur les autres machines de la plate-forme de supervision

Installation à l’aide de yum:

yum install vigilo-vigiconf        # sur la machine d'administration
yum install vigilo-vigiconf-local  # sur les autres machines de la plate-forme de supervision

Configuration¶

La configuration de VigiConf comprend deux parties. D’une part, la configuration de l’outil en lui-même. D’autre part, la configuration du parc informatique supervisé par Vigilo (et dont la configuration est gérée par VigiConf). Ce chapitre ne porte que sur la configuration de VigiConf. Pour la documentation sur la configuration du parc informatique supervisé, reportez-vous au chapitre Configuration du parc à superviser.

Par défaut, la configuration de VigiConf se trouve dans /etc/vigilo/vigiconf/settings.ini. Vous devrez impérativement modifier ce fichier de configuration avant d’utiliser VigiConf.

Si vous le souhaitez, vous pouvez également placer les options de configuration communes à tous les modules de Vigilo installés sur la machine dans le fichier /etc/vigilo/settings.ini. Ce fichier générique sera chargé en premier au lancement de VigiConf.

Ces fichiers sont composés de différentes sections permettant de paramétrer des aspects divers de VigiConf, chacune de ces sections peut contenir un ensemble de valeurs sous la forme cle=valeur. Les lignes commençant par ”;” ou “#” sont des commentaires et sont par conséquent ignorées.

Le format de ces fichiers peut donc être résumé dans l’extrait suivant:

# Ceci est un commentaire
; Ceci est également un commentaire

[section1]
option1=valeur1
; ...
optionN=valeurN

; ...

[sectionN]
option1=valeur1
; ...
optionN=valeurN

Configuration de la base de données¶

Connexion¶

VigiConf enregistre une partie des informations de la configuration du parc supervisé en base de données. La configuration de la connexion à cette base de données se fait en modifiant la valeur de la clé sqlalchemy_url sous la section [database].

Cette clé consiste en une URL définissant tous les paramètres nécessaires pour pouvoir se connecter à la base de données. Le format de cette URL est le suivant:

sgbd://utilisateur:mot_de_passe@serveur:port/base_de_donnees

Le champ :port est optionnel et peut être omis si vous utilisez le port par défaut d’installation du SGBD choisi.

Par exemple, voici la valeur correspondant à une installation mono-poste par défaut de Vigilo:

postgresql://vigilo:vigilo@localhost/vigilo

Avertissement

À l’heure actuelle, seul PostgreSQL a fait l’objet de tests intensifs. D’autres SGBD peuvent également fonctionner, mais aucun support ne sera fourni pour ceux-ci.

Configuration du dépôt pour le suivi des évolutions¶

Les modifications apportées à la configuration du parc sont enregistrées dans un dépôt SVN, permettant ainsi d’assurer un suivi des modifications et un éventuel retour arrière.

La configuration de ce dépôt se fait en utilisant les clés suivantes de la section vigiconf:

confdir

Dossier contenant un « checkout » (version de travail) du dépôt SVN et dont les modifications seront enregistrées dans le dépôt à chaque utilisation de la commande “vigiconf deploy”.

Cette option doit pointer vers le dossier où la configuration du parc supervisé est sauvegardée.

svnusername

Nom d’utilisateur pour accéder au dépôt SVN.

svnpassword

Mot de passe pour accéder au dépôt SVN.

svnrepository

URL indiquant l’emplacement du dépôt SVN. Il peut s’agir d’une URL pointant vers un dépôt local (file://) ou distant (ssh+svn://, http://, etc.). Référez-vous à la documentation de Subversion pour les différents protocoles supportés.

Autres options de configuration¶

Les paragraphes qui suivent décrivent les autres options de configuration disponibles dans VigiConf et situées sous la section [vigiconf] du fichier settings.ini.

En règle générale, les valeurs correspondant à une nouvelle installation de VigiConf sont suffisantes et il n’est pas nécessaire de les modifier.

Répertoire de travail pour la génération¶

L’option “libdir” permet de spécifier l’emplacement du répertoire de travail servant à générer les fichiers de configuration des applications.

La valeur définie dans la configuration initiale est /var/lib/vigilo/vigiconf.

Emplacement final de la configuration¶

La directive “targetconfdir” permet d’indiquer le dossier vers lequel les fichiers de configuration finaux seront télé-déployés sur les serveurs de supervision.

La valeur définie dans la configuration initiale est /etc/vigilo/vigiconf. Les applications dont dépend Vigilo (ex : Nagios) doivent être configurées pour aller chercher leur fichier de configuration dans le sous-dossier “prod” de ce dossier.

Répertoire des plugins de VigiConf¶

L’option “pluginsdir” permet de faciliter l’extension de VigiConf à l’aide de plugins (modules complémentaires). Il s’agit de l’emplacement d’un répertoire qui contiendra des modules Python (eggs) qui seront chargés automatiquement au lancement de VigiConf. Ces modules ont la possibilité d’enregistrer des points d’entrée Python afin d’ajouter de nouvelles fonctionnalités.

La valeur de cette option dans la configuration initiale fournie avec VigiConf est /etc/vigilo/vigiconf/plugins.

Emplacement du verrou¶

Afin d’éviter un conflit lorsque plusieurs administrateurs du même parc effectuent un nouveau déploiement de la configuration simultanément, VigiConf acquiert un verrou au démarrage. Ce verrou est automatiquement libéré lors de l’arrêt de VigiConf.

La directive “lockfile” permet de spécifier l’emplacement du fichier qui correspondra au verrou. Dans la configuration fournie par défaut avec VigiConf, le verrou est enregistré dans /var/lock/subsys/vigilo-vigiconf/vigiconf.token.

Mode de simulation des opérations¶

L’option “simulate” est un booléen qui permet d’activer un mode spécial de VigiConf dans lequel les opérations sont simulées et ne sont pas validées. Cette option est destinée uniquement au débogage de l’application lors de la phase de développement et doit être positionnée à “False” en production.

Configuration du parc à superviser¶

La configuration du parc à superviser se fait au travers de fichiers XML. Ces fichiers sont stockés dans le répertoire pointé par l’option “confdir” de la section “vigiconf” dans le fichier de configuration de VigiConf. Des fichiers d’exemple sont installés en même temps que VigiConf.

Ce chapitre présente la structure de la configuration et le contenu des différents fichiers.

Fichiers de configuration XML¶

Afin d’éviter les erreurs de saisie dans les fichiers de configuration de VigiConf, ceux-ci font systématiquement l’objet d’une validation à l’aide de schémas XML.

Ces schémas sont stockés dans:

/usr/libarch/pythonversion/site-packages/vigilo/vigiconf/validation/xsd/

Par exemple, pour une installation standard de Python 2.5 sur une machine équipée d’une architecture x86:

/usr/lib/python2.5/site-packages/vigilo/vigiconf/validation/xsd/

Dans la suite de ce document, on considère qu’un fichier type.xml de la configuration de VigiConf est valide s’il respecte le schéma défini dans le fichier type.xsd situé dans ce répertoire correspondant au type d’objet manipulé.

Pour le reste des explications de ce chapitre, tous les emplacements de fichiers ou dossiers indiqués sont relatifs au dossier de configuration du parc (par défaut, /etc/vigilo/vigiconf/conf.d/)

Configuration des hôtes¶

Le dossier “hosts” contient les fichiers de définition des hôtes supervisés du parc. Tous les fichiers XML de ce dossier sont analysés et doivent contenir la définition d’un ou plusieurs hôtes.

La balise à la racine de ce document se nomme “hosts” et peut contenir un ou plusieurs blocs “host”, correspondant chacun à la définition d’un hôte.

Le fragment de code suivant rappelle la structure générale du fichier:

<?xml version="1.0"?>
<hosts>
  <host name="host1" attr1="..." attr2="..." attrN="...">
    ...
  </host>
  <host name="host2" attr1="..." attr2="..." attrN="...">
    ...
  </host>
  ...
</hosts>

Définition d’un hôte¶

Un hôte est défini à l’aide d’une balise host ayant la forme suivante:

<host name="localhost" address="127.0.0.1" ventilation="P-F">
  ...
</host>

Un bloc de données host possède les attributs suivants :

name

[requis] Nom de l’hôte. Il peut s’agir d’un nom entièrement qualifié (FQDN) ou simplement d’un nom court permettant d’identifier l’équipement au sein du parc.

address

[optionnel] Adresse permettant de communiquer avec l’hôte. Il peut s’agir d’une adresse IP (v4 ou v6) ou d’un nom de domaine entièrement qualifié (FQDN). Si cet attribut est omis, la valeur de l’attribut name est utilisée.

ventilation

[optionnel] Nom du groupe de supervision dans lequel cet hôte doit être placé (ventilé).

En général, il n’est pas nécessaire de spécifier cet attribut. VigiConf tente de le déduire automatiquement à partir des noms des groupes auxquels l’hôte est rattaché. Cet attribut permet essentiellement de résoudre les conflits entre les groupes. Il peut également être utilisé pour affecter l’hôte à un groupe de supervision qui n’a aucune relation avec les groupes métier.

La balise host peut contenir les balises suivantes :

class (0 ou plus)
template (0 ou plus)
attribute (0 ou plus)
nagios (0 ou 1)
test (0 ou plus)
tag (0 ou plus)
group (1 ou plus)

Balise “`class`“¶

Syntaxe:

<class>nom de la classe</class>

Indique la ou les classes d’équipements auxquelles l’hôte appartient. En fonction de ces classes, des tests spécifiques peuvent être disponibles afin d’obtenir des informations plus précises sur l’état de l’équipement.

Balise “`template`“¶

Syntaxe:

<template>nom du modèle</template>

Précise le nom du modèle d’hôtes duquel cet hôte hérite une partie de ses propriétés. L’utilisation de l’héritage est pratique lorsque votre parc est composé d’éléments (serveurs, routeurs, etc.) homogènes. Vous pouvez alors définir un modèle (template) pour chaque type d’équipement avec tous les tests associés et créer ensuite simplement une définition d’hôte pour chaque équipement.

Cette balise peut être utilisée à plusieurs reprises. Les paramètres du dernier modèle chargé écrasent ceux des modèles précédents. Les valeurs définies au niveau d’un hôte écrase toujours les valeurs définies au niveau d’un modèle hérité (en particulier, les paramètres des tests).

Note

Pour être utilisable via cette balise, le modèle doit avoir été défini à l’aide de la balise hosttemplate (voir Configuration des modèles d’hôtes).

Avertissement

En cas de conflits liés aux dépendances des modèles, il se peut que les modèles soient réordonnés (un message d’avertissement est alors émis par VigiConf lors du déploiement). Dans ce cas, l’ordre d’application des paramètres peut être légèrement différent de l’ordre d’affectation des modèles dans le fichier de configuration.

Balise “`attribute`“¶

Syntaxes:

<attribute name="nom de l'attribut">valeur de l'attribut</attribute>

<attribute name="nom de l'attribut">
  <item>valeur 1</item>
  <item>valeur 2</item>
</attribute>

Cette balise permet de fixer certains des attributs de l’hôte, comme par exemple le nombre de processeurs présents sur la machine. En général, ces informations sont extraites automatiquement des équipements par une interrogation SNMP (voir à ce sujet le chapitre « Découverte des services à superviser sur un hôte »).

Les noms d’attributs utilisables dépendent des tests de supervision installés avec VigiConf. Par défaut, les attributs suivants sont disponibles :

“collectorTimeout” : délai d’attente utilisé lors de la récupération des données SNMP de l’hôte ;
“cpulist“ : la liste des identifiants des processeurs sur l’équipement ;
“fans“ : la liste des identifiants des ventilateurs sur l’équipement ;
“snmpCommunity“ : la communauté pour l’accès SNMP à l’équipement ;
“snmpPort“ : le port SNMP à utiliser (par défaut, le port 161 est utilisé) ;
“snmpVersion“ : la version SNMP à utiliser (par défaut, la version 2 est utilisée) ;
“tempsensors“ : la liste des noms des sondes de température présentes sur l’équipement.

Balise “`test`“¶

Syntaxe:

<test name="nom du test">
  <arg name="nom_argument_1">valeur argument 1</arg>
  <arg name="nom_argument_2">valeur argument 2</arg>
  ...
  <arg name="nom_argument_n">valeur argument n</arg>
  <nagios>
    <directive name="nom_directive_1">valeur directive 1</directive>
    ...
    <directive name="nom_directive_n">valeur directive n</directive>
  </nagios>
</test>

La balise test permet d’ajouter un test de supervision à l’hôte. Elle possède un attribut name obligatoire qui désigne le test de supervision à appliquer (par exemple : “CPU” pour superviser l’état du processeur d’un équipement).

Un test accepte généralement zéro, un ou plusieurs arguments, qui doivent être passés dans l’ordre lors de la déclaration du test, à l’aide de la balise arg. Chaque argument dispose d’un nom (attribut name) et d’une valeur (ou liste de valeurs). Pour spécifier une liste de valeurs pour un argument, la sous-balise item doit être utilisée, comme dans l’extrait suivant :

<test name="ACL">
    <arg name="policy">whitelist</arg>
    <!--
        L'argument "addresses" est une liste d'adresses IP,
        sous-réseaux ou noms de machines.
    -->
    <arg name="addresses">
        <item>127.0.0.1</item>
        <item>localhost</item>
        <item>192.168.0.0/24</item>
    </arg>
</test>

Chaque argument possède un type (spécifié dans la documentation du test). Les types reconnus sont :

les chaînes de caractères ;
les nombres entiers ;
les nombres relatifs (flottants) ;
les booléens (utiliser la valeur 1, true, on ou yes pour la valeur True ou bien 0, false, off ou no pour la valeur False).

Vous pouvez également, de façon optionnelle, définir des paramètres spécifiques pour la supervision à l’aide de la balise nagios, qui contiendra une ou plusieurs directives adressées au moteur de supervision Nagios. Voir la section ci-dessous pour plus d’informations.

Note

Si le même argument est défini deux fois, seule la dernière valeur sera utilisée.

Balise “`nagios`“¶

Un bloc de données nagios contient des blocs directive dont l’attribut name appartient à la liste des directives “host” de Nagios. La documentation sur ces directives est disponible dans la documentation Nagios.

Syntaxe:

<nagios>
  <directive name="max_check_attempts">5</directive>
  <directive name="check_interval">10</directive>
  <directive name="retry_interval">1</directive>
</nagios>

Toutes les directives proposées par Nagios sont utilisables ici. Néanmoins, un mauvais réglage des directives peut dégrader sérieusement les performances de la supervision, voire entrainer un dysfonctionnement. L’utilisation des directives est donc à laisser à des utilisateurs avertis.

Un bloc nagios peut se trouver au sein d’un bloc host/hosttemplate ou d’un bloc test.

Si la même directive est défini deux fois, la dernière valeur est celle qui sera utilisée.

Balise “`tag`“¶

Syntaxe:

<tag service="service" name="étiquette"/>

<tag service="service" name="étiquette">valeur</tag>

La balise tag permet d’affecter une étiquette à un hôte ou un service. L’attribut name permet de préciser le nom de l’étiquette à ajouter. Il doit correspondre au nom d’une image (privée de son extension) à afficher dans VigiMap. Cette image doit se trouver dans /etc/vigilo/vigimap/public/images/tags.

L’attribut service permet, quant à lui, d’indiquer le nom du service auquel cette étiquette sera affectée. Utilisez la valeur “host” si l’étiquette doit porter sur l’hôte en lui-même et non pas sur l’un de ses services.

Enfin, la valeur de l’étiquette est facultative et fait office de méta-donnée. Exemple, pour associer à un hôte l’étiquette de MCO (l’image mco.png est fournie dans toute installation standard de Vigilo):

<tag service="host" name="mco"/>

Balise “`group`“¶

Syntaxe:

<group>/Chemin complet/vers le/Groupe</group>

<group>Nom de groupe</group>

La balise group permet d’indiquer les groupes métiers auxquels cet équipement appartient. Les groupes sont organisés de manière hiérarchique (sous la forme d’un arbre).

La première forme (chemin absolu) permet de se déplacer dans cette hiérarchie en donnant le chemin complet jusqu’au groupe, de la racine de l’arbre vers les feuilles. Chaque élément du chemin est précédé du symbole “/”. Si le nom de l’élément contient un “/” ou un “\”, vous devez le faire précéder du caractère d’échappement “\”. Ainsi, l’élément “Serveurs Linux/Unix” sera écrit dans les chemins comme “Serveurs Linux\/Unix”.

La seconde forme (chemin relatif) permet d’ajouter l’équipement à tous les groupes dont le nom vaut celui indiqué, quelque soit leur position dans l’arbre. Il n’est pas possible de préciser plusieurs éléments (par exemple “A/B”) lorsque cette forme est utilisée. Les règles d’échappement de la première forme s’appliquent également ici.

Note

Les groupes sont utilisés pour décider de la ventilation des équipements sur les différents groupes de supervision. Une fois tous les groupes exprimés sous la forme d’un chemin absolu, VigiConf suppose que le premier élément du chemin correspond au groupe à utiliser pour la ventilation. En cas de conflit, ou pour placer l’équipement dans un autre groupe de ventilation que celui déterminé automatiquement, vous devez utiliser l’attribut ventilation de la balise host afin de spécifier manuellement le groupe de ventilation à utiliser.

Remarques¶

De même que pour les tests, l’hôte peut disposer de directives de configuration spécifiques destinées à Nagios. Celles-ci seront groupées sous une balise nagios (voir également la documentation concernant la balise test ci-dessus).

Chaque hôte hérite implicitement d’un modèle appelé “default”. Toutes les directives définies dans le modèle “default” sont donc appliquées à la configuration des différents hôtes, et ce même si ces hôtes n’indiquent pas explicitement qu’ils utilisent ce modèle, via la balise <template>. Voir le chapitre pour plus d’information.

Configuration des modèles d’hôtes¶

Le dossier “hosttemplates” contient les fichiers de définition des modèles d’hôtes. Un modèle d’hôtes permet de regrouper un ensemble d’éléments de configuration communs à plusieurs hôtes. Les hôtes peuvent ensuite être déclarés comme héritant de ce modèle. Tous les fichiers XML de ce dossier sont analysés et doivent contenir la définition d’un ou plusieurs modèles.

La balise à la racine de ce document se nomme “hosttemplates” et peut contenir un ou plusieurs blocs “hosttemplate”, correspondant chacun à la définition d’un hôte.

Le fragment de code suivant rappelle la structure générale du fichier:

<?xml version="1.0"?>
<hosttemplates>
    <hosttemplate attr1="..." attr2="..." attrN="..."> ... </hosttemplate>
    <hosttemplate attr1="..." attr2="..." attrN="..."> ... </hosttemplate>
...
</hosttemplates>

Un bloc de données hosttemplate possède les attributs suivants:

name: Nom du modèle.

Un bloc de données hosttemplate contient les blocs suivants, en respectant l’ordre:

parent (0 ou un)
attribute (0 ou plus)
tag (0 ou plus)
group (0 ou plus)
class (0 ou plus)
test (0 ou plus)
nagios (0 ou un)
item (0 ou plus)

Balise “`parent`“¶

Un bloc de données parent contient une simple chaîne de caractères, le nom du template dont ce template hérite. Il est possible de créer autant de niveaux d’héritage de templates que souhaité et chaque template peut hériter d’un ou plusieurs templates (héritage multiple).

Exemple:

<parent>generic</parent>

Balise “`attribute`“¶

Un bloc de données attribute possède un attribut : name.

Un bloc de données attribute contient une valeur de type chaîne de caractères.

Exemple:

<attribute name="snmpOIDsPerPDU">10</attribute>

Balise “`tag`“¶

Syntaxe:

<tag service="service" name="étiquette"/>

<tag service="service" name="étiquette">valeur</tag>

La balise tag permet d’affecter une étiquette à un hôte ou un service. L’attribut name permet de préciser le nom de l’étiquette à ajouter. Il doit correspondre au nom d’une image (privée de son extension) à afficher dans VigiMap. Cette image doit se trouver dans /etc/vigilo/vigimap/public/images/tags.

L’attribut service permet, quant à lui, d’indiquer le nom du service auquel cette étiquette sera affectée. Utilisez la valeur “host” si l’étiquette doit porter sur l’hôte en lui-même et non pas sur l’un de ses services.

Enfin, la valeur de l’étiquette est facultative et fait office de méta-donnée. Exemple, pour associer à un hôte l’étiquette de MCO (l’image mco.png est fournie dans toute installation standard de Vigilo):

<tag service="host" name="mco"/>

Balise “`group`“¶

Un bloc de données group contient une chaîne de caractères.

Exemple:

<group>AIX servers</group>

Balise “`class`“¶

Un bloc de données class contient une simple chaîne de caractère.

Exemple:

<class>aix</class>

Balise “`test`“¶

Un bloc de données test possède l’attribut suivant :

name (1 exactement)

Un bloc de données test contient les blocs suivants, dans l’ordre :

arg (0 ou plus)
nagios (0 ou 1)

Reportez-vous à la documentation sur la configuration des tests d’un hôte pour plus d’information sur les attributs et blocs acceptés par cette balise.

Exemple:

<test name="Proc">
  <arg name="label">aixmibd</arg>
  <arg name="processname">.*aixmibd .*</arg>
  <nagios> ... </nagios>
</test>

Balise “`nagios`“¶

Voir la définition utilisée pour la balise host : Balise “nagios”.

Balise “`item`“¶

Un bloc de données item contient une simple chaîne de caractère.

Exemple:

<item>item1</item>

Cas particulier du modèle “`default.xml`“¶

Le modèle nommé “default.xml” est un cas particulier de modèle. Il est appliqué systématiquement à tous les hôtes configurés.

Par défaut, ce modèle contient des attributs destinés à configurer le comportement de Nagios et à renseigner certaines informations relatives à la configuration de SNMP sur le parc. Il contient également le test “UpTime” qui envoie une alerte lorsque la durée de fonctionnement d’une machine est trop faible (c’est-à-dire lorsqu’elle a été redémarrée récemment).

Dossier “`groups`“¶

Le dossier “groups” contient les fichiers de définition des groupes d’éléments supervisés. Tous les fichiers XML de ce dossier sont analysés et doivent contenir la définition d’un ou plusieurs groupes.

L’utilisation de groupes facilite la gestion au quotidien des permissions (application en masse d’une permission sur un groupe d’éléments supervisés à un groupe d’utilisateurs).

La balise à la racine de ce document se nomme “groups” et peut contenir un ou plusieurs blocs “group”, correspondant chacun à la définition d’un groupe d’éléments supervisés.

Le fragment de code suivant rappelle la structure générale du fichier:

<?xml version="1.0"?>
<groups>
  <group attr1="..." attr2="..." attrN="..."> ... </group>
  <group attr1="..." attr2="..." attrN="..."> ... </group>
  ...
</groups>

Balise “`group`“¶

Un bloc de données group possède un attribut: name.

Le bloc de données group peut possèder un ou plusieurs sous-blocs group. Cette imbrication peut être répétée autant de fois que nécessaire et permet de construire une hiérarchie de groupes. Cette hiérarchie est ensuite utilisée dans les différentes interfaces, pour la gestion des permissions, ou encore, pour organiser les informations.

Exemple:

<group name="group1" />

<group name="group2" >
  <group name="group21"/>
  ...
</group>

Le même nom de groupe ne peut pas être utilisé plusieurs fois au même niveau dans la hiérarchie des groupes. C’est-à-dire que l’exemple suivant est interdit:

<!-- Attention, cet exemple ne fonctionne pas ! -->
<group name="group1">
    <group name="group2"/>
    <group name="group2"/>
</group>

En revanche, le même nom de groupe peut être utilisé dans des endroits séparés de l’arborescence, comme dans l’exemple ci-dessous:

<group name="group1">
    <group name="group1">
        <group name="group1"/>
    </group>
</group>

Notez que chacun des “group1” correspond à un groupe différent.

Dossier “`hlservices`“¶

Cette fonctionnalité n’est disponible que dans la version Enterprise de Vigilo.

Configurations particulières¶

Ce chapitre recense des cas particuliers de configuration. Pour chaque cas, un exemple de configuration associée est donné.

Utilisation de SNMPv3¶

L’utilisation de SNMP version 3 nécessite un peu plus de configuration que pour SNMP version 1 ou 2c. En effet, en plus de la définition de la communauté de l’équipement, il est nécessaire de spécifier les éléments de sécurité permettant d’authentifier la connexion à l’équipement et/ou d’assurer la confidentialité des échanges SNMP avec l’équipement.

Aucun test particulier n’est à appliquer pour utiliser SNMPv3 dans Vigilo. Cependant, des attributs supplémentaires doivent être définis au niveau de la configuration de l’équipement fonctionnant avec SNMPv3.

Le listing suivant présente un exemple de configuration d’un hôte devant être interrogé en utilisant SNMPv3:

<attribute name="snmpVersion">3</attribute>
<attribute name="snmpSeclevel">authPriv</attribute>
<attribute name="snmpAuthproto">MD5</attribute>
<attribute name="snmpPrivproto">DES</attribute>
<attribute name="snmpSecname">snmpuser1</attribute>
<attribute name="snmpAuthpass">12345678</attribute>
<attribute name="snmpPrivpass">12345678</attribute>

Les noms des attributs suivent la terminologie standard de SNMPv3, excepté pour le préfixe “snmp” qui ne sert qu’à empêcher d’éventuels conflits de nommage avec d’autres attributs similaires.

Le rôle de chacun de ces attributs est précisé ci-dessous :

L’attribut “snmpVersion” indique que c’est la version 3 du protocole SNMP qui doit être utilisée pour interroger l’équipement.
L’attribut “snmpSeclevel” indique les contraintes de sécurité à apporter sur les communications avec l’équipement. Les valeurs possibles sont :
- “noAuthNoPriv” (no authentication / no privacy) : aucune authentification n’a lieu et les échanges ne sont pas chiffrés. Cette valeur correspond à ce qui est fourni par SNMPv1 et SNMPv2c et n’offre aucune sécurité. Il est donc recommandé de ne pas utiliser cette valeur (sauf cas exceptionnels).
- “authNoPriv” (authentication / no privacy) : Vigilo s’authentifiera auprès de l’équipement avec un nom d’utilisateur et un mot de passe dédiés. Les échanges avec l’équipement ne seront pas chiffrés et les communications pourront donc être écoutées par n’importe quelle personne disposant d’un accès physique au réseau.
- “authPriv” (authentication / privacy) : Vigilo s’authentifiera auprès de l’équipement avec un nom d’utilisateur et un mot de passe dédiées. De plus, tous les échanges seront chiffrés. Cette valeur est celle offrant le plus de sécurité et est donc recommandée.
L’attribut “snmpAuthproto” est obligatoire lorsque “snmpSeclevel” vaut “authNoPriv” ou “authPriv” et spécifie l’algorithme utilisé pour masquer le mot de passe lors des transmissions avec l’équipement. Les valeurs possibles sont “MD5” et “SHA1”.
L’attribut “snmpPrivproto” est obligatoire lorsque “snmpSeclevel” vaut “authPriv” et spécifie l’algorithme de chiffrement utilisé pour les échanges avec l’équipement. Les valeurs possibles sont “DES” et “AES”.
L’attribut “snmpSecname” est obligatoire lorsque “snmpSeclevel” vaut “authNoPriv” ou “authPriv” et indique le nom d’utilisateur avec lequel Vigilo s’authentifiera auprès de l’équipement.
L’attribut “snmpAuthpass” est obligatoire lorsque “snmpSeclevel” vaut “authNoPriv” ou “authPriv” et indique le mot de passe à utiliser pour s’authentifier auprès de l’équipement. Il peut être donné sous forme textuelle (comme dans l’exemple ci-dessus) ou sous forme de chaîne de caractères hexadécimaux en préfixant la valeur par “0x”.
L’attribut “snmpPrivpass” est obligatoire lorsque “snmpSeclevel” vaut “authPriv” et spécifie la clé de chiffrement utilisée pour les échanges avec l’équipement. Elle peut être donnée sous forme textuelle (comme dans l’exemple ci-dessus) ou sous forme de chaîne de caractères hexadécimaux en préfixant la valeur par “0x”.

Configuration des journaux¶

VigiConf est capable de transmettre un certain nombre d’informations au cours de son fonctionnement à un mécanisme de journalisation des événements (par exemple, des journaux systèmes, une trace dans un fichier, un enregistrement des événements en base de données, etc.).

La syntaxe de la configuration des journaux est la même que pour le reste de la configuration. Les mécanismes utilisés pour gérer les journaux sont ceux mis à disposition par le module logging de Python.

Le reste de cette chapitre présente les informations basiques concernant la configuration des journaux. La documentation complète du format de configuration est disponible à l’adresse http://docs.python.org/library/logging.html#configuration-file-format

La configuration de la journalisation se fait en manipulant trois types d’objets :

les loggers, qui permettent de configurer les modules python qui devront être journalisés et de définir les gestionnaires d’événements à appliquer ;
les handlers (gestionnaires d’événements), qui indiquent le traitement qui doit être appliqué aux événements reçus (enregistrement dans un fichier, dans les journaux Syslog du système, stockage en base de données, etc.) ;
les formatters, qui permettent de configurer le formatage appliqué aux événements.

Les sections qui suivent vous donnent des informations sur la configuration de chacun de ces éléments.

Configuration des `loggers`¶

Les loggers permettent d’indiquer les sources d’événements pour lesquelles les événements de journalisation seront effectivement consignés. Ils permettent également de définir les traitements qui seront appliqués à ces événements (pour définir par exemple la destination des événements).

La configuration des loggers se fait en deux étapes :

dans un premier temps, les loggers sont déclarés,
puis, les loggers déclarés sont configurés.

Déclaration d’un `logger`¶

La déclaration des loggers se fait sous la forme d’une liste des noms des loggers, contenue sous la clé « keys » de la section « loggers ».

Les loggers sont organisés sous une forme hiérarchique, qui suit l’organisation des modules Python sur le disque dur. Si aucun logger n’est défini pour traiter les messages d’un module, le logger défini sur le niveau supérieur est utilisé. L’arborescence du système de fichiers est ainsi parcourue jusqu’à ce qu’un logger intercepte le message ou qu’on ne puisse plus remonter.

Si aucun logger n’est trouvé après le parcours de la hiérarchie, un message d’avertissement est affiché sur la console afin d’inciter l’utilisateur à configurer correctement les journaux.

Par ailleurs, un logger spécial est défini qui apparaît toujours au sommet de la hiérarchie des loggers, nommé « root ».

Exemple de parcours de la hiérarchie des loggers :

Si le module Python vigilo.common.conf émet un événement et qu’aucun logger n’est associé à ce module, le gestionnaire de journaux recherche un logger pour le module vigilo.common. S’il n’en trouve pas, il recherche un logger pour le module vigilo. Si après toutes ces recherches il n’en trouve toujours pas, il recherche le logger root.

Configuration d’un `logger`¶

Chaque logger déclaré doit ensuite être configuré. La configuration d’un logger appelé <nom_du_logger> se fait en ajoutant une section appelée logger_<nom_du_logger> dans le fichier de configuration.

Pour chaque logger, les clés suivantes sont configurables :

level (obligatoire) : niveau de criticité à partir duquel les messages seront pris en compte. Les niveaux utilisables sont (par ordre de criticité croissante) :
- NOTSET pour que l’événement soit toujours pris en compte, quelle que soit sa criticité,
- DEBUG pour ne prendre en compte que les événements au niveau « débogage » ou supérieur,
- INFO pour ne prendre en compte que les événements au niveau « information » ou supérieur,
- WARNING pour ne prendre en compte que les événements au niveau « avertissement » ou supérieur,
- ERROR pour ne prendre en compte que les événements au niveau « erreur » ou supérieur,
- CRITICAL pour ne prendre en compte que les événements au niveau « critique ».
qualname optionnel le nom du module Python qui sert de source pour les événements enregistrés par ce logger. Si ce champ est omis, c’est que le logger se trouve au sommet de la hiérarchie, et donc, qu’il s’agit du logger « root ».
propagate optionnel un entier qui indique si l’événement doit être propagé (1) aux loggers situés « au-dessus » dans la hiérarchie ou non (0). Par défaut, les messages sont propagés.
handlers obligatoire une liste contenant les noms des handlers gestionnaires d’événements qui traiteront les événements capturés par ce logger.

Exemple de configuration d’un `logger`¶

L’encadré suivant présente un exemple de configuration d’un logger nommé « log ». Cet exemple suppose par ailleurs qu’un handler « hand » a été défini dans la configuration.

[loggers]
keys=log

[logger_log]
level=WARNING
qualname=vigilo
handlers=hand

Ce logger intercepterait tous les événements émis par un composant de Vigilo et les enverrait au handler « hand » pour qu’ils soient traités.

Configurations des `handlers` (gestionnaires d’événements)¶

Les handlers permettent d’indiquer comment sont traités les événements reçus. Ils permettent par exemple d’indiquer que les messages doivent être stockés dans une base de données, dans les journaux systèmes, envoyés par email, etc.

La configuration des handlers se fait en deux étapes :

dans un premier temps, les handlers sont déclarés,
puis, les handlers déclarés sont configurés.

Déclaration d’un `handler`¶

La déclaration des handlers se fait sous la forme d’une liste des noms des handlers, contenue sous la clé « keys » de la section « handlers ».

Configuration d’un `handler`¶

Chaque handler déclaré doit ensuite être configuré. La configuration d’un handler appelé <nom_du_handler> se fait en ajoutant une section appelée « handler_<nom_du_handler> » dans le fichier de configuration.

Pour chaque handler, les clés suivantes sont configurables :

class (obligatoire) : la classe Python qui effectuera le stockage des messages. Les plus couramment utilisées sont « handlers.SysLogHandler » (enregistrement vers les journaux systèmes de Linux), « StreamHandler » (enregistrement dans un flux, comme par exemple la sortie standard du programme). La liste complète des handlers utilisables est disponible sur http://docs.python.org/library/logging.html
args (optionnel) : arguments qui seront passés au constructeur de la classe désignée par la clé class.
level (obligatoire) : le niveau de criticité à partir duquel les messages seront pris en compte. Les niveaux utilisables sont les mêmes que pour les loggers.
formatter (obligatoire) : le nom du formatter à utiliser pour mettre en forme les messages.

Exemple de configuration d’un `handler`¶

L’encadré suivant présente un exemple de configuration d’un handler nommé « hand ». Cet exemple suppose par ailleurs qu’un formatter « fmt » a été défini dans la configuration.

[handlers]
keys=hand

[handler_hand]
class=handlers.SysLogHandler
args='/dev/log', 'daemon'
level=NOTSET
formatter=fmt

Ce handler enregistre les événements dans le journal du système, quelque soit leur niveau de criticité, en utilisant le formatter « fmt ».

Configuration des `formatters`¶

Les formatters permettent de mettre en forme les messages avant leur stockage. La configuration des formatters se fait en deux étapes :

dans un premier temps, les formatters sont déclarés,
puis, les formatters déclarés sont configurés.

Déclaration d’un `formatter`¶

La déclaration des formatters se fait sous la forme d’une liste des noms des formatters, contenue sous la clé « keys » de la section « formatters ».

Configuration d’un `formatter`¶

Chaque formatter déclaré doit ensuite être configuré. La configuration d’un formatter appelé <nom_du_formatter> se fait en ajoutant une section appelée «formatter_<nom_du_formatter> » dans le fichier de configuration.

Pour chaque formatter, les clés suivantes sont configurables :

format (obligatoire) : un texte qui décrit la mise en forme du message. Ce texte peut faire références à des informations contextuelles concernant l’événement à enregistrer. Ces informations contextuelles sont insérées en utilisant le mécanisme de formatage des chaines de caractères de Python. Par exemple, le message original de l’événement peut être inséré dans le texte qui sera effectivement enregistré à l’aide de la substitution suivante
```
%(message)s
```
La liste des informations contextuelles les plus fréquemment utilisées est fournie dans la suite de ce document. La liste complète peut être consultée en lisant la documentation de Python concernant le module logging.
datefmt (optionnel) : un texte indiquant le format à utiliser pour les dates. La description complète du format est présentée dans la documentation de Python (http://docs.python.org/library/time.html#time.strftime). Par défaut, le format ISO 8601 est utilisé.

Informations contextuelles disponibles pour les `formatters`¶

Plusieurs informations contextuelles peuvent être insérées automatiquement par les formatters avant l’envoi d’un message dans les journaux.

Les informations contextuelles suivantes sont disponibles :

La date à laquelle l’événement est survenu peut être insérée, dans un format intelligible, grâce à la substitution suivante
```
%(asctime)s
```
La criticité du message reçu (DEBUG, WARNING, ERROR, etc.) peut être insérée sous forme textuelle grâce à la substitution suivante
```
%(levelname)s
```
Le nom du module qui a émis le message peut être inséré grâce à cette substitution
```
%(module)s
```
Le message original associé à l’événement peut être inséré grâce à cette substitution
```
%(message)s
```

Cette liste ne contient que les informations les plus couramment utilisées. La liste complète est disponible sur http://docs.python.org/library/logging.html#formatter.

Exemple de configuration d’un `formatter`¶

L’encadré suivant présente un exemple de configuration d’un formatter nommé « fmt ».

[formatters]
keys=fmt

[formatter_fmt]
format=[%(asctime)s] %(levelname)s – %(message)s
datefmt=%a, %d %b %Y %H:%M:%S

Ce formateur affiche le niveau de criticité (sous forme textuelle) ainsi que le message de l’événement original. Le message est précédé de la date.

Un exemple de message enregistré en utilisant ce formateur serait :

[Thu, 28 Jun 2001 14:17:15] ERROR – Could not connect to memcached.

Exemple de configuration complète des journaux¶

L’encadré qui suit donne un exemple simple mais complet d’une configuration des journaux dans le cas du corrélateur de Vigilo. Le résultat de cette configuration est ensuite détaillé.

[loggers]
keys = root,rules

[handlers]
keys = syslog

[formatters]
keys = generic

[logger_root]
level = WARNING
handlers = syslog

[logger_rules]
level = INFO
handlers = syslog
qualname = vigilo.correlator.rules

[handler_syslog]
class=handlers.SysLogHandler
level=DEBUG
formatter=nullFormatter
args='/dev/log', 'daemon'

[formatter_generic]
format = %(message)s
datefmt =

Dans cette configuration, tous les messages émis par le corrélateur et qui ont un niveau de criticité au moins équivalent à « WARNING » sont enregistrés dans les journaux du système (syslog).

Par ailleurs, les messages issus des règles de corrélation (module Python vigilo.correlator.rules) sont consignés dès lors que leur niveau de criticité est supérieur ou égal à « INFO ».

Le message enregistré a un formatage « brut » où seul le message apparaît. En effet, dans le cas d’un handler de type « handlers.SysLogHandler », il n’est pas nécessaire d’ajouter des informations supplémentaires (nom et PID du processus qui a envoyé l’événement, heure où l’événement a été consigné, etc.). Le système ajoute automatiquement ces informations à l’événement.

Utilisation de l’utilitaire “`vigiconf`“¶

La génération des fichiers de configuration des différentes applications en charge de la supervision du parc se fait en utilisant l’utilitaire “vigiconf” fourni lors de l’installation du paquet portant le même nom.

Cet utilitaire permet d’effectuer les opérations suivantes :

Affichage des informations concernant la configuration actuelle ;
Gestion des applications ;
Retour arrière de la configuration ;
Déploiement d’une nouvelle configuration ;
Découverte des services présents sur le réseau.

La commande “vigiconf --help” permet d’obtenir l’aide de l’utilitaire. Elle affiche la sortie suivante:

usage : vigiconf [-h] [--debug] {info,server-status,discover,deploy} ...

Gestionnaire de configuration Vigilo

arguments optionnels:
-h, --help affiche ce message d'aide et quitte
--debug Mode de débogage

Sous-commandes: {info,server-status,discover,deploy}

info           Affiche un résumé de la configuration actuelle.
deploy         Déploie la configuration sur chaque serveur si la
               configuration a changé.
discover       Découvrir les services disponibles sur un serveur
               distant.
server-status  Active ou désactive un serveur Vigilo.

Ces différentes opérations sont détaillées dans les sections qui suivent.

Vous pouvez obtenir l’aide sur une commande en tapant “vigiconf nom_de_la_commande --help”.

Affichage des informations¶

L’affichage des informations concernant la configuration actuelle se fait en exécutant la commande “vigiconf info”.

La commande renvoie plusieurs informations, comme dans l’exemple d’exécution suivant:

VigiConf a été lancé depuis le compte 'root'. Utilisation du compte 'vigiconf' à la place.
Révision actuelle dans le dépôt : 358
Serveur supserver1.example.com:
    déployé: 358
    installé: 358
    précédent: 358
Serveur supserver2.example.com:
    déployé: 358
    installé: 358
    précédent: 358
    DÉSACTIVÉ
VigiConf se termine

La révision actuelle correspond à la dernière version de la configuration validée sur la machine qui héberge VigiConf.

Les lignes suivantes affichent, pour chaque serveur de supervision : son nom, éventuellement son état (lorsque le serveur est désactivé), ainsi que les numéros de la révision de la configuration actuellement déployée (donc en production), de la dernière révision installée et de la précédente révision installée.

Vous pouvez préciser les noms des serveurs de supervision dont les informations doivent être affichés en passant simplement leur nom comme argument de la commande.

Note

Toutes les valeurs sont à 0 lors d’une nouvelle installation (car aucun des serveurs n’a encore été configuré).

Déploiement de la configuration¶

Une fois la configuration des différents éléments du parc effectuées, vous pouvez la déployer sur les divers machines de la supervision à l’aide de la commande “vigiconf deploy”.

Vous pouvez passer en argument la liste des noms des serveurs de supervision pour lesquels une nouvelle version de la configuration doit être déployée.

Découverte des services à superviser sur un hôte¶

Afin d’assister l’administrateur dans sa configuration des tests de supervision d’un serveur, VigiConf dispose d’un mode de découverte automatique des services disponibles sur un hôte.

La commande “vigiconf discover” prend en arguments les noms d’hôtes (entièrement qualifiés) ou les fichiers de scan à analyser afin de découvrir les services à superviser. Les fichiers de scan doivent avoir été générés à l’aide de la commande “snmpwalk” sur l’OID “.1” en lui passant les options “-OnQe”.

Exemple de commande pour créer le fichier de scan:

SNMPCONFPATH=/dev/null snmpwalk -OnQe -v2c -c public hostname .1 \
    > hostname-OnQe.walk

Note

“SNMPCONFPATH=/dev/null” permet d’éviter l’import d’options de configuration depuis des fichiers du système tels que :

/etc/snmp/snmp.local.conf
/etc/snmp/snmp.conf

Par défaut, cette commande affiche sur la sortie standard le fichier de configuration XML correspondant aux équipements analysés. Le listing suivant présente le résultat d’une telle analyse:

<?xml version="1.0"?>
<host address="127.0.0.1" name="localhost.localdomain">
  <group>Servers</group>
  <class>ucd</class>
  <test name="Users" />
  <test name="Partition">
    <arg name="partname">/home</arg>
    <arg name="label">/home</arg>
  </test>
  <test name="Partition">
    <arg name="partname">/</arg>
    <arg name="label">/</arg>
  </test>
  <test name="TotalProcesses" />
  <test name="Swap" />
  <test name="CPU" />
  <test name="Load" />
  <test name="RAM" />
  <test name="UpTime" />
  <test name="TCPConn" />
  <test name="InterrCS" />
</host>

Le résultat de cette commande peut être enregistré directement dans un fichier de configuration XML afin d’être lu ensuite par VigiConf en utilisant l’option “-o” suivie de l’emplacement du fichier dans lequel le résultat doit être sauvegardé.

La découverte peut-être limitée à un test en particulier via l’option “-t”.

Activation / désactivation d’un serveur de supervision¶

La commande “vigiconf server-status” permet d’activer ou de désactiver un ou plusieurs serveurs de la plate-forme de supervision. Elle doit être appelée avec au moins 2 arguments.

Le 1er argument indique l’action à effectuer et peut valoir :

“enable” pour activer un ou plusieurs serveurs de supervision précédemment désactivés.
“disable” pour désactiver un ou plusieurs serveurs de supervision.

Annexes¶

Tests de supervision disponibles dans Vigilo¶

Le tableau suivant recense les tests de supervision disponibles dans Vigilo.

Liste des tests de supervision disponibles dans Vigilo¶
Nom du test	Classes disponibles	Détails
Collector	Toutes	The Collector service
CPU	linux ucd	Check the CPU usage of a host (service only) Paramètres acceptés par le test : `crit`: CRITICAL threshold (unused, for compatibility) `warn`: WARNING threshold (unused, for compatibility)
DiskIO	ucd	Monitor the disks Input/Output Paramètres acceptés par le test : `crit`: tuple containing the thresholds for CRITICAL status. Ex: (limit_reads, limit_writes) `diskname`: disk name. Default: hdisk0 `warn`: tuple containing the thresholds for WARNING status. Ex: (limit_reads, limit_writes)
HTTP	Toutes	Check if the HTTP service is up
HTTP_url	Toutes	Check if the HTTP service is up for a given url Paramètres acceptés par le test : `port`: Le port sur lequel le serveur web écoute (80 par défaut). `service`: Le nom du service à utiliser dans Nagios.
HTTPS	Toutes	Check if the SSL certificates on the HTTPS server are OK
Interface	Toutes	Check the status of an interface, and graph its throughput Paramètres acceptés par le test : `counter32`: to use Counter32bits specifically for this interface. `crit`: CRITICAL threshold. See description for the format. `errors`: create a graph for interface errors `ifname`: SNMP name for the interface `label`: Label to display `max`: the maximum bandwidth available through this interface, in bits/s `staticindex`: consider the ifname as the static SNMP index instead of the interface name. It’s not recommanded, but it can be necessary as some OS (Windows among others) assign the same name to different interfaces. `teststate`: Used to deactivate the interface state control. (When you only need statistics.) `warn`: WARNING threshold. See description for the format.
InterrCS	ucd	Check the Interrupts and Context Switches of a host Paramètres acceptés par le test : `crit`: CRITICAL threshold `warn`: WARNING threshold
Load	ucd	Check the load of a host Paramètres acceptés par le test : `crit`: CRITICAL threshold `warn`: WARNING threshold
Metro	Toutes	Set a threshold on metrology values Paramètres acceptés par le test : `crit`: str `metroname`: str `servicename`: str `warn`: str
NagiosPlugin	Toutes	Test générique pour utiliser un plugin Nagios indépendant Paramètres acceptés par le test : `command`: Le nom de la commande à utiliser (check_command) `name`: Le nom du service dans Nagios (service_description)
NTP	Toutes	Check if the NTP service is up
NTPSync	Toutes	Check if a host’s time is synchronized with the NTP server (uses NRPE)
Partition	Toutes	Check if a partition is filling up Paramètres acceptés par le test : `label`: the displayed name for the partition (ex: Data) `max`: total size of the partition `partname`: the SNMP name of the partition (ex: /var) `warn`: WARNING threshold
Ping	Toutes	Check if a host is up with a ping Paramètres acceptés par le test : `crit`: La limite CRITICAL sous la forme d’une liste contenant deux éléments : round_trip_average, packet_loss_percent `warn`: La limite WARNING sous la forme d’une liste contenant deux éléments : round_trip_average, packet_loss_percent
Process	Toutes	Check the number of instances of a process Paramètres acceptés par le test : `label`: the label to display `processname`: the name of the process `section`: the section to search in the SNMP table `warn`: WARNING threshold
Proxy	Toutes	Check if the HTTP proxy works as expected Paramètres acceptés par le test : `auth`: `port`: `url`:
RAID	linux	Check the RAID status of a host
RAM	Toutes ucd	Check the RAM usage of a host Paramètres acceptés par le test : `crit`: CRITICAL threshold (uniquement pour les classes suivantes: ucd) `warn`: WARNING threshold (uniquement pour les classes suivantes: ucd)
SSH	Toutes	Check if the SSH service is up
Swap	Toutes	Graph the swap usage (no supervision test)
TCP	Toutes	Check if the requested TCP port is open Paramètres acceptés par le test : `port`:
TCPConn	Toutes	Check the total number of TCP connections Paramètres acceptés par le test : `crit`: `warn`:
TotalProcesses	Toutes	Check the total number of running processes Paramètres acceptés par le test : `crit`: `warn`:
UpTime	Toutes	Check the SNMP server’s uptime Paramètres acceptés par le test : `crit`: int `warn`: int
Users	Toutes	Check the number of connected users Paramètres acceptés par le test : `crit`: `warn`:

Messages d’erreurs/d’alerte/d’informations¶

Ce chapitre recense les messages d’erreurs les plus courants que vous êtes susceptibles de rencontrer, ainsi que la méthode de résolution de ces problèmes.

VigiConf n’a pas été lancé en utilisant le compte ‘vigiconf’. Abandon.: Afin de garantir la sécurité du système, VigiConf doit être exécuté en tant qu’utilisateur “vigiconf”. Ce message d’erreur s’affiche lorsque cette condition n’est pas remplie et VigiConf refuse de s’exécuter. Le compte “root” peut également être utilisé pour exécuter VigiConf (dans ce cas, l’application commencera par basculer vers le compte “vigiconf” avant de lâcher ses privilèges). L’utilisation du compte “root” pour démarrer VigiConf en production est déconseillée.
VigiConf a été lancé depuis le compte “root” (super-utilisateur). Utilisation du compte ‘vigiconf’ à la place.: Ce message d’avertissement est affiché lorsque VigiConf est exécuté depuis le compte “root”.

Glossaire - Terminologie¶

Ce chapitre recense les différents termes techniques employés dans ce document et donne une brève définition de chacun de ces termes.

XML: eXtensible Markup Language. Langage de balisage extensible.
URL: Uniform Resource Locator. Chaîne de caractères permettant d’identifier une ressource sur Internet.
SGBD: Système de Gestion de Base de Données. Logiciel permettant d’héberger une base de données sur la machine.
SVN: Subversion, système de contrôle de versions. URL : http://subversion.apache.org

Manuel utilisateur¶

Installation¶

Pré-requis logiciels¶

Installation du paquet RPM¶

Configuration¶

Configuration de la base de données¶

Connexion¶

Configuration du dépôt pour le suivi des évolutions¶

Autres options de configuration¶

Répertoire de travail pour la génération¶

Emplacement final de la configuration¶

Répertoire des plugins de VigiConf¶

Emplacement du verrou¶

Mode de simulation des opérations¶

Configuration du parc à superviser¶

Fichiers de configuration XML¶

Configuration des hôtes¶

Définition d’un hôte¶

Balise “class“¶

Balise “template“¶

Balise “attribute“¶

Balise “test“¶

Balise “nagios“¶

Balise “tag“¶

Balise “group“¶

Remarques¶

Configuration des modèles d’hôtes¶

Balise “parent“¶

Balise “attribute“¶

Balise “tag“¶

Balise “group“¶

Balise “class“¶

Balise “test“¶

Balise “nagios“¶

Balise “item“¶

Cas particulier du modèle “default.xml“¶

Dossier “groups“¶

Balise “group“¶

Dossier “hlservices“¶

Configurations particulières¶

Utilisation de SNMPv3¶

Configuration des journaux¶

Configuration des loggers¶

Déclaration d’un logger¶

Configuration d’un logger¶

Exemple de configuration d’un logger¶

Configurations des handlers (gestionnaires d’événements)¶

Déclaration d’un handler¶

Configuration d’un handler¶

Exemple de configuration d’un handler¶

Configuration des formatters¶

Déclaration d’un formatter¶

Configuration d’un formatter¶

Informations contextuelles disponibles pour les formatters¶

Exemple de configuration d’un formatter¶

Exemple de configuration complète des journaux¶

Utilisation de l’utilitaire “vigiconf“¶

Affichage des informations¶

Déploiement de la configuration¶

Découverte des services à superviser sur un hôte¶

Activation / désactivation d’un serveur de supervision¶

Annexes¶

Tests de supervision disponibles dans Vigilo¶

Messages d’erreurs/d’alerte/d’informations¶

Glossaire - Terminologie¶

Balise “`class`“¶

Balise “`template`“¶

Balise “`attribute`“¶

Balise “`test`“¶

Balise “`nagios`“¶

Balise “`tag`“¶

Balise “`group`“¶

Balise “`parent`“¶

Balise “`attribute`“¶

Balise “`tag`“¶

Balise “`group`“¶

Balise “`class`“¶

Balise “`test`“¶

Balise “`nagios`“¶

Balise “`item`“¶

Cas particulier du modèle “`default.xml`“¶

Dossier “`groups`“¶

Balise “`group`“¶

Dossier “`hlservices`“¶

Configuration des `loggers`¶

Déclaration d’un `logger`¶

Configuration d’un `logger`¶

Exemple de configuration d’un `logger`¶

Configurations des `handlers` (gestionnaires d’événements)¶

Déclaration d’un `handler`¶

Configuration d’un `handler`¶

Exemple de configuration d’un `handler`¶

Configuration des `formatters`¶

Déclaration d’un `formatter`¶

Configuration d’un `formatter`¶

Informations contextuelles disponibles pour les `formatters`¶

Exemple de configuration d’un `formatter`¶

Utilisation de l’utilitaire “`vigiconf`“¶