Guide d’administration

Installation

Pré-requis logiciels

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

  • python (>= 2.5), sur la machine où le connecteur est installé
  • rabbitmq (>= 2.7.1), éventuellement sur une machine distante
  • postgresql-server (>= 8.3), éventuellement sur une machine distante

Création du compte sur le bus

Le connecteur FTP nécessite qu’un compte soit créé sur la machine hébergeant le bus. Les comptes doivent être créés sur la machine qui héberge le serveur rabbitmq, à l’aide de la commande:

# rabbitmqctl add_user nom_d_utilisateur mot_de_passe

Configuration

Le module |name| est fourni avec un fichier de configuration situé par défaut dans « /etc/vigilo/|name|/settings.ini ».

Ce fichier est composé de différentes sections permettant de paramétrer des aspects divers du module, chacune de ces sections peut contenir un ensemble de valeurs sous la forme clé = valeur. Les lignes commençant par « ; » ou « # » sont des commentaires et sont par conséquent ignorées.

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

# Ceci est un commentaire
; Ceci est également un commentaire
[section1]
option1=valeur1
option2=valeur2
; ...

[section2]
option1=val1
; ...

Les sections utilisées par le connecteur et leur rôle sont détaillées ci-dessous:

bus
Contient les options relatives à la configuration de l’accès au bus de messages.
connector
Contient les options de configuration génériques d’un connecteur de Vigilo.
publications
Contient une liste d’associations entre les types de messages envoyés et les nœuds de publication (exchange) vers lesquels ces messages sont transmis. Un paramètre optionnel permet de définir une durée de vie en secondes pour les messages (si un message passe plus de temps que sa durée de vie dans la file d’attente sans être consommé, il est automatiquement supprimé de la file d’attente).
loggers, handlers, formatters, logger_*, handler_*, formatter_*

Contient la configuration du mécanisme de journalisation des événements (voir chapitre Journaux).

« * » correspond au nom d’un logger/handler/formatter défini dans la section loggers, handlers ou formatters (respectivement).

connector-syncevents
Contient les options spécifiques au connecteur syncevents.
database
Contient les options relatives à la connexion à la base de données de Vigilo.

Connexion au bus de messages

Le connecteur utilise un bus de communication basé sur le protocole AMQP pour communiquer avec les autres connecteurs de Vigilo.

Ce chapitre décrit les différentes options de configuration se rapportant à la connexion à ce bus de communication, situées dans la section [bus] du fichier de configuration.

Trace des messages

L’option « log_traffic » est un booléen permettant d’afficher tous les messages échangés avec le bus lorsqu’il est positionné à « True ». Cette option génère un volume d’événements de journalisation très important et n’est donc pas conseillée en production.

Adresse du bus

L’option « host » permet d’indiquer le nom ou l’adresse IP de l’hôte sur lequel le bus fonctionne.

Service de publication

Le connecteur utilise les mécanismes de publication de messages du protocole AMQP pour échanger des informations avec les autres connecteurs de Vigilo.

Ces mécanismes nécessites de spécifier le nom du service de publication utilisé pour l’échange de messages sur le bus, appelé exchange. Par défaut, le nom de ce service est le nom du type de message à envoyer.

Identifiant

Chaque connecteur de Vigilo est associé à un compte AMQP différent. L’option « user » permet d’indiquer le nom de ce compte.

Mot de passe

L’option « password » permet de spécifier le mot de passe associé au compte AMQP indiqué dans l’option « user ».

Connexions sécurisées

Les connecteurs ont la possibilité de spécifier la politique de sécurité à appliquer pour les connexions avec le bus. Il est possible de forcer l’utilisation d’une connexion chiffrée entre le connecteur et le bus en positionnant l’option « require_ssl » à « True ». Le port de connexion utilisé par défaut sans SSL est le 5672, avec SSL il devient le 5671.

Délai maximum de reconnexion

En cas de déconnexion du bus, les connecteurs se reconnectent automatiquement, selon un délai qui augmente exponentiellement (afin d’éviter d’innonder les journaux système avec des messages annonçant la reconnexion).

L’option « max_reconnect_delay » permet d’indiquer le délai maximum (en secondes) qui peut s’écouler entre 2 tentatives de reconnexion. Par défaut, ce délai est fixé à 60 secondes.

File d’attente

L’option « queue » permet de spécifier le nom de la file d’attente AMQP à laquelle se connecter pour recevoir les messages. Si plusieurs connecteurs spécifient la même file d’attente, il en consommeront les messages au fur et à mesure de leur capacité de traitement (mode « répartition de charge »).

Abonnements

L’option « subscriptions » contient la liste des nœuds de publication auxquels le connecteur est abonné (séparés par des virgules). Plus exactement, il s’agit des nœuds de publication auxquels la file d’attente spécifiée par l’option « queue » est abonnée. La valeur configurée par défaut lors de l’installation du connecteur convient généralement à tous les types d’usage.

Attention, il est possible d’ajouter des abonnements dans cette liste, mais les abonnements existants ne seront pas supprimés automatiquement s’ils sont supprimés de la liste (il s’agit d’une limitation actuelle du protocole). Pour cela, il faut passer soit par l’interface de gestion du serveur, soit par la commande vigilo-config-bus.

État du connecteur

Les connecteurs de Vigilo sont capables de s’auto-superviser, c’est-à-dire que des alertes peuvent être émises par Vigilo concernant ses propres connecteurs lorsque le fonctionnement de ceux-ci est perturbé ou en défaut.

Ce mécanisme est rendu possible grâce à un signal de vie émis (un état Nagios) par chaque connecteur à intervalle régulier. Chaque signal de vie correspond à un message de type « nagios ».

L’option « status_service » permet de spécifier le nom du service Nagios par lequel on supervise ce connecteur.

Des données de performance sont également générées afin d’alimenter les graphiques de métrologie des différents connecteurs. Chaque donnée de performance correspond à un message de type « perf ».

Les options « self_monitoring_nagios_exchange » et « self_monitoring_perf_exchange » permettent de choisir les nœuds de publication vers lesquels les messages d’état Nagios et de performance du connecteur sont envoyés, respectivement. Dans le cas où cette option ne serait pas renseignée, les nœuds configurés dans la section [publication] sont utilisés pour déterminer la destination des messages. Si aucun nœud n’est configuré pour l’envoi des messages d’état Nagios ou de performance, un message d’erreur est enregistré dans les journaux d’événements.

Destination des messages

Le connecteur envoie des messages au bus contenant des informations sur l’état des éléments du parc, ainsi que des données de métrologie permettant d’évaluer la performance des équipements. Chaque message transmis par le connecteur possède un type.

La section [publications] permet d’associer le type des messages à un nœud de publication. Ainsi, chaque fois qu’un message doit être transmis au bus, le connecteur consulte cette liste d’associations afin de connaître le nom du nœud sur lequel il doit publier son message.

Les types de messages supportés par un connecteur sont :

  • perf : messages de performances
  • state : messages d’état
  • event : messages d’événements
  • nagios : commandes Nagios
  • command : commandes diverses

Si aucune destination n’est renseignée, le message sera envoyé sur un nœud du même nom que le type du message.

Exemple de configuration possible, correspondant à une installation standard :

[publications]
perf   = perf
state  = state
event  = event
nagios = nagios

Journaux

Le connecteur 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.).

Le document Vigilo - Journaux d’événements décrit spécifiquement la configuration de la journalisation des événements au sein de toutes les applications de Vigilo, y compris les connecteurs.

Configuration spécifique au connecteur syncevents

Le connecteur syncevents dispose de quelques options de configuration spécifiques, détaillées ci-dessous.

Seuils pour l’envoi des demandes d’état

L’option minutes_old détermine l’âge minimum (en minutes) d’une alerte ou d’un état portant sur un hôte ou un service de bas niveau au-dessus duquel on demande une mise à jour à Nagios.

Nagios est configuré pour ré-émettre des notifications toutes les 30 minutes pour les hôtes et les services de bas niveau. Il faut donc régler ici une valeur légèrement supérieure, pour ne cibler que les états désynchronisés.

Une valeur négative désactive cette resynchronisation. La valeur par défaut est 45 minutes.

Avertissement

Cette valeur doit être cohérente avec la fréquence des réémissions de notifications configurées dans Nagios pour les alertes sur les hôtes et les services de bas niveau.

L’option hls_minutes_old détermine l’âge minimum d’un état (en minutes) portant sur un service de haut niveau au-dessus duquel on demande une mise à jour à Nagios. Elle sert également à initialiser les services de haut niveau plus rapidement, en contrepartie d’une dégradation des performances générales de Vigilo.

Nagios est configuré pour ré-émettre des notifications toutes les 30 minutes pour les services de haut niveau. Il faut donc régler ici une valeur légèrement supérieure, pour ne cibler que les états désynchronisés.

Une valeur négative désactive cette resynchronisation. La valeur par défaut est -1 (ie. la resynchronisation est désactivée).

Avertissement

Si la resynchronisation des services de haut niveau est souhaitée, cette valeur doit être cohérente avec la fréquence des réémissions de notifications configurées dans Nagios pour les alertes sur les services de haut niveau.

Emplacement du fichier de verrou

Un fichier de verrou est créé par le connector-syncevents afin d’empêcher l’exécution simultanée de plusieurs instances du connecteur.

L’option lockfile peut être utilisée pour spécifier l’emplacement du fichier de verrou à créer. L’emplacement par défaut de ce fichier de verrou est /var/lock/subsys/vigilo-connector-syncevents/lock.

Limite sur le nombre de demandes d’état

L’option max_events permet de limiter le nombre de demandes de réémission d’état qui peuvent être envoyées à Nagios au cours d’une exécution du connecteur syncevents.

Cette option est particulièrement utile afin d’empêcher une inondation du bus de communication de Vigilo sur un parc de grande taille lorsqu’un incident majeur survient sur la plate-forme de supervision (par exemple : collecteur qui ne répond plus).

Si cette option n’est pas renseignée, aucune limite n’est imposée sur le nombre de demandes de réémission d’état qui peuvent être envoyées à Nagios au cours de la même exécution.

Utilisation

Lancement du composant

Le composant connector-syncevents est construit de sorte qu’une fois lancé, il liste les états qui semblent désynchronisés en base de données, et envoie des messages à Nagios pour qu’il ré-expédie les notifications sur ces états. Les données transmises sont précisées au chapitre .

S’il n’y a pas d’état à synchroniser, le connecteur s’arrête sans se connecter au bus. Le lancement se fait en exécutant la commande .

Activation régulière

Il est recommandé de planifier l’exécution de la commande à intervalles réguliers (par exemple, toutes les 10 minutes) afin d’effectuer des re-synchronisations assez fréquemment. Grâce à la limite d’âge configurée, seuls les événements qui semblent dé-synchronisés seront sélectionnés. Il y a donc peu d’impact à réaliser cette vérification assez fréquemment (seule une requête SQL est effectuée). Une bonne pratique consiste à exécuter périodiquement cette commande à l’aide d’un planificateur de tâches comme cron.

Le listing suivant donne un exemple de configuration utilisant cron:

# minutes heures n°jour mois jour commande > journal
# Exécution de la commande de synchronisation.
*/10 * * * * vigilo-syncevents /usr/bin/vigilo-connector-syncevents >/dev/null

Cette commande doit être lancée soit en tant que l’utilisateur « vigilo-syncevents », soit en tant que « root », pour avoir accès à son fichier settings.ini. Il est recommandé de ne pas utiliser « root », mais de lui préférer l’utilisateur dédié.

À l’installation, le connecteur installe cette tâche planifiée dans cron, mais la laisse désactivée. Pour l’activer, il suffit de dé-commenter l’entrée dans le fichier /etc/cron.d/vigilo-connector-syncevents.

Nature des informations transmises

Le connecteur syncevents envoie des messages contenant des commandes qui seront récupérées par le connector-nagios, puis transmises à Nagios après avoir été converties en utilisant la syntaxe adéquate.

Ce messages sont des demandes de ré-émission de notification, définis dans la documentation Nagios aux URL suivantes :

Pour circuler sur le bus, ces demandes sont encodées dans un message Vigilo de type « command », dont un exemple suit :

{ "type": "nagios",
  "cmdname": "SEND_CUSTOM_SVC_NOTIFICATION",
  "value": "server.example.com;Load 01;0;vigilo;syncevents",
}

Après réception par Nagios, ce dernier va ré-expédier une notification de l’état de l’hôte ou du service concerné, qui suivra le chemin classique des notifications dans Vigilo : elle sera réceptionnée par le corrélateur, qui mettra à jour l’état dans la base Vigilo.

Annexes

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.

AMQP
Advanced Message Queuing Protocol. Protocole ouvert de messagerie applicative. Voir amqp.org.
exchange
Nœud de publication dans le dialecte AMQP. Les messages publiés sur un exchange sont relayés à une ou plusieurs files d’attente sur le serveur, à partir desquelles les connecteurs vont consommer les messages.
inotify
L’outil inotify est un mécanisme du noyau Linux qui fournit des notifications concernant le système de fichiers lorsqu’un événement particulier se produit (par exemple, la fermeture d’un fichier).
JSON
JavaScript Object Notation. Méthode de sérialisation textuelle compatible JavaScript.
RRD
Round-Robin Database. Base de données circulaire permettant de stocker des données disposant d’une granularité différente.
SGBD
Système de Gestion de Base de Données. Logiciel permettant d’héberger une base de données sur la machine.
URL
Uniform Resource Locator. Chaîne de caractères permettant d’identifier une ressource sur Internet.
XML
eXtensible Markup Language. Langage de balisage extensible.