Une des fonctionnalités de Nagios® est de traiter le résultat de contrôles de service soumis par des applications tierces. Les contrôles d'hôtes et de service réalisés par des applications tierces et traités par Nagios® sont appelés contrôles passifs. Ces contrôles sont dits passifs par opposition aux contrôles actifs, qui sont des contrôles d'hotes ou de services réalisés à l'initiative de Nagios®.
Les contrôles passifs sont utiles pour superviser des services qui sont :
Les contrôles passifs d'hôtes et de services sont également utiles dans le cadre d'une supervision répartie.
Les contrôles passifs d'hôte et de service fonctionnent de manière similaire, mais avec d'importantes limitations pour les contrôles passifs d'hôte. Voyez ci-dessous pour plus d'informations sur ces limitations.
La seule réelle différence entre les contrôles actifs et passifs est que les contrôles actifs sont initiés par Nagios®, alors que les contrôles passifs sont réalisés par des applications tierces. Une fois qu'une application tierce 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 envoie le résultat du "contrôle" de service à Nagios® à travers le 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 d'attente pour un traitement ultérieur. C'est la même file 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.
Les applications tierces 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 :
[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<description>;<return_code>;<plugin_output>
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 objets ! Nagios® ignorera tous les résultats de contrôles de service si ceux-ci n'ont pas été configurés avant son dernier (re)démarrage.
Si vous voulez que seuls des résultats passifs soient fournis pour un service particulier (c.-à-d. que les contrôles actifs ne doivent pas avoir lieu), mettez simplement le paramètre active_check_enabled de la définition du service à 0. Ceci empêchera définitivement Nagios® de réaliser un contrôle du service. Assurez vous également que le paramètre passive_check_enabled de la définition du service est à 1, sinon Nagios® ne traitera jamais les contrôles passifs 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.
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 l'addon nsca ici…
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 de service peuvent tous deux être employés pour superviser les 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" sur des hôtes distants (serveur web, serveur FTP, etc.), et pour des ressources "privées" sur des hôtes distants (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.
Les contrôles passifs d'hôte fonctionnent de la même manière que les contrôles passifs de service. Quand une application tierce a réalisé un contrôle d'hôte, elle envoie les résultats de ce "contrôle" d'hôte à Nagios® via le fichier de commandes externes. Quand Nagios® lira le contenu du fichier de commandes externes, il traitera le résultat de contrôle d'hôte qui a été envoyé.
ATTENTION ! Les contrôles d'hôtes passifs ont des limitations. A la différence des contrôles d'hôtes actifs, Nagios® ne tente pas de déterminer si l'hôte est dans l'état DOWN ou UNREACHABLE lors d'un contrôle passif. Nagios® prend plutôt le résultat du contrôle passif comme étant l'état réel de l'hôte, sans essayer de déterminer cet état réel. Au contraire, dans le cas de contrôle d'hôte actif (initié par Nagios®), Nagios® tente de déterminer l'état correct (DOWN ou UNREACHABLE) des hôtes qui ne sont pas dans l'état UP. Cela peut poser des problèmes si vous envoyez des contrôles passifs depuis un hôte distant ou si vous avez une supervision répartie où les relations entre les hôtes parent/enfant sont différentes. Voyez la documentation sur l'accessibilité des hôtes pour de plus amples informations sur la façon dont sont déterminés les états DOWN et UNREACHABLE lors de contrôles actifs d'hôte.
Les applications tierces peuvent envoyer des résultats de contrôles d'hôte à Nagios® en écrivant une commande externe PROCESS_HOST_CHECK_RESULT dans le fichier des commandes externes.
Le format de la commande est le suivant :
[<timestamp>] PROCESS_HOST_CHECK_RESULT;<host_name>;<host_status>;<plugin_output>
où…
Notez que pour envoyer un contrôle d'hôte à Nagios®, l'hôte correspondant doit être défini dans le fichier de configuration des objets ! Nagios® ignorera tous les résultats de contrôles d'hôte si ceux-ci n'ont pas été configurés avant son dernier (re)démarrage.
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®, vous pouvez utiliser 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…