A la différence de beaucoup d'autres outils de supervision, Nagios® ne dispose pas de mécanisme interne pour vérifier l'état d'un service, d'un hôte, etc. A la place, il utilise des programmes externes (appelés plugins) pour faire le "sale boulot". Nagios® exécutera un plugin dès qu'il a besoin de vérifier un service ou un hôte supervisé. Le plugin fait quelque chose (remarquez ce terme très général) pour exécuter le contrôle et simplement renvoyer le résultat à Nagios®. Nagios® analysera le résultat provenant du plugin et prendra les mesures nécessaires (lancer les gestionnaires d'événements, envoyer des notifications, etc).
L'image ci-dessous montre comment les plugins sont séparés du coeur logique de Nagios®. Nagios® exécute les plugins qui vérifient ensuite des services ou des ressources locales ou distantes. Lorsque les plugins ont fini de vérifier la ressource ou le service, ils transmettent simplement le résultat de la vérification à Nagios®. Un schéma plus complexe sur la façon de travailler des plugins se trouve dans la documentation à la page des contrôles de services passifs.
Grâce à cette architecture, vous pouvez contrôler n'importe quoi, du moment que vous y pensez. Si vous pouvez automatiser le processus de contrôle de quelque chose, vous pouvez le superviser avec Nagios®. Il existe déjà beaucoup de plugins crées pour superviser les ressources basiques telles que : la charge du processeur, l'espace d'un disque dur, les réponses aux pings, etc. Si vous voulez superviser quelque chose d'autre, regardez la documentation sur la page comment écrire ses plugins et lancez vous !
Le seul réel inconvénient à cette architecture de plugin est le fait que Nagios® n'a absolument aucune idée de ce que vous supervisez. Vous pouvez très bien superviser des statistiques de trafic réseau, des taux d'erreur, la température d'une pièce, la tension du CPU, la vitesse des ventilateurs, la charge du processeur, l'espace disque, ou la capacité de votre fantastique toaster a bien griller votre pain pour le matin… Nagios® ne peut pas créer des graphes des ressources que vous supervisez. Il peut seulement suivre les changements d'état de ces ressources. Seul les plugins savent exactement ce qu'ils supervisent et comment ils réalisent les vérifications. Cependant les plugins peuvent retourner optionnellement des informations de performances liés aux données en même temps que l'état. Ces information peuvent être ensuite passées à une application externe qui peut créer des graphes des services (i.e. utilisation des espaces disques, charge du processeur, etc.). Vous trouverez plus d'informations à ce sujet ici.
La corrélation entre les plugins et les contrôles de services devrait être évidente. Quand Nagios® a besoin de vérifier l’état d'un service que vous avez défini, il exécutera le plugin spécifié dans l'argument <check_command> de la définition du service. Le plugin vérifiera l’état du service ou de la ressource et retournera le résultat à Nagios®.
L'utilisation des plugins pour vérifier les états d'un hôte peut être un peu plus difficile à comprendre. Dans chaque définition d'hôte vous utilisez l'argument <host_check_command> pour spécifier un plugin qui devra être utilisé pour vérifier l'état de l'hôte. Les contrôles des hôtes ne sont pas effectués régulièrement : ils sont exécutés uniquement au besoin, typiquement lorsqu'il il y a des problèmes avec un ou plusieurs services associes à l'hôte.
Les contrôles des hôtes peuvent s'effectuer avec les mêmes plugins que les contrôles des services. La seule réelle différence entre les deux types de contrôles est l'interprétation des résultats du plugin. Si le résultat d'un plugin utilisé pour le contrôle d'un hôte est un état différent de OK, alors Nagios® croira que l'hôte n'est pas actif.
Dans la plupart des cas, vous voudrez utiliser un plugin permettant de contrôler si l'hôte est répond à une requête ICMP (i.e. il répond au "ping") car c'est la méthode la plus courante pour savoir si un hôte est actif ou non. Cependant, si vous supervisez un super grille pain, vous pourriez vouloir utiliser un plugin [NdT : check_paing :-) ? ] afin de contrôler si les résistances fonctionnent lorsqu'on abaisse la manette. Cela donnerait une bonne indication de l'état du grille-pain, 'vivant' ou non.