Introduction

Les périodes vous permettent une meilleure maîtrise sur le moment où les contrôles de service peuvent être lancés, celui où les notifications d'hôtes et de services peuvent être envoyées, et celui où les contacts peuvent recevoir les notifications. Cette nouvelle fonctionnalité amène son lot de problèmes potentiels, comme je l'expliquerai plus loin. J'ai été très réticent à l'origine à introduire les périodes à cause de ces "snafus" [NdT : acronyme de Situation Normal All Fucked Up, qui peut se traduire par : La situation est complètement normale, puisque tout le système est par terre ]. Je vous laisse décider de ce qui est bon dans votre propre cas...

Comment les périodes fonctionnent pour les contrôles de service

Sans l'implémentation des périodes, Nagios superviserait tous les services que vous auriez défini 24 heures sur 24, 7 jours sur 7. Bien que cela convienne à la plupart des services à superviser, cela ne fonctionne pas si bien pour certains. Par exemple, avez-vous vraiment besoin de superviser les imprimantes en permanence alors qu'elles sont réellement utilisées uniquement durant les heures de bureau ? Peut-être avez-vous des serveurs de développement dont vous préféreriez qu'ils soient en fonctionnement, mais qui ne sont pas "critiques" et qui n'ont donc pas besoin d'être contrôlés pendant le weekend. Les définitions de périodes vous permettent maintenant de mieux maîtriser les horaires de supervision de ces machines...

L'argument <check_period> de chaque définition de service vous permet de spécifier une période qui renseigne Nagios sur le moment où le service doit être contrôlé. Quand Nagios essaie de réordonnancer un contrôle de service, il s'assurera que le prochain contrôle tombe dans une plage de temps valide à l'intérieur de la période définie. Dans le cas contraire, Nagios ajustera le moment du prochain contrôle de service pour coïncider avec le prochain moment "valide" dans la période spécifiée. Cela signifie que le service peut ne pas être recontrôlé avant une heure, un jour, ou une semaine, etc.

Problèmes potentiels liés aux contrôles de service

Si vous utilisez des périodes qui ne couvrent pas une plage 24h/24, 7j/7, vous aurez des problèmes, particulièrement si un service (ou l'hôte correspondant) est hors fonction alors que le contrôle a été repoussé au prochain moment valide de la période. Voici quelques uns de ces problèmes...

1. Les contacts ne se verront pas notifier à nouveau de problèmes sur un service jusqu'à ce que le prochain contrôle puisse avoir lieu.
2. Si un service se rétablit à un moment qui a été exclu de la période de contrôle, les contacts ne recevront pas de notification du rétablissement.
3. L'état du service ne changera pas (dans le journal des états et le CGI) jusqu'à ce qu'il puisse être recontrôlé.
4. Si tous les services associés avec un hôte particulier ont la même période de contrôle, les problèmes de l'hôte ou son rétablissement ne seront pas détectés jusqu'à ce qu'un des services puisse être contrôlé (et donc les notifications peuvent être retardées ou ne pas être envoyées du tout).

Limiter la période de contrôle de service à autre chose que 24 heures sur 24, 7 jours sur 7 peut causer de nombreux problèmes. En fait, pas tant des problèmes que des désagréments et des inexactitudes... A moins que vous n'ayez une bonne raison de le faire, je vous recommande fortement de définir dans l'argument <check_period> de chaque service une période de type "24x7".

Comment les périodes fonctionnent pour les notifications aux contacts

Le meilleur usage que vous puissiez probablement faire des périodes est de gérer le moment auquel les notifications peuvent être envoyées aux contacts. En utilisant les arguments <svc_notification_period> et <host_notification_period> dans les définitions de contact, vous pouvez définir une période de disponibilité pour chaque contact. Notez que vous pouvez définir des périodes différentes pour les notifications d'hôte et de service. Ceci peut être utile si vous voulez que les notifications d'hôtes soient envoyées au contact n'importe quel jour de la semaine, mais que les notifications de service ne soient envoyées que les jours ouvrables. Il faut savoir que ces deux périodes de notification doivent couvrir tous les moments où le contact peut recevoir la notification. Vous pouvez définir les périodes de notification pour des services ou des hôtes de manière spécifique de la manière suivante...

En définissant l'argument <notification_period> de la définition d'hôte, vous gérez les moments où Nagios est autorisé à envoyer des notifications concernant les problèmes ou les rétablissements de cet hôte. Quand une notification d'hôte est prête à partir, Nagios s'assurera que le moment présent fait partie d'une plage valide de la période <notification_period>. Si c'est un moment valide, alors Nagios tentera de notifier chaque contact du problème de l'hôte. Certains contacts peuvent ne pas recevoir la notification d'hôte si leur argument <host_notification_period> n'autorise pas les notifications d'hôtes à ce moment. Si le moment n'est pas valide au sein de l'argument <notification_period> défini pour l'hôte, Nagios n'enverra la notification à aucun contact.

Vous pouvez définir les moments de notification pour les services de la même manière que pour les hôtes. En définissant l'argument <notification_period>, vous pouvez gérer les moments où Nagios est autorisé à envoyer des notifications concernant les problèmes ou les rétablissement de ce service. Quand une notification de service est prête à partir, Nagios s'assurera que le moment présent fait partie d'une plage valide de la période <notification_period>. Si c'est un moment valide, alors Nagios tentera de notifier chaque contact du problème du service. Certains contacts peuvent ne pas recevoir la notification de service si leur argument <svc_notification_period> n'autorise pas les notifications de service à ce moment. Si le moment n'est pas valide au sein de l'argument <notification_period> défini pour le service, Nagios n'enverra la notification à aucun contact.

Problèmes potentiels liés aux notifications de contact

Il n'y a pas réellement de problèmes majeurs liés à l'utilisation de périodes pour la notification des contacts. Vous devez toutefois être conscients que des contacts peuvent ne pas toujours recevoir notification de problèmes ou de rétablissements d'hôtes ou de services. Si le moment n'est pas correct à la fois pour la période de notification de l'hôte ou du service, et la période de notification du contact, la notification ne partira pas. Une fois que vous avez bien pesé les problèmes potentiels qu'amène la restriction des moments de notification par rapport à vos besoins, vous devriez pouvoir mettre en place une configuration adaptée à votre situation.

Conclusion

Les périodes vous donnent une meilleure maîtrise de la façon dont Nagios réalise la supervision et les notifications, mais peut amener des problèmes. Si vous ne savez pas trop quelles périodes implémenter, ou si votre implémentation pose des problèmes, je vous suggère d'utiliser des périodes "24x7" (où toutes les heures sont valides tous les jours de la semaine). N'hésitez pas à me contacter si vous avez des questions ou si vous rencontrez des problèmes.