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. 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.