Les experts en supervision libre le savent : au delà d’un certain nombre de machines composant un parc, la supervision à mettre en place peut devenir un véritable casse-tête.
Pourquoi ?
Tout simplement parce chaque équipement supervisé impliquera un certain nombre de sondes à déclencher régulièrement.
Et on ne peut pas se contenter de multiplier à l’infini ces sondes, sous peine d’écrouler le serveur de supervision.
Face à cette problématique, il existe plusieurs solutions :
- Muscler son infrastructure de supervision, en adjoignant au serveur de supervision d’autre machines « satellites » qui auront pour mission de soulager le serveur principal, [br]
- Répartir la charge via des add-ons tels que modgear, ou check_mk, [br]
- Abandonner, quand c’est possible, les sondes actives, au profit de sondes passives.
Je ne détaillerai pas ici chacun de ces mécanismes. Un article de cent pages n’y suffirait pas.
Sachez simplement que Overmon sera à même d’implémenter, dans un futur proche, chacune de ces solutions.
Aujourd’hui, avec la version 7.7, nous introduisons la gestion des sondes passives au sein de Overmon
Qu’est-ce qu’une sonde passive ?
Jetez un oeil sur ce schéma :
Dans le premier cas (sondes actives), c’est le serveur de supervision (Nagios) qui, à intervalles réguliers, lance une requête (1) vers le serveur à superviser. Celui-ci, dès qu’il recoit la requête, traite la demande (2), puis retourne le résultat (3) vers le serveur de supervision
Dans le second cas (sondes passives), c’est le serveur à superviser qui, de lui-même, enverra à intervalles réguliers des informations (2), que le serveur de supervision se contentera de recevoir, analyser, et aggréger.
Nous le voyons bien avec cet exemple : la charge de travail est considérablement amoindrie pour le serveur de supervision. Par conséquent, ce même serveur de supervision voit ainsi capable de traiter un parc de machines plus important.
Mais alors, me direz-vous, pourquoi ne pas utiliser systématiquement des sondes passives ?
Jusqu’à aujourd’hui, l’implémentation de sondes passives posait certains problèmes :
- La machine à superviser étant maîtresse des informations à envoyer, tout doit donc être paramétré sur chacune de ces machines. Rien ne peut se faire de façon centralisée.
- Impossible pour le serveur de supervision de passer des valeurs d’arguments aux hôtes supervisés
[NSCALinuxChecks]
NSCA-LINUX-CPU-LOAD=$PathLibexec/check_nrpe -t 60 -H localhost -n -c check_load -a \"15,10,5\" \"30,25,20\"
NSCA-LINUX-DISKS=$PathLibexec/check_nrpe -t 60 -H localhost -n -c check_disks -a \"10%\"
NSCA-LINUX-PROCESSES=$PathLibexec/check_nrpe -t 60 -H localhost -n -c check_total_procs -a 500 1000 RSZDT
NSCA-LINUX-SWAP=$PathLibexec/check_nrpe -t 60 -H localhost -n -c check_swap -a 20 10
NSCA-LINUX-USERS=$PathLibexec/check_nrpe -t 60 -H localhost -n -c check_users -a 5 10
NSCA-LINUX-ZOMBIES=$PathLibexec/check_nrpe -t 60 -H localhost -n -c check_zombie_procs -a 5 10
[NSCAWindowsChecks]
NSCA-WIN-CPU-LOAD=checkCPU warn=80 crit=90 time=5m time=1m time=30s
NSCA-WIN-DISKS=CheckDriveSize MinWarn=10% MinCrit=5% CheckAll FilterType=FIXED
NSCA-WIN-EVENTLOGS=CheckEventLog file=application file=system MaxWarn=1 MaxCrit=1 \"filter=generated gt -2d AND severity NOT IN ('success', 'informational') AND source != 'SideBySide'\" truncate=800 unique descriptions
NSCA-WIN-MEMORY=checkMem MaxWarn=80% MaxCrit=90% ShowAll=long type=physical type=virtual type=paged type=page
NSCA-WIN-PROCESSES=checkProcState MaxWarnCount=500 MaxCritCount=1000
NSCA-WIN-SERVICESTATE=checkServiceState CheckAll
NSCA-WIN-UPTIME=checkUpTime MinWarn=1d MinWarn=1h
Deux nouveaux paragraphes sont au menu : NSCALinuxChecks et NSCAWindowsChecks
Ils permettent de définir quels sont les checks passifs que vous souhaitez implémenter. Vous pouvez enrichir à votre convenance les checks proposés par défaut.
Concernant le déploiement des ces checks, comme d’habitude, on ne peut faire plus simple …
Un certain nombre de host templates sont prévus :
[br] Il vous suffit donc d’associer ces nouveaux types de host à vos machines, et de lancer le déploiement : [br]
[br] Patientez que le déploiement se termine, puis allez simplement sur votre interface Centreon. Il ne vous reste plus qu’à admirer le résultat : [br]
[br]L’ensemble des services, tels que définis dans votre fichier ini sont bien implémentés !
Cerise sur le gâteau : vous n’êtes même pas obligé d’avoir déclaré les services templates au prélable. L’oat le fait pour vous.
Comme aurait mon cher cyclopède … [br]
étonnant, non ? [br]
Cette version inclut également de petites corrections (changelog)
[br] [br] [hr]
