Nagios® propose une fonctionnalité de vérification de la "fraîcheur" des résultats de contrôles d'hôtes et de services. Cette fonctionnalité est utile pour vous assurer que des contrôles passifs sont reçus à la fréquence que vous souhaitez. Bien que le contrôle de fraîcheur puisse être utilisé dans de nombreuses situations, son emploi premier est dans la configuration d'un environnement de supervision réparti.
Le but du contrôle de "fraîcheur" est de s'assurer que les contrôles d'hôte et de service sont soumis régulièrement de manière passive par des applications externes. Si les résultats d'un contrôle d'hôte ou de service (pour lequel vous avez activé le contrôle de fraîcheur) sont considérés comme "périmés", Nagios® forcera un contrôle actif de l'hôte ou du service.
La documentation ci-dessous décrit le contrôle de fraîcheur de service. Le contrôle de fraîcheur d'hôte (qui n'est pas documenté individuellement) fonctionne de manière similaire au contrôle de fraîcheur de service - à part évidemment qu'il se rapporte à la fraîcheur des hôtes et pas à celle des services. Si vous souhaitez configurer le contrôle de fraîcheur d'hôte, adaptez les instructions ci-dessous.
Avant de paramètrer le seuil de fraîcheur de chaque service, vous devez activer le contrôle de fraîcheur par les paramètres check_service_freshness et freshness_check_interval du fichier de configuration principal. Si vous deviez configurer le contrôle de fraîcheur d'hôte, vous utiliseriez les paramètres check_host_freshness et host_freshness_check_interval.
Maintenant, comment activer le contrôle de fraîcheur d'un service en particulier ? Vous devez configurer la définition de service comme suit.
Nagios® contrôle régulièrement la "fraîcheur" des résultats de tous les services dont le contrôle de fraîcheur est activé. Le paramètre freshness_threshold de la définition de chaque service permet de déterminer quelle "fraîcheur" ces résultats doivent présenter. Par exemple, si vous donnez la valeur 60 au paramètre freshness_threshold de l'un de vos services, Nagios® considérera que le service est "périmé" si ses resultats sont âgés de plus de 60 secondes (1 minute). Si vous ne spécifiez pas de valeur pour le paramètre freshness_threshold (ou si vous le mettez à zéro), Nagios® calculera automatiquement un seuil de "fraîcheur" à utiliser en se basant soit sur le paramètre normal_check_interval soit sur retry_check_interval (selon le type d'état dans lequel se trouve le service actuellement).
Si le résultat d'un contrôle de service devient "périmé" (selon la définition ci-dessus), Nagios® forcera un contrôle actif du service en exécutant la commande spécifiée par le paramètre check_command de la définition du service. Il est important de noter qu'un contrôle de service actif déclenché parce que le service est vu comme "périmé" sera exécuté même si les contrôles actifs de service sont désactivés de manière globale ou pour le service en particulier.
Comme je l'ai déjà dit, le contrôle de fraîcheur est surtout utile pour les services dont les résultats sont issus d'un contrôle passif. Il se peut bien souvent (comme dans le cas d'une supervision répartie) que ces services ne reçoivent pas tous les résultats de leur contrôle passif - aucun résultat n'étant obtenu par contrôle actif.
Un exemple de service purement passif pourrait être un rapport d'état de vos travaux de sauvegarde de nuit. Vous avez peut-être un script externe qui soumet les résultats du travail de sauvegarde à Nagios® une fois que la sauvegarde est terminée. Dans ce cas, tous les résultats des contrôles pour ce service sont fournis par une application externe, en utilisant des contrôles passifs. Pour vous assurer que l'état des travaux de sauvegarde est bien remonté chaque jour, vous activerez le contrôle de fraîcheur pour ce service. Si le script externe ne soumet pas les resultats du travail de sauvegarde, vous pouvez faire en sorte que Nagios® simule un résultat "critical" de la manière suivante…
Voici ce à quoi la définition du service pourrait ressembler (certains paramètres obligatoires ont été omis)…
define service{
host_name backup-server
service_description ArcServe Backup Job
active_checks_enabled 0 ; active checks are NOT enabled
passive_checks_enabled 1 ; passive checks are enabled (this is how results are reported)
check_freshness 1
freshness_threshold 93600 ; 26 hour threshold, since backups may not always finish at the same time
check_command no-backup-report ; this command is run only if the service results are "stale"
…other options…
}
Notez que les contrôles actifs sont désactivés pour ce service. En effet les résultats du service sont uniquement fournis par une application externe, en utilisant des contrôles passifs. Le contrôle de fraîcheur est activé et le seuil de fraîcheur a été positionné à 26 heures. C'est un peu plus de 24 heures parce que la durée des travaux de sauvegarde varie selon les jours (en fonction du volume de données à sauvegarder, de l'encombrement du réseau, etc.). La commande no-backup-report est exécutée seulement si les résultats du service sont considérés comme "périmés". La définition de la commande no-backup-report pourrait ressembler à ceci…
define command{
command_name no-backup-report
command_line /usr/local/nagios/libexec/nobackupreport.sh
}
Le script nobackupreport.sh dans votre répertoire /usr/local/nagios/libexec pourait ressembler à ceci :
#!/bin/sh /bin/echo "CRITICAL: Results of backup job were not reported!" exit 2
Si Nagios® détecte que les résultats du service sont périmés, il lancera la commande no-backup-report comme un contrôle actif de service (même si les contrôles actifs sont désactivés pour ce service - rappelez-vous que nous sommes dans un cas particulier). Cela lance le script /usr/local/nagios/libexec/nobackupreport.sh, qui retourne un état "critical". Le service passe en état "critical" (s'il n'y était pas déjà) et quelqu'un sera probablement notifié du problème.