====== Supervision Nagios ======
===== Nagios Core =====
==== Supervision de logs ====
La supervision de logs est considéré comme un service, mais un peu particulier...\\
En effet, Nagios utilise la notion de d'état **SOFT** ou **HARD** pour les services ou les hosts, ce qui permet de limiter les effets de faux positif. Un fonctionnement intéressant pour gérer les aléas du réseau, pour temporiser sur des changements furtif de statut. En ''SOFT'' ou en ''HARD'', l'alarme apparaît sur l'interface Nagios, mais la notification n'est effectif que sur des états ''HARD''.\\
Or, dans le cas de la supervision de log, ce fonctionnement n'est pas souhaitable, car l’événement va apparaître à un instant T, sera détecté par Nagios déclenchera un état ''SOFT'', puis au prochain check, si on n'a pas eut de nouvelles occurrences, le service reprendra son état OK.\\
Donc à moins d'être collé devant l'écran de supervision en permanence ou de lire le log statut nagios régulièrement, on n'aura pas connaissance de cette alarme, car il n'y aura **pas de notifications**.\\

☛ L'idée pour palier à cette problématique, c'est tout simplement de désactiver cet état SOFT en configurant le paramètre ''max_check_attempts'' à **1** (pour les services), par exemple :
<code bash>
# SVG : Sauvegarde serveur
define service{
        use                             service-1d           ; Name of service template to use
        hostgroup_name                  grp-localhost
        service_description             SVG Serveur
        check_command                   check_file_age!/var/back/log/sauvegarde.log!2592000!7776000!0!0
        max_check_attempts              1                    ; Pour désactiver l'etat SOFT pour ce type de service
        }
</code>

==== Gestion du Flapping ====
FIXME : Problématique de certains checks pour les lesquels on ne les vérifie que toutes les heures ou 24h... Le flapping n'est pas intéressant dans ce cas là. A compléter