L’installation de Munin (serveur) et Munin-node (PCs à monitorer) n’est pas compliquée. De base, assez bien de plugins existent et sont déjà configurés. Les statistiques sont présentées en graphique clairs.
J’avais déjà fait un billet concernant l’installation de Munin sur un serveur.
Mais certaines choses pourtant utiles ne sont pas monitorées par défaut. Par exemple, si vous voulez vérifier la température, la vitesse du ventilateur (et là, il vaut mieux savoir à l’avance s’il commence à faiblir ou à s’encrasser), il est nécessaire d’ajouter quelques éléments pour que ces statistiques soient disponibles.
Je me base sur la page (en) “Munin Statistic” qui fourni de très bonnes explications. 
Le plugin nécessaire est disponible et installé avec Munin, mais il n’est pas activé. De plus, il manque un utilitaire faisant le lien entre votre hardware et les capteurs associés, et le plugin Munin : Lm-sensor.
J’ai déjà Munin et Munin-node installé sur ce serveur, et Munin-node est également sur d’autres machines, locales ou distantes. Je ne reviens pas sur l’installation de base de Munin.
Commençons pas installer Lm-sensor.
C’est classique en Debian ou Ubuntu : un apt-get, ou un aptitude, et c’est fait.
N’oubliez pas d’utiliser le user “root”, ou si vous êtes en Ubuntu, de taper “sudo ” devant chaque commande système.
# aptitude install lm-sensors
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Lecture de l'information d'état étendu
Initialisation de l'état des paquets... Fait
Construction de la base de données des étiquettes... Fait
Les NOUVEAUX paquets suivants vont être automatiquement installés :
libsensors4
Les NOUVEAUX paquets suivants vont être installés :
libsensors4 lm-sensors
0 paquets mis à jour, 2 nouvellement installés, 0 à enlever et 1 non mis à jour.
Il est nécessaire de télécharger 250ko d'archives. Après dépaquetage, 918ko seront utilisés.
Voulez-vous continuer ? [Y/n/?]
Suivant votre modèle de carte mère, le chipset (Intel, AMD, nVidia, VIA, SIS…) et le type de processeur (Intel, AMD, VIA…), les capteurs disponibles peuvent être très différents. Une commande permet de contrôler ceux qui sont réellement disponibles dans votre machine :
# sensors-detect # sensors-detect revision 4171 (2006-09-24 03:37:01 -0700) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. We can start with probing for (PCI) I2C or SMBus adapters. Do you want to probe now? (YES/no): Probing for PCI bus adapters... Use driver `i2c-viapro' for device 0000:00:11.0: VIA Technologies VT8233A/8235 South Bridge We will now try to load each adapter module in turn. Module `i2c-viapro' already loaded. If you have undetectable or unsupported adapters, you can have them scanned by manually loading the modules before running this script. To continue, we need module `i2c-dev' to be loaded. Do you want to load `i2c-dev' now? (YES/no): Module loaded successfully. We are now going to do the I2C/SMBus adapter probings. Some chips may be double detected; we choose the one with the highest confidence value in that case. If you found that the adapter hung after probing a certain address, you can specify that address to remain unprobed. Next adapter: SMBus Via Pro adapter at 0400 Do you want to scan it? (YES/no/selectively): Client found at address 0x50 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... Success! (confidence 8, driver `eeprom') Probing for `EDID EEPROM'... No Probing for `Maxim MAX6900'... No Client found at address 0x69 ...
Les tests continuent. La liste est fort longue.
...
Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `ITE'... Yes
Found `ITE IT8705F Super IO Sensors' Success!
(address 0x290, driver `it87')
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `ITE'... Yes
Found `ITE IT8705F Super IO Sensors' Success!
(address 0x290, driver `it87')
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus Via Pro adapter at 0400'
Busdriver `i2c-viapro', I2C address 0x50
Chip `SPD EEPROM' (confidence: 
EEPROMs are *NOT* sensors! They are data storage chips commonly
found on memory modules (SPD), in monitors (EDID), or in some
laptops, for example.
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `ITE IT8705F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the required modules.
Just press ENTER to continue:
To make the sensors modules behave correctly, add these lines to
/etc/modules:
#----cut here----
# I2C adapter drivers
i2c-viapro
# Chip drivers
eeprom
it87
#----cut here----
Do you want to add these lines to /etc/modules automatically? (yes/NO) yes
J’ai répondu “yes” à la dernière question : les modules ont donc été ajoutés dans /etc/modules. Mais ils ne sont pas encore actifs.
En effet, ils seront chargés au prochain reboot. Bien évidemment, je désire qu’automatiquement ces modules soient en mémoire si le serveur est redémarré.
Mais, c’est un peu dommage de devoir rebooter une machine juste pour activer des modules !
Heureusement, je peux les charger manuellement :
# modprobe i2c-viapro # modprobe it87
Il reste à tester et activer les monitorings souhaités.
Températures mesurées sur une carte mère VIA avec un cpu VIA C3.
Ce processeur VIA C3 n’est pas très puissant, mais consomme peu,
ce qui explique la faible température.
Les pointes de températures sont dues à certains utilitaires de scanning
(je pense) qui font une utilisation intensive du disque dur.
Certains plugins, dont le nom se termine par le caractère “_”, peuvent retourner plusieurs variables. C’est le cas de “sensors”. Il faut savoir quels sont les variables possibles.
# /usr/share/munin/plugins/sensors_ suggest
fan
volt
temp
J’ai, avec le hardware présent dans mon serveur, 3 possibilités de monitoring. Je vais les ajouter toutes les 3.
Pour cela, il suffit de faire des liens symboliques dans le dossier /etc/munin/plugins :
cd /etc/munin/plugins :/etc/munin/plugins# ln /usr/share/munin/plugins/sensors_ sensors_fan :/etc/munin/plugins# ln /usr/share/munin/plugins/sensors_ sensors_volt :/etc/munin/plugins# ln /usr/share/munin/plugins/sensors_ sensors_temp
On voit que pour les plugins pouvant fournir plusieurs variables, il faut indiquer dans le lien symbolique le nom de la variable (fan, volt ou temp pour le plugin “sensor” pour mon serveur)
Comme souvent quand on modifie une configuration, il faut redémarrer le daemon Munin-node :
# /etc/init.d/munin-node restart
Stopping Munin-Node: done.
Starting Munin-Node: done.
Et voilà, cela fonctionne.
Ah, qu’il est beau le graphique…
Quoi que… certaines valeurs me semblent bizarres…
Je sais qu’on a une marge d’erreur (+/- 5% toléré je pense) dans les voltages, mais le -5 Volts me semble assez écartés ! C’est même du positif !
Et l’écart pour le -12 Volts, qui varie entre -19,83 et -18,58 …
Si j’avais de tels problèmes avec l’alimentation de ce serveur, il se serait planté depuis longtemps je crois !
Donc… vérifiez vos graphiques : sont-ils cohérents ? Parfois certains types de hardware ne sont pas bien supportés, et les valeurs reçus mal collectées ou mal interprétées…
