Chapitre 31. Les contrôles passifs

Table des matières

Introduction

Dans la plus part des cas, vous utilisez Nagios pour réaliser des contrôles actifs. Les contrôles actifs sont utilisés pour prélever les informations sur le statut d'une machine aussi souvent que possible. Nagios possède un autre moyen de contrôle, celui dit passif. Les attraits des contrôles passifs sont les suivants:

  • Les contrôles passifs sont lancés et exécutés par des applications externes

  • Les résultats des contrôles passifs sont soumis à Nagios pour traitement

La différence majeure entre les contrôles actifs et passifs; Dans le cas des actifs, c'est Nagios qui lance et exécute les contrôles alors que dans le cas des passifs, cet acheminement est géré par une application externe.

L'utilité du contrôle passif

Les contrôles passifs sont utiles pour superviser des services qui sont:

  • Asynchrones par nature et ne peuvent donc pas être contrôlés activement de manière fiable (p.ex. les interruptions SNMP, les alertes de sécurité, etc.)

  • Situés derrière un firewall, et ne peuvent donc pas être contrôlés depuis l'hôte supportant Nagios

Les exemples de services asynchrones qui se prêtent à être contrôlés passivement incluent les interruptions SNMP et alertes de sécurité. Vous ne savez jamais à quels moment une faille de sécurité peut être franchie, donc il n'est pas réalisable de contrôler leur statut toutes les deux ou trois minutes.

Les contrôles passifs sont aussi utilisés lors d'installation de supervision distribuée ou redondante

Comment les contrôles passifs fonctionnent-ils ?

Passive Checks

Ci-dessous, le fonctionnement des contrôles passifs en plus détaillé :

  1. Une application externe contrôle l'état d'un hôte ou un service.

  2. L'application externe écrit le résultat du contrôle dans le fichier des commandes externes.

  3. Ensuite, Nagios lit ce fichier et place les résultats dans une queue pour les traiter plus tard. Cette même queue est utilisée pour aussi bien stocker les résultats des contrôles actifs que passifs.

  4. Nagios va exécuter périodiquement un événement collecteur de résultat et scanner la queue. Chaque résultat de services trouvé est traité de la même manière qu'il soit actif ou passif. Nagios enverra les notifications, alertes de log, etc. en fonction du résultat des contrôles.

Le principe des contrôles actifs et passifs est similairement le même. Cela tient en compte de l'intégration de l'information des états à partir d'applications externes avec Nagios.

Autoriser les contrôles passifs

Dans l'odre, pour autoriser le contrôle passifs dans Nagios, Il faut procéder de la manière suivante:

  • Passer le paramètre accept_passive_service_checks à 1.

  • Passer dans la définition des hôtes et des services le paramètre passive_checks_enabled à 1

Si vous voulez désactiver globalement le contrôle passifs, passer le paramètre accept_passive_service_checks à 0.

Si vous voulez désactiver les contrôles passifs pour quelques services ou hôtes, utilisez le paramètre passive_checks_enabled dans votre définition d'hôte et/ou service.

Soumission d'un résultat de contrôle passif

Les applications externes peuvent soumettre à Nagios des résultats de contrôles passifs en écrivant une commande externe PROCESS_SERVICE_CHECK_RESULT dans le fichier de commande externe.

Le format de la commande ressemble à ce qui suit:


[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<svc_description>;<return_code>;<plugin_output>
        

où :

  • timestamp est le temps au format time_t (secondes écoulée depuis le commencement UNIX) que le contrôle de service génère (ou soumet). Notez bien le simple espace juste après la parenthèse.

  • host_name est l'alias de l'hôte associé avec le service dans la définition de service

  • svc_description est la description de service spécifiée dans la définition de service

  • return_code est le code de retour d'un contrôle (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN)

  • plugin_output est le texte de sortie d'un contrôle de service

Un service doit être défini dans Nagios avant de lui soumettre un contrôle passif! Nagios ignorera tous les résultats de contrôles pour les services qui n'ont pas été configuré avant son dernier (re)démarrage.

Un exemple de script shell sur comment soumettre un contrôle passif de service à Nagios se trouve dans la documentation des services volatiles .

Soumission d'un résultat de contrôle passif d'un hôte

Les applications externes peuvent soumettre à Nagios des résultats de contrôles passifs en écrivant une commande externe PROCESS_HOST_CHECK_RESULT dans le fichier de commande externe.

Le format de la commande ressemble à ce qui suit:


[<timestamp>]PROCESS_HOST_CHECK_RESULT;<host_name>;<host_status>;<plugin_output>
    

où :

  • timestamp est le temps au format time_t (secondes écoulée depuis le commencement UNIX) que le contrôle de service génère (ou soumet). Notez bien le simple espace juste après la parenthèse.

  • host_name est l'alias correspondant à l'hôte (défini dans la définition de l'hôte)

  • host_status est l'état de l'hôte (0=UP, 1=DOWN, 2=UNREACHABLE)

  • plugin_output est le texte de sortie du contrôle de l'hôte

Un hôte doit être défini dans Nagios avant de lui soumettre un contrôle passif! Nagios ignorera tous les résultats de contrôles pour les hôtes qui n'ont pas été configurés avant son dernier (re)démarrage.

Les contrôles passifs et les états d'hôtes

À la différence des contrôles actifs d'hôte, Nagios n'essaie pas (par défaut) de déterminer si l'hôte est DOWN ou UNREACHABLE avec le contrôle passif. Plutôt, Nagios prend le résultat du contrôle passif comme l'état réel dans lequel l'hôte est et n'essaie pas de déterminer que l'état réel de l'hôte en utilisant la logique d'accessibilité. Ceci peut causer des problèmes si vous soumettez un contrôle passif provenant d'un hôte distant ou vous avez une supervision dite distribuée dans laquelle vous avez des liens d'hôtes père/fils complexes.

Vous pouvez dire à Nagios de traduire un résultat de contrôle passif DOWN/UNREACHABLE par votre propre état en utilisant la variable translate_passive_host_checks . Vous trouverez plus d'informations sur son fonctionnement ici.

Les contrôles passifs des hôtes sont normalement traités en états HARD, à moins que l'option passive_host_checks_are_soft soit activée.

Soumission des résultats de contrôles passifs provenant d'hôtes distants

NSCA

Si une application demeurant sur le même serveur que Nagios veut envoyer un résultat de contrôle passif d'hôte ou de service, vous pouvez simplement écrire en mode append directement dans le fichier de commandes externes. Contrairement, une application sur un hôte distant ne peut pas le faire aussi simplement.

Pour permettre aux hôtes distants d'envoyer leurs résultats de contrôles passifs au serveur de supervision, j'ai développé un agent du nom NSCA. L'agent NSCA se compose d'un démon tournant sur le serveur Nagios et un client qui est exécuté par les hôtes distants. Le démon écoutera toutes les connexions des hôtes distants, exécutera quelques validations fondamentales sur les résultats lui étant soumis et écrira ensuite les résultats des contrôles directement dans le fichier de commandes externes (comme décrit au-dessus). Plus de renseignements sur l'agent NSCA peuvent être trouvés ici.