Introduction
Une des fonctionnalités de Nagios permet de traiter le résultat de contrôles de service soumis par des applications tierces. Les contrôles de service réalisés par des applications tierces et traités par Nagios sont appelés contrôles passifs. Les contrôles sont dits passifs par opposition aux contrôles actifs, qui ont été réalisés à l'initiative de Nagios.
Des contrôles passifs pour quoi faire?
Les contrôles passifs sont utiles pour superviser des services qui sont :
Comment les contrôles passifs fonctionnent-ils ?
La seule réelle différence entre les contrôles actifs et passifs est que les contrôles actifs sont activés par Nagios, alors que les contrôles passifs sont réalisés par des applications externes. Une fois qu'une application externe a réalisé un contrôle de service (que ce soit activement ou en ayant reçu un événement asynchrone comme un trap SNMP ou une alerte de sécurité), elle soumet le résultat à Nagios à travers un fichier de commande externe.
Lorsque Nagios traite le contenu du fichier de commande externe, il place les résultats de tous les contrôles passifs de service dans une file pour traitement ultérieur. C'est la même file d'attente qui est utilisée pour stocker les résultats des contrôles actifs et passifs.
Nagios exécute régulièrement un événement de consolidation des services et lit le contenu de la file de résultat des contrôles. Chaque résultat de contrôle de service, qu'il soit actif ou passif, est traité de la même façon. L'algorithme de contrôle de service est exactement le même pour les deux types de contrôles. Ceci permet d'appliquer une seule méthode pour la gestion des résultats de contrôles actifs et passifs.
Comment les applications tierces soumettent-elles le résultat des contrôles de service ?
Les applications externes peuvent soumettre les résultats de contrôles de service à Nagios en écrivant une commande externe PROCESS_SERVICE_CHECK_RESULT dans le fichier de commandes externes.
Le format de la commande est le suivant :
[<date_heure>] PROCESS_SERVICE_CHECK_RESULT;<nom_hôte>;<description>;<code_retour>;<affichage_plugin>
où...
Notez que pour soumettre des contrôles de service à Nagios, un service doit avoir été défini préalablement dans le fichier de configuration des hôtes ! Nagios ignorera tous les résultats de contrôles de services qui n'ont pas été configurés avant son dernier (re)démarrage.
Si vous voulez que des résultats passifs soient fournis pour un service particulier seulement (i.e. les contrôles actifs ne doivent pas avoir lieu), mettez simplement le paramétre active_check_enabled de la définition à 0. Ceci empêchera totalement ( et à jamais) Nagios de réaliser un contrôle du service. Assurez vous également que le paramètre passive_check_enabled est à 1, sinon Nagios ne fera jamais de contrôle passif pour ce service.
Vous pouvez trouver un exemple de script Shell sur la façon de soumettre des résultats de contrôles passifs de services à Nagios dans la documentation sur les services volatils.
Soumission de résultats de contrôles passifs de services depuis des hôtes distants
Si l'application qui soumet les résultats de contrôles passifs se trouve sur le même hôte que Nagios, elle peut directement écrire ces résultats dans le fichier de commandes externes comme décrit ci-dessus. Mais les applications se trouvant sur des hôtes distants ne peuvent pas le faire aussi simplement. Pour que des hôtes distants puissent envoyer des résultats de contrôles passifs à l'hôte sur lequel tourne Nagios, j'ai développé l'addon nsca. Cet addon consiste en un démon qui tourne sur l'hôte de Nagios et un client exécuté sur les hôtes distants. Le démon attend les connexions des clients distants, valide sommairement les résultats soumis, et les écrit directement dans le fichier de commandes externe (de la manière décrite ci-dessus). Vous trouverez plus d'information sur le addon nsca ici...
Utilisation commune des contrôles actifs et passifs
A moins que vous n'implémentiez un environnement de supervision répartie avec un serveur central n'acceptant que les contrôles passifs (et ne réalisant aucun contrôle actif), vous utiliserez probablement les deux types de contrôles. Comme je l'ai déjà dit, les contrôles actifs sont plus adaptés aux services qui se prêtent au contrôle régulier (disponibilité d'un serveur FTP ou web, etc.), alors que les contrôles passifs conviennent mieux pour gérer des événement asynchrones survenant à des fréquences variables (alertes de sécurité, etc.).
L'image ci-dessous donne une représentation visuelle de la façon dont les contrôles actifs et passifs peuvent tous deux être employés pour superviser des ressources du réseau (cliquez sur l'image pour la voir en grand format).
Les patatoïdes oranges à droite de l'image sont des applications tierces qui soumettent des résultats de contrôles passifs dans le fichier de commandes externes de Nagios. Une des applications se trouve sur le même hôte que Nagios, ce qui fait qu'elle peut écrire directement dans ce fichier. L'autre application se trouve sur un hôte distant et se sert du client et du démon nsca pour transférer les résultats de contrôles passifs à Nagios.
Les éléments à gauche de l'image représentent des contrôles actifs de services que Nagios réalise. J'ai montré comment les contrôles peuvent être réalisés pour des ressources locales (utilisation du disque, etc.), pour des ressources "publiques" [exposed] sur des hôtes distants (serveur web, serveur FTP, etc.), et pour des ressources "privées" [private] sur des hôtes disants (utilisation du disque de l'hôte distant, charge du processeur, etc.). Dans cet exemple, les ressources privées des hôtes distants sont en fait contrôlées grâce à l'addon nrpe, qui facilite l'exécution de plugins sur les hôtes distants.