Introduction

Une des fonctionnalités de Nagios est la possibilité d'effectuer des contrôles de service en parallèle. Cette documentation essaiera d'expliquer en détail ce que cela signifie et quel est son impact sur les services que vous avez définis.

Comment fonctionne la parallélisation

Avant que je n'explique comment fonctionne la parallélisation du contrôle des services, vous devez d'abord comprendre comment Nagios effectue l'ordonnancement des événements. Tous les événements internes de Nagios (c.-à-d. rotation des fichiers journaux, contrôle des commandes externes, contrôle des services, etc.) sont placés dans une file d'attente. Chaque membre de la file d'attente est ordonnancé pour une exécution à un instant donné. Nagios fait de son mieux pour que tous les événements soient exécutés au bon moment, bien que certains puissent être retardés si Nagios est occupé à autre chose.

Les contrôles de services sont un des types d'événement qui sont placés dans la file d'attente de Nagios. Lorsqu'un contrôle de service doit être effectué, Nagios démarre un nouveau processus (avec un appel à la fonction fork()) et effectue le contrôle de service (c.-à-d. un quelconque plugin). Cependant, Nagios n'attend pas que le contrôle de service s'achève ! Il retourne plutôt s'occuper des autres événements qui se trouvent dans la file d'attente...

Que se passe-t-il donc lorsque le contrôle de service s'achève ? Hé bien, le processus lancé par Nagios pour effectuer ce contrôle envoie un message à Nagios avec les résultats du contrôle. C'est alors au tour de Nagios de vérifier la présence et d'analyser les résultats de ce contrôle de service quand il aura le temps.

Afin que Nagios supervise effectivement, il doit analyser les résultats des contrôles de services qui sont terminés. Ceci est effectué via un processus de "récolte". Les "récoltes" de service sont un autre type d'événement placé dans la file d'attente de Nagios. La fréquence de ces événements de "récolte" est déterminée par le paramétre service_reaper_frequency du fichier de configuration principal. Lorsqu'un événement de "récolte" est exécuté, il cherche tous les messages qui contiennent le résultat d'un contrôle de service terminé. Ces résultats sont alors traités par l'algorithme de contrôle des services. A partir de cela, Nagios détermine si des hôtes doivent ou non être contrôlés, si des notifications doivent être envoyées, etc. Lorsque les résultats des contrôles de service ont été analysés, Nagios reprogramme le prochain traitement des contrôles de service et le place dans la file d'attente pour une exécution ultérieure. Ce qui termine le cycle contrôle de service/traitement !

Pour ceux d'entre vous qui veulent vraiment savoir, mais qui n'ont pas regardé le code source, Nagios utilise des files de messages pour traiter les communications entre Nagios et le processus qui effectue le contrôle de service...

Attrape-nigauds possibles...

Vous devez savoir qu'il y a quelques ennuis potentiels liés à la parallélisation du contrôle des services. Comme plusieurs contrôles de service peuvent s'exécuter simultanément, ils peuvent interférer les uns avec les autres. Vous devrez évaluer le type de contrôles de services qui tournent et prendre les mesures appropriées pour vous prémunir des conséquences indésirables. Ceci est particuliérement important si vous avez plus d'un contrôle de service qui accède au même matériel (comme un modem). De même, si au plusieurs contrôles de services se connectent au même démon sur un hôte distant pour vérifier une information, assurez-vous que le démon peut traiter les connexions simultanées.

Heureusement, vous pouvez effectuer certaines manipulations pour éviter les "collisions" de contrôles de services...

1. Le moyen le plus simple pour éviter les collisions est d'utiliser le paramétre service_interleave_factor. Entrelacer les services aidera à réduire la charge imposée par les contrôles de services sur les hôtes distants. Réglez la variable pour utiliser le calcul "débrouillard" [NdT : smart] du facteur d'entrelacement, puis réglez-la manuellement si vous estimez que c'est nécessaire.
2. Ensuite, vous pouvez régler le paramétre max_check_attempts de chaque définition de service à une valeur supérieure à un. Si le contrôle de service entre en collision avec un autre contrôle en cours, Nagios réessaiera le contrôle de service max_check_attempts - 1 fois avant d'envoyer une notification du problème à quelqu'un.
3. Vous pouvez aussi essayer d'implémenter un algorithme du type "retrait et réessai" [NdT : back-off and retry] dans le code de contrôle de service, bien que vous puissiez trouver cela trop difficile ou trop consommateur de temps.
4. Si rien de tout cela ne fonctionne, vous pouvez empêcher la parallélisation des contrôles de service en réglant l'option max_concurrent_checks à 1. Cela ne permettra le contrôle que d'un seul service à la fois, ce n'est donc pas une solution spectaculaire. S'il y a suffisamment de demandes, j'ajouterai une option aux définitions de services qui vous permettra de préciser si le contrôle de chaque service doit être ou non parallélisé. S'il n'y a pas assez de demandes, je ne le ferai pas...

Un autre élément à noter est l'effet de la parallélisation des contrôles de service sur les ressources de la machine hébergeant Nagios. Effectuer un grand nombre de contrôles de services en parallèle peut grever les ressources mémoire et processeur. Le paramétre inter_check_delay_method essaiera de minimiser la charge imposée sur votre machine en répartissant les contrôles de manière homogène dans le temps (si vous utilisez la méthode "débrouillard" [NdT : smart]), mais ce n'est pas une solution totalement sûre. Afin d'avoir un regard sur le nombre de contrôles de services qui peuvent s'exécuter en même temps, utilisez le paramétre max_concurrent_checks. Vous devrez affiner sa valeur, basée sur le nombre total de services que vous contrôlez, les ressources système disponibles (cadence du processeur, mémoire, etc.) et les autres processus qui tournent sur votre machine. Pour avoir davantage d'informations sur la façon de régler le paramétre max_concurrent_checks pour qu'il corresponde à vos exigences, lisez la documentation relative à l'ordonnancement des contrôles.

Ce qui n'est pas parallélisé

Il faut se souvenir que seule l'éxecution des contrôles de services a été parallélisée. Il y a une bonne raison à cela - les autres choses ne peuvent pas l'être d'une manière trés sûre ou très saine. En particulier les gestionnaires d'événements, les notifications de contact, le traitement des contrôles de services et des contrôles d'hôtes ne sont pas parallélisés. Voici pourquoi...

Les gestionnaires d'événements ne sont pas parallélisés du fait de leur conception même. Une grande part de leur puisssance provient de leur capacité à résoudre les problèmes de manière préventive. Par exemple, redémarrer le serveur web quand le service HTTP de la machine locale est détecté DOWN. Pour éviter que plusieurs gestionnaires d'événements n'essayent de "résoudre" des problèmes en parallèle (sans savoir ce que font les autres), j'ai décidé de ne pas les paralléliser.

Les notifications de contact ne sont pas parallélisées à cause des méthodes de notification que vous pouvez utiliser. Si, par exemple, une notification de contact utilise un modem pour composer le numéro de votre pager et lui envoyer un message, elle a besoin de l'accès exclusif au modem pendant que la notification s'effectue. Si plusieurs notifications étaient exécutées en parallèle, une seule serait effectuée car les autres n'auraient pas accès au modem. Il y a des moyens de contourner cela, comme employer une méthode du style "retrait et réessai" dans le script de notification, mais j'ai décidé de ne pas me fier aux utilisateurs qui pourraient implémenter ce type de fonction dans leurs scripts. Une note rapide : si vous avez des contrôles de services qui utilisent un modem, assurez-vous que les scripts de notification qui effectuent la numérotation peuvent réessayer d'accéder au modem après un échec. C'est nécessaire, car un contrôle de service peut s'exécuter en même temps qu'une notification !

Le traitement des résultats des contrôles de services n'a pas été parallélisé. Et cela pour éviter les situations où de multiples notifications relatives à des problèmes ou au rétablissement d'hôtes ou de service peuvent être envoyées lorsqu'un hôte passe dans l'état DOWN, UNREACHABLE, ou RECOVERY.