Comment répondre aux questions suivantes:

• Pourquoi ça rame ?
• Est ce que c'est logiciel ou matériel (et qu'est ce qui est actionnable) ?
• Si c'est logiciel, qui prend des ressources ?

On part du général vers le particulier, c'est à dire l'état général de la machine, puis d'une ou quelques métrique pour enfin aller au détail processus par processus. Ce faisant on évite de se focaliser sur un problème local et de louper un problème plus important au niveau global.

Avant de qualifier un bon ou un mauvais fonctionnement, il faut l'étalonner (i.e. connaître les limites théorique et pratique). Deux exemples pour illustrer:

• Je fait un test de débit sans tester mon système dans les conditions optimales (deux ordinateurs avec iperf et un câble ethernet entre les deux). Si mon câble et/ou une des interfaces réseau est défectueuse, je vais voir un problème de débit partout et mon test ne me donne pas d'information utile. Si j'étalonne et que je me rend compte que le débit maximal dans les conditions optimales est de 250 mbps avec des interfaces gigabits, je sais quelles sont les limites de mon test: je peux tester de l'ADSL, des pont radios, éventuellement de la fibre optique mais pas avec un débit de plus de 250 mbps.
• Je regarde des logs pour déterminer l'origine d'un problème. Si je n'ai pas connaissance des logs en conditions normales (quel est le bruit de fond) je vais me focaliser sur tout les messages que je trouve suspect. Or rien ne me garanti que les logs soient bien écrits; il arrivent que des messages soient alarmants sans que ce soit vraiment le cas: par exemple dans les logs d'un serveur web:
  • open() "/var/lib/dehydrated/acme-challenges/license.php" failed (2: No such file or directory), c'est “juste” un client web qui scan. Ça ne veut pas dire que c'est sans importance mais ce type de message a toute chance de faire partie du bruit de fond. On cherche d'abord ce qui sort du bruit de fond.
  • a contrario, dans le même contexte, une erreur 500 met en cause l'application et/ou la configuration du serveur (si là ça fait partie du bruit de fond, il y a un autre type de problème… :( )
• Une étape cruciale peut échouer sans être loggée
• Bref, pouvoir constater les logs en fonctionnement normal et pouvoir trier les logs par priorité (SYSLOG.PRIORITY par exemple) permet de hiérarchiser la recherche dans les logs et éventuellement d'ajuster la verbosité de certaines applications (en plus ou en moins d'ailleurs) pour faciliter la recherche de la cause d'un problème.

Outils en vracs:

• uptime (permet de voir l'uptime mais aussi le load (le load est un indicateur qui -avec N le nombre de processeurs dont dispose la machine- dit en gros: en dessous de N, ça va, au dessus le système n'est plus “temps réél”: les questions arrivent plus vite que les réponses). Le load est donné sur:
  • la dernière minute écoulée
  • les 5 dernières minutes écoulées
  • les 15 dernières minutes écoulées
• atop, atopsar (Accumulated Top) permet de voir la consommation mémoire, disque, CPU, Swap des processus individuellement ou par groupe.
• sysstat (fourni entre autre: iostat, pidstat)
• iotop

Un système parfaitement fonctionnel au niveau matériel mais surchargé, a du mal à indiquer l'origine d'un problème. Par exemple, si il y a une surcharge au niveau des disque (le temps d'accès I/O va s'allonger) alors le moindre processus qui fait une demande d'accès disque va se retrouver dans le top des consommateurs d'I/O disque pour un instant, puis ça sera le suivant. Du point de vue de l'administrateur système, c'est le syndrome du “tous coupables”. Pour déterminer le véritable coupable dans ce type de situation, il faut monitorer pendant la montée en charge avant que la charge ne sature le système.

Lorsqu'il y a un problème d'ordre matériel, alors par construction, la remontée d'information ne sera pas fiable. Si le cpu et/ou la RAM renvoie de fausses informations, il y a toute chance que le système plante. Ça peut être aussi le cas d'un composant sur la carte mère. Je me demande même si dans le cas d'un contrôleur disque défaillant, celui ci pourrait introduire de la latence qui ne sera pas comptabilisé ni dans la consommation des I/O disques générales ni par processus mais l'IOwaitTime du CPU pourrait trahir ce genre de comportement.

Dans ce genre de cas, on va chercher à mettre en cause composant par composant en essayant de les faire échouer pour savoir à qui on peut faire confiance. Tests de la mémoire RAM (memtest86, memtester), test de surcharge du CPU (stress test, cpu burn). Ces tests sont plus compliquer à mener car ils impliquent au mieux un service dégradé ou arrêté et au pire des dégâts irréversible (un cpuburn sur un microprocesseur sans radiateur va le griller).