Générer un rapport système complet (matériel + pilotes + erreurs) en un seul script

février 25, 2026 • février 25, 2026 • Lecture : 34 min • Views: 0

Cet article vous a aidé ?

Vous connaissez le moment. Il est 02:13, une base de données est « lente », et la seule preuve disponible est une capture d’écran de top
plus un souvenir flou que « hier tout allait bien ». Le fournisseur demande « un rapport système complet », votre responsable veut une chronologie,
et vous voulez dormir. La bonne démarche est de faire raconter la machine son histoire dans un instantané reproductible.

Voici comment construire un script unique qui collecte le matériel, les pilotes, l’état du stockage, les messages du noyau et les erreurs qui
comptent vraiment — sans briquer l’hôte, sans exposer de secrets, et sans produire un blob illisible de 80 Mo que personne n’ouvre.

À quoi ressemble un bon rapport système complet

Un rapport système complet n’est pas un trophée. C’est un outil. S’il ne peut pas répondre rapidement à « qu’est-ce qui a changé ? » et « qu’est-ce qui échoue ? »,
c’est juste une utilisation du disque avec des étapes en plus.

Voilà le niveau que j’utilise en production :

Une seule commande à lancer. Pas d’invite interactive. Pas d’« installer ça » à 3 h du matin.
Lisibilité d’abord. Fichiers texte regroupés par sujet. Un humain doit pouvoir parcourir rapidement.
Compatible diff machine. Formatage stable pour comparer aujourd’hui vs la semaine dernière.
Risque minimal. Pas de benchmarks par défaut. Pas d’outils firmware invasifs. Pas de « rescanner le bus » héroïque.
Conscient des secrets. Capturer suffisamment pour déboguer ; éviter de vider des jetons, données clients et clés privées.
Crédible pour le stockage. Si la machine a ZFS, mdraid, LVM, multipath, NVMe — collecter correctement leur état de santé.
Axé sur les erreurs. Récupérer les erreurs du noyau et du journal avec le contexte. Pas seulement « voici tous les logs depuis 2019 ».

Aussi : compresser le tout. Donner un nom sensé. Inclure un manifeste. Si vous avez déjà essayé d’envoyer au fournisseur « des fichiers que j’ai copiés depuis /var/log »,
vous savez déjà pourquoi.

Faits & bref historique: pourquoi c’est comme ça

Un peu de contexte rend l’outil meilleur. Ces détails expliquent pourquoi le reporting Linux ressemble à un tiroir rempli de clés anglaises aux formes étranges.

/proc et /sys existent parce que le noyau avait besoin d’une API « fichier » pour l’introspection. Ce n’est pas un disque ; c’est une vue de l’état du noyau.
lspci vient des utilitaires PCI qui précèdent beaucoup d’observabilité « moderne ». C’est toujours le moyen le plus rapide de lier périphériques et pilotes.
dmesg est un journal en anneau à l’ancienne. C’est bruyant, mais c’est là où les pannes matérielles et pilotes confessent en premier.
Le journal de systemd a été conçu pour réparer la fragmentation des logs. Il centralise, ajoute des métadonnées, et rend « montre-moi les démarrages » une requête de première classe.
SMART précède NVMe. Le « SMART log » NVMe est similaire dans l’esprit mais pas identique ; mélanger les interprétations mène à de mauvaises décisions.
mdraid a survécu parce que c’est ennuyeux et fiable. C’est dans le noyau, stable et compris — encore un défaut dans beaucoup d’entreprises.
Les noms de périphériques comme /dev/sda n’étaient pas destinés à être des identifiants stables. C’est pourquoi il y a /dev/disk/by-id et les règles udev.
Multipath existe parce que les SAN omettent des informations. Si vous ne vérifiez pas la santé des chemins, vous croirez que « redondant » signifie « sans risque ».
La topologie CPU moderne est compliquée parce que la performance l’est. NUMA, SMT et la gestion d’énergie peuvent faire en sorte que deux CPU du même modèle se comportent différemment.

Blague #1 : Les logs sont comme des scènes de crime — tout le monde dit « je n’ai rien touché », puis vous trouvez de nouvelles empreintes partout dans /etc.

Principes de conception : sûr, comparable, exploitable

1) Préférer l’inspection en lecture seule plutôt que la sonde active

On obtient 90 % de la valeur en inspectant : lsblk, lspci, modinfo, journalctl, lectures SMART.
Les sondes actives (tests de charge, rescans, mises à jour firmware) peuvent modifier le système ou amplifier une panne. Ne pas les faire par défaut.

2) Capturer l’identité et le contexte en premier

Avant de collecter quoi que ce soit d’autre, capturez :

hostname, version de l’OS, version du noyau, uptime
état de la synchronisation temporelle
indices de virtualisation/conteneur
historique de démarrages et raison du dernier redémarrage (quand disponible)

La raison est simple : beaucoup d’« erreurs » ne sont que des sauts temporels, des démarrages partiels ou des incompatibilités de noyau. Le contexte évite de diagnostiquer des fantômes.

3) Rendre la sortie suffisamment stable pour diff

Les humains aiment « le plus récent d’abord ». Les outils de diff aiment la stabilité. Vous pouvez avoir les deux en écrivant des fichiers avec des noms déterministes et des formats stables,
et en séparant « état courant » et « événements récents ». Par exemple : enregistrez la sortie de lsblk et enregistrez aussi
« les erreurs du journal depuis le démarrage ».

4) Éviter de collecter des secrets par accident

Ne pas aspirer :

/etc/shadow, clés SSH privées, jetons de métadonnées cloud
configs applicatives contenant des identifiants (URLs de base de données, clés API)
vidages d’environnement complets depuis les listes de processus

À la place, collectez des fragments de config sanitizés (versions de paquets, statut des services, fichiers unit) et des logs avec fenêtres temporelles limitées.
Un bundle de support doit être sûr à partager avec votre équipe sécurité sans mail d’excuse interminable.

5) Être explicite sur les permissions

Beaucoup de commandes utiles requièrent root : lectures SMART, accès au journal, certains outils de stockage. Votre script devrait :

s’exécuter en root (recommandé) ou se dégrader gracieusement
enregistrer quelles commandes ont échoué pour cause de permissions
ne jamais faire de « sudo » à l’intérieur du script (trop d’environnements l’interdisent)

6) Capturer les erreurs avec les preuves environnantes

Traces de pile du noyau, messages de reset NVMe, erreurs ext4, timeouts mpt3sas — ce sont les miettes de pain.
Quand vous extrayez des erreurs, incluez quelques lignes de contexte et l’ID/horodatage de démarrage. Sinon vous collerez
une ligne effrayante dans le chat et déclencherez une panique inutile.

Mode opératoire pour un diagnostic rapide (premier/deuxième/troisième)

Quand quelqu’un dit « le serveur est lent », il veut dire « ma requête est lente ». Cela peut venir du CPU, du stockage, de la mémoire, du réseau,
ou d’un pilote qui spamme des resets. Commencez par les vérifications qui écartent des classes entières de problèmes.

Premier : confirmer les bases (10 secondes)

L’horloge est-elle saine ? Les sauts temporels rendent les logs inutilisables et peuvent casser TLS, le clustering et les caches.
La machine redémarre-t-elle ou bascule-t-elle ? Uptime et logs de démarrage montrent si vous poursuivez une cible mouvante.
Y a-t-il une tempête dans dmesg ? Si le noyau hurle, écoutez avant d’optimiser quoi que ce soit.

Deuxième : identifier le domaine du goulot d’étranglement (1 minute)

Saturation CPU ? Charge élevée avec user/sys élevés, ou file d’attente de run qui s’allonge.
Pression mémoire ? Activité swap, kills OOM, stalls de reclaim.
Attente I/O ? Iowait élevé, tâches bloquées, latence disque.
Réseau ? Paquets perdus, retransmissions, resets du pilote NIC.

Troisième : mapper les symptômes vers la couche physique/pilote (5 minutes)

Quel périphérique est lent ? Quel contrôleur ? Quel pilote ?
Les erreurs coïncident-elles avec une version de firmware ou un module ?
Êtes-vous sur un pool RAID/ZFS dégradé ?
Une mise à jour mineure du noyau a-t-elle modifié la pile de stockage ?

Un flux de travail fiable : logs → topologie → santé → dérive de configuration. L’inverse (« tuner sysctl d’abord ») vous fait polir le capot pendant que le moteur brûle.

12+ tâches pratiques : commandes, signification, décision

Voici les tâches spécifiques qu’un « rapport système complet » doit couvrir. Chaque tâche inclut : une commande, ce que la sortie vous dit,
et quelle décision en tirer. Utilisez-les en mode interactif, et intégrez-les ensuite au bundle en un script.

Tâche 1 : Identifier l’OS + noyau + mode de démarrage

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 x86_64 x86_64 GNU/Linux

Signification : La version du noyau et la saveur de build influencent le comportement des pilotes (surtout stockage et NIC).

Décision : Si ce noyau a changé récemment, considérez une régression de performance comme « problème pilote/firmware » jusqu’à preuve du contraire.

cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"

Signification : La politique de mise à jour des paquets et du noyau est implicite selon la distribution et la release.

Décision : Le support fournisseur dépend souvent de la release mineure du distro ; ne l’ignorez pas.

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Signification : Le mode de démarrage influence le partitionnement, le comportement du bootloader et parfois les outils firmware.

Décision : Pour des flottes : standardisez le mode de démarrage ; un mix UEFI/BIOS complique l’automatisation et la récupération.

Tâche 2 : Confirmer l’uptime et les logs du dernier démarrage

cr0x@server:~$ uptime -p
up 17 days, 3 hours, 12 minutes

Signification : De longs uptimes cachent la dégradation lente ; de courts uptimes signifient une fenêtre d’évidence réduite.

Décision : Si l’uptime est suspectement court, priorisez « pourquoi a-t-il redémarré » plutôt que « pourquoi c’est lent ».

cr0x@server:~$ journalctl -b -1 -n 30 --no-pager
Feb 05 01:02:11 server kernel: Linux version 6.5.0-21-generic (buildd@lcy02-amd64-039) ...
Feb 05 01:02:19 server systemd[1]: Started Journal Service.
Feb 05 01:02:26 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x1, PCI_STATUS=0x10
Feb 05 01:02:28 server kernel: nvme nvme0: reset controller

Signification : Les messages du démarrage précédent montrent souvent la première occurrence du problème (comme des resets de stockage).

Décision : Si les démarrages antérieurs montrent des resets de périphérique, cessez de blâmer l’application et commencez à valider la santé du stockage/PCIe.

Tâche 3 : Instantané rapide CPU et mémoire

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 512340  92112 4213900   0    0    12    44  320  510  6  2 90  2  0
 5  1      0 120480  93200 4061012   0    0   180   920 1250 2100 14  6 60 20  0

Signification : r file d’exécution, b tâches bloquées, swap in/out, et wa iowait.

Décision : Un wa élevé et des tâches bloquées signifient latence stockage ; n’ajoutez pas de CPU pour résoudre un problème disque.

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           31Gi        12Gi       490Mi       1.2Gi        18Gi        17Gi
Swap:           0B          0B          0B

Signification : « free » n’est pas tout ; « available » est ce qui compte.

Décision : Si available est faible et la latence élevée, vérifiez le reclaim/I/O ; si un swap existe et est actif, attendez des pics de latence en queue.

Tâche 4 : Trouver rapidement les erreurs du noyau

cr0x@server:~$ dmesg -T --level=err,warn | tail -n 20
[Mon Feb  5 03:11:22 2026] nvme nvme0: I/O 129 QID 7 timeout, aborting
[Mon Feb  5 03:11:22 2026] nvme nvme0: Abort status: 0x0
[Mon Feb  5 03:11:23 2026] nvme nvme0: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10
[Mon Feb  5 03:11:25 2026] EXT4-fs warning (device dm-0): ext4_end_bio:344: I/O error 10 writing to inode 262402 starting block 8392704

Signification : Le noyau vous dit la vérité terrain : timeouts, resets, retombées filesystem.

Décision : Si vous voyez des resets/timeouts, arrêtez les optimisations de perf. Collectez versions firmware, état du lien PCIe et santé du stockage ensuite.

Tâche 5 : Mapper les périphériques PCI aux pilotes

cr0x@server:~$ lspci -nnk | sed -n '1,80p'
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e30] (rev 0a)
03:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]
        Subsystem: Samsung Electronics Co Ltd Device [144d:a801]
        Kernel driver in use: nvme
        Kernel modules: nvme
05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
        Kernel driver in use: i40e
        Kernel modules: i40e

Signification : « Quel périphérique, quel pilote ». C’est ainsi que l’on relie un timeout dans dmesg à un contrôleur et un module précis.

Décision : Si le pilote est inattendu (pilote de secours, ou module externe ancien), vous avez un risque de supportabilité et de stabilité.

Tâche 6 : Confirmer les modules chargés et leurs versions

cr0x@server:~$ lsmod | head
Module                  Size  Used by
nvme                   61440  2
nvme_core             212992  4 nvme
i40e                  557056  0
xfs                  1703936  1

Signification : Les modules chargés montrent ce qui tourne réellement, pas ce que vous croyez installé.

Décision : Si les modules stockage/NIC n’ont pas les dépendances attendues ou affichent des comptes « Used by » bizarres, suspectez une instabilité de pilote ou une mise à jour partielle.

cr0x@server:~$ modinfo i40e | sed -n '1,15p'
filename:       /lib/modules/6.5.0-21-generic/kernel/drivers/net/ethernet/intel/i40e/i40e.ko
version:        2.24.0-k
license:        GPL
description:    Intel(R) Ethernet Connection XL710 Network Driver
firmware:       i40e/ddp/i40e-1.3.34.0.pkg

Signification : Version du pilote et attentes concernant le blob firmware sont indiquées ici.

Décision : Si le pilote attend un paquet firmware absent, vous pouvez avoir des fonctionnalités dégradées ou un comportement de lien étrange.

Tâche 7 : Inventaire des disques, systèmes de fichiers et options de montage

cr0x@server:~$ lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,ROTA,TRAN,HCTL,FSTYPE,MOUNTPOINTS
NAME        TYPE   SIZE MODEL              SERIAL        ROTA TRAN HCTL       FSTYPE MOUNTPOINTS
nvme0n1     disk  1.8T  Samsung SSD 980    S6X...           0 nvme -          -      -
nvme0n1p1   part   512M -                  -                0 nvme -          vfat   /boot/efi
nvme0n1p2   part   1.8T -                  -                0 nvme -          LVM2_member
dm-0        lvm   1.8T  -                  -                0 -    -          ext4   /

Signification : Cela relie les périphériques physiques aux couches logiques (partitions → LVM → système de fichiers).

Décision : Si vous voyez un empilement inattendu (ex. mdraid au-dessus de dm-crypt au-dessus de LVM), la performance et la récupération deviennent plus difficiles. Documentez-le.

cr0x@server:~$ findmnt -Dno TARGET,SOURCE,FSTYPE,OPTIONS | sed -n '1,20p'
/ /dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro
/boot/efi /dev/nvme0n1p1 vfat rw,relatime,fmask=0077,dmask=0077

Signification : Les options de montage comptent : barriers, atime, discard, gestion d’erreurs.

Décision : Si des systèmes critiques montent avec des options risquées (désactivation de journaling ou barriers), considérez cela comme une panne en attente.

Tâche 8 : Vérifier la santé NVMe (si présent)

cr0x@server:~$ nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
/dev/nvme0n1     S6X...               Samsung SSD 980 PRO 2TB                  1          1.80  TB /   2.00  TB    512   B +  0 B   5B2QGXA7

Signification : La révision firmware n’est pas anecdotique ; c’est souvent la différence entre « stable » et « resets mystères ».

Décision : Si la révision FW est connue mauvaise dans votre environnement, planifiez une mise à jour contrôlée, pas un correctif d’urgence en production.

cr0x@server:~$ nvme smart-log /dev/nvme0n1 | sed -n '1,25p'
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
percentage_used                     : 3%
data_units_read                     : 12,345,678
data_units_written                  : 9,876,543
media_errors                        : 0
num_err_log_entries                 : 18

Signification : critical_warning, media_errors et les entrées du journal d’erreurs sont vos signaux d’alerte précoces.

Décision : Si les entrées d’erreurs augmentent et que vous voyez des timeouts noyau, suspectez le périphérique, le lien PCIe ou l’interaction contrôleur/firmware.

Tâche 9 : Vérifier le SMART classique (SATA/SAS)

cr0x@server:~$ smartctl -a /dev/sda | sed -n '1,40p'
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.5.0-21-generic] (local build)
Device Model:     ST12000NM0007
Serial Number:    ZRT0...
Firmware Version: SN02
SMART overall-health self-assessment test result: PASSED

Signification : « PASSED » n’est pas un blanc-seing ; il faut analyser les tendances d’attributs et les journaux d’erreurs.

Décision : Si des secteurs réalloués/pending existent ou si les erreurs montent, remplacez de manière proactive. Les disques ne guérissent pas ; ils deviennent poétiques.

Tâche 10 : État RAID/ZFS (selon le cas)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5] [raid4]
md0 : active raid1 sdb1[0] sdc1[1]
      976630336 blocks super 1.2 [2/2] [UU]

Signification : [UU] signifie que tous les membres sont en ligne. Tout autre état est dégradé, et les arrays dégradés deviennent lents.

Décision : Si dégradé, arrêtez les enquêtes de performance et commencez les enquêtes de protection des données. Puis reconstruisez en sécurité.

cr0x@server:~$ zpool status
pool: tank
state: ONLINE
scan: scrub repaired 0B in 00:12:31 with 0 errors on Sun Feb  4 02:00:01 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors

Signification : ZFS indique si la redondance est intacte et si les scrubs détectent des corruptions.

Décision : Si les scrubs montrent des erreurs ou DEGRADED, considérez la couche matérielle coupable jusqu’à preuve du contraire.

Tâche 11 : Sanity LVM et device-mapper

cr0x@server:~$ pvs
PV         VG  Fmt  Attr PSize  PFree
/dev/nvme0n1p2 vg0 lvm2 a--  1.81t    0

Signification : Le mapping PV/VG/LV détecte les surprises du type « quelqu’un a redimensionné quelque chose ».

Décision : Si vous voyez des PV manquants ou des VGs partiels, stoppez. Vous pourriez tourner sur une pile dégradée ou mal assemblée.

cr0x@server:~$ lvs -a -o +devices
LV   VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
root vg0 -wi-ao---- 1.81t                                                     /dev/nvme0n1p2(0)

Signification : Montre quels périphériques sous-jacents soutiennent les volumes logiques.

Décision : Si un LV s’étend sur plusieurs PVs de manière inattendue, les performances et les domaines de défaillance changent. Mettez à jour votre modèle mental.

Tâche 12 : Erreurs système de fichiers et signaux du journal

cr0x@server:~$ journalctl -k --since "2 hours ago" -p warning --no-pager | tail -n 30
Feb 05 03:11:22 server kernel: nvme nvme0: I/O 129 QID 7 timeout, aborting
Feb 05 03:11:23 server kernel: EXT4-fs warning (device dm-0): ext4_end_bio:344: I/O error 10 writing to inode 262402 starting block 8392704

Signification : Les avertissements noyau filtrés vous donnent une narration d’erreurs concise.

Décision : Si des avertissements filesystem apparaissent, planifiez un contrôle de filesystem contrôlé et inspectez immédiatement le stockage sous-jacent.

Tâche 13 : Erreurs réseau qui se déguisent en « problèmes stockage »

cr0x@server:~$ ip -s link show dev ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      123456789  7654321      0       0       0       0

Signification : Les drops et erreurs provoquent retransmissions et timeouts qui ressemblent à « la base de données est lente ».

Décision : Si les drops augmentent, vérifiez le pilote/firmware du NIC, les tampons d’anneaux, et la congestion en amont avant de démonter le stockage.

Tâche 14 : Synchronisation temporelle et discipline d’horloge

cr0x@server:~$ timedatectl
               Local time: Mon 2026-02-05 03:24:11 UTC
           Universal time: Mon 2026-02-05 03:24:11 UTC
                 RTC time: Mon 2026-02-05 03:24:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : Si le temps n’est pas synchronisé, corréler les logs entre systèmes devient de l’interprétation.

Décision : Si la synchronisation est incorrecte, corrigez NTP/chrony en priorité. L’observabilité sans temps est une danse d’interprétation.

Le bundle en un script (prêt pour la production)

Maintenant, transformons ces tâches en un seul script. Il collecte :

Identité système (OS, noyau, uptime, mode de démarrage)
Inventaire matériel (CPU, mémoire, PCI, USB)
Pilotes/modules et indices de firmware
Topologie et santé du stockage (lsblk, LVM, mdraid, ZFS, multipath si présent)
Erreurs (dmesg avertissements/erreurs, extraits du journal)
État réseau
Un manifeste plus les stderr des commandes

Il fait aussi quelques choses « adultes » : contrôles défensifs, logs bornés dans le temps, et redaction des secrets évidents dans quelques sorties.
La redaction n’est pas parfaite. C’est une ceinture de sécurité, pas l’invincibilité.

cr0x@server:~$ cat sysreport.sh
#!/usr/bin/env bash
set -euo pipefail

# Full system report: hardware + drivers + errors
# Safe-by-default. No benchmarks. No destructive actions.
# Run as root for best results.

ts_utc="$(date -u +%Y%m%dT%H%M%SZ)"
host="$(hostname -s 2>/dev/null || hostname)"
out_root="${SYSREPORT_OUTDIR:-/tmp}"
bundle_dir="${out_root%/}/sysreport-${host}-${ts_utc}"
mkdir -p "$bundle_dir"/{meta,identity,hardware,drivers,storage,network,logs,errors,perf}

manifest="$bundle_dir/meta/manifest.txt"
stderr_log="$bundle_dir/meta/stderr.log"

run() {
  # run "command string" "output-file"
  local cmd="$1"
  local out="$2"
  {
    echo "### CMD: $cmd"
    echo "### WHEN_UTC: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
    echo
    bash -lc "$cmd"
    echo
  } >"$out" 2>>"$stderr_log" || true

  {
    echo "$(date -u +%Y-%m-%dT%H:%M:%SZ)  $out  $cmd"
  } >>"$manifest"
}

have() { command -v "$1" >/dev/null 2>&1; }

redact() {
  # Very light redaction for outputs likely to contain tokens/keys.
  # You should still review before sharing externally.
  sed -E \
    -e 's/(Authorization:)[[:space:]]*Bearer[[:space:]]+[A-Za-z0-9._-]+/\1 Bearer [REDACTED]/Ig' \
    -e 's/([Pp]assword=)[^[:space:]]+/\1[REDACTED]/g' \
    -e 's/([Tt]oken=)[^[:space:]]+/\1[REDACTED]/g'
}

# Identity
run "hostnamectl 2>/dev/null || true" "$bundle_dir/identity/hostnamectl.txt"
run "uname -a" "$bundle_dir/identity/uname.txt"
run "cat /etc/os-release 2>/dev/null || true" "$bundle_dir/identity/os-release.txt"
run "uptime -p; uptime" "$bundle_dir/identity/uptime.txt"
run "who -b 2>/dev/null || true" "$bundle_dir/identity/last-boot-who.txt"
run "test -d /sys/firmware/efi && echo UEFI || echo BIOS" "$bundle_dir/identity/boot-mode.txt"
run "timedatectl 2>/dev/null || true" "$bundle_dir/identity/timedatectl.txt"

# Hardware
run "lscpu" "$bundle_dir/hardware/lscpu.txt"
run "free -h" "$bundle_dir/hardware/free.txt"
run "cat /proc/meminfo" "$bundle_dir/hardware/proc-meminfo.txt"
run "dmidecode -t system -t baseboard -t bios -t processor -t memory 2>/dev/null || true" "$bundle_dir/hardware/dmidecode.txt"
run "lspci -nnk" "$bundle_dir/hardware/lspci-nnk.txt"
run "lsusb -t 2>/dev/null || true" "$bundle_dir/hardware/lsusb-tree.txt"
run "ls -l /dev/disk/by-id 2>/dev/null || true" "$bundle_dir/hardware/dev-disk-by-id.txt"

# Drivers / kernel
run "lsmod" "$bundle_dir/drivers/lsmod.txt"
run "sysctl -a 2>/dev/null | egrep '^(kernel\\.|vm\\.|fs\\.|net\\.)' | head -n 2000" "$bundle_dir/drivers/sysctl-kernel-vm-fs-net.txt"
run "cat /proc/cmdline" "$bundle_dir/drivers/kernel-cmdline.txt"
run "grep -R . /etc/modprobe.d 2>/dev/null || true" "$bundle_dir/drivers/modprobe-d.txt"

# Storage topology
run "lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,ROTA,TRAN,HCTL,FSTYPE,FSVER,UUID,MOUNTPOINTS" "$bundle_dir/storage/lsblk.txt"
run "blkid 2>/dev/null || true" "$bundle_dir/storage/blkid.txt"
run "findmnt -D" "$bundle_dir/storage/findmnt.txt"
run "df -hT" "$bundle_dir/storage/df-ht.txt"
run "mount" "$bundle_dir/storage/mount.txt"

# LVM / mdraid
run "pvs 2>/dev/null || true" "$bundle_dir/storage/lvm-pvs.txt"
run "vgs 2>/dev/null || true" "$bundle_dir/storage/lvm-vgs.txt"
run "lvs -a -o +devices 2>/dev/null || true" "$bundle_dir/storage/lvm-lvs.txt"
run "cat /proc/mdstat 2>/dev/null || true" "$bundle_dir/storage/mdstat.txt"
run "mdadm --detail --scan 2>/dev/null || true" "$bundle_dir/storage/mdadm-detail-scan.txt"

# ZFS (if present)
if have zpool; then
  run "zpool status -v" "$bundle_dir/storage/zpool-status.txt"
  run "zfs list -o name,used,avail,refer,mountpoint,compression,recordsize,atime,primarycache,secondarycache -t filesystem,volume 2>/dev/null || true" "$bundle_dir/storage/zfs-list.txt"
  run "zpool get all 2>/dev/null || true" "$bundle_dir/storage/zpool-get-all.txt"
fi

# Multipath (if present)
if have multipath; then
  run "multipath -ll 2>/dev/null || true" "$bundle_dir/storage/multipath-ll.txt"
fi

# NVMe and SMART (if present)
if have nvme; then
  run "nvme list" "$bundle_dir/storage/nvme-list.txt"
  run "for d in /dev/nvme*n1; do echo '## ' \$d; nvme id-ctrl \$d 2>/dev/null | head -n 80; echo; nvme smart-log \$d 2>/dev/null; echo; done" "$bundle_dir/storage/nvme-health.txt"
fi

if have smartctl; then
  run "lsblk -dn -o NAME,TYPE | awk '\$2==\"disk\"{print \"/dev/\"\$1}' | while read -r d; do echo '## ' \$d; smartctl -a \$d 2>/dev/null | head -n 120; echo; done" "$bundle_dir/storage/smartctl-head.txt"
fi

# Performance snapshots (safe)
run "vmstat 1 5" "$bundle_dir/perf/vmstat.txt"
run "iostat -xz 1 3 2>/dev/null || true" "$bundle_dir/perf/iostat.txt"
run "pidstat 1 3 2>/dev/null || true" "$bundle_dir/perf/pidstat.txt"
run "top -b -n 1 | head -n 80" "$bundle_dir/perf/top.txt"

# Network
run "ip -br link" "$bundle_dir/network/ip-link.txt"
run "ip -s link" "$bundle_dir/network/ip-link-stats.txt"
run "ip addr" "$bundle_dir/network/ip-addr.txt"
run "ip route" "$bundle_dir/network/ip-route.txt"
run "ss -s" "$bundle_dir/network/ss-summary.txt"
run "ss -tupna 2>/dev/null | head -n 2000" "$bundle_dir/network/ss-sockets.txt"

# Logs / errors (time-bounded)
run "dmesg -T" "$bundle_dir/logs/dmesg.txt"
run "dmesg -T --level=err,warn" "$bundle_dir/errors/dmesg-warn-err.txt"

if have journalctl; then
  run "journalctl -b --no-pager -n 3000" "$bundle_dir/logs/journal-this-boot-tail.txt"
  run "journalctl -k -b --no-pager -p warning..alert" "$bundle_dir/errors/journal-kernel-warning-alert.txt"
  run "journalctl -b --no-pager -p err..alert --since '24 hours ago'" "$bundle_dir/errors/journal-errors-24h.txt"
  run "journalctl --list-boots --no-pager" "$bundle_dir/logs/journal-boot-list.txt"
fi

# A light touch of redaction on socket listings (can include tokens in args on some systems)
if [ -f "$bundle_dir/network/ss-sockets.txt" ]; then
  redact <"$bundle_dir/network/ss-sockets.txt" >"$bundle_dir/network/ss-sockets.redacted.txt"
fi

# Meta
run "id; umask; ulimit -a" "$bundle_dir/meta/runtime.txt"
run "dpkg -l 2>/dev/null | head -n 4000 || true" "$bundle_dir/meta/packages-dpkg.txt"
run "rpm -qa 2>/dev/null | head -n 4000 || true" "$bundle_dir/meta/packages-rpm.txt"

# Bundle
tarball="${bundle_dir}.tar.gz"
tar -C "$out_root" -czf "$tarball" "$(basename "$bundle_dir")" 2>>"$stderr_log" || true

echo "Wrote: $tarball"
echo "Manifest: $manifest"
echo "Stderr log: $stderr_log"

Comment l’exécuter

cr0x@server:~$ sudo bash sysreport.sh
Wrote: /tmp/sysreport-server-20260205T032411Z.tar.gz
Manifest: /tmp/sysreport-server-20260205T032411Z/meta/manifest.txt
Stderr log: /tmp/sysreport-server-20260205T032411Z/meta/stderr.log

Signification : Vous obtenez une seule archive tar que vous pouvez joindre à un ticket d’incident, partager en interne, ou comparer à un hôte « connu bon ».

Décision : Si stderr contient de nombreuses erreurs de permission, relancez en root ou acceptez explicitement la visibilité réduite et documentez-la.

Comment lire le bundle comme un SRE, pas comme un touriste

Commencez par les erreurs, puis confirmez la topologie

Le chemin le plus rapide est généralement :

errors/dmesg-warn-err.txt et errors/journal-kernel-warning-alert.txt
hardware/lspci-nnk.txt pour mapper périphériques et pilotes
storage/lsblk.txt et l’état RAID/ZFS pour voir la pile de stockage réelle
perf/vmstat.txt et perf/iostat.txt (si disponibles) pour orienter le goulot

Recherchez ces « indicateurs »

Boucles de reset : « controller is down; will reset » qui se répète n’est pas du bruit normal.
Plainte filesystem : avertissements ext4/xfs suivent souvent une défaillance de périphérique réelle. La cause racine est généralement en dessous.
Désalignement pilote : un pilote NIC en service qui ne correspond pas au standard de la flotte est une dérive et un risque futur.
Redondance dégradée : mdraid sans [UU], ZFS dégradé, multipath avec chemins manquants. Cela transforme des hic mineurs en pannes.
Thermiques : température élevée plus erreurs PCIe est un motif réel, surtout dans les racks densément peuplés.

Citation (idée paraphrasée) de W. Edwards Deming : « Vous ne pouvez pas améliorer ce que vous ne mesurez pas. » En ops : vous ne pouvez pas réparer ce que vous n’avez pas capturé.

Blague #2 : Un « correctif rapide » n’est qu’un long incident portant une fausse moustache.

Trois mini-histoires d’entreprise (et les leçons qu’elles ont achetées)

Mini-histoire 1 : La panne causée par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un dépôt d’artefacts interne sur une paire de serveurs « identiques ». Même modèle CPU, même taille RAM, même image distro.
L’équipe supposait que le stockage était aussi identique, parce que les achats indiquaient « NVMe 2 To » sur les deux lignes. Assez proche, non ?

L’incident a commencé par des pics de latence intermittents. Les graphiques applicatifs ressemblaient à un peigne : tout va bien, puis une dent aiguë.
L’astreinte a vérifié le CPU (ok), la mémoire (ok), le réseau (ok). Ils ont redémarré le service. Les pics ont disparu pendant une heure, puis sont revenus.
Classique « ça marche après un redémarrage ».

Quand ils ont finalement exécuté un vrai bundle de rapport système, la différence était dans storage/nvme-list.txt :
un hôte avait un modèle NVMe et une révision firmware différents. Le journal noyau montrait des resets périodiques du contrôleur sur ce périphérique précis.
Sous la charge, le firmware du disque atteignait un coin bizarre, le contrôleur déraillait, le noyau le réinitialisait, l’I/O se bloquait,
et l’appli paraissait « lente ».

La mauvaise hypothèse n’était pas « NVMe est rapide ». C’était « même capacité = même comportement ». Le stockage n’est pas une commodité ; c’est une personnalité.
Même interface, firmware différent, modes de panne différents.

La correction fut ennuyeuse : ils ont standardisé le modèle/révision des disques et ajouté le bundle en un script à leur checklist d’incident.
La prochaine fois que les achats ont changé de pièces, ils ont détecté la dérive en staging plutôt que pendant le trafic client.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une équipe finance avait une pipeline de traitement de fichiers sur un ext4 au-dessus de LVM. Ça allait « bien » jusqu’à la fin du mois où
le débit a chuté et le job a manqué sa fenêtre. Quelqu’un a proposé une optimisation audacieuse : monter avec des options agressives,
désactiver atime, tweaker les dirty ratios, et activer discard partout pour « préserver les SSD ».

Après le changement, le pipeline a d’abord accéléré. On a célébré. Puis est venue la lente dégradation : des stalls sporadiques lors de pics d’écriture.
La latence a empiré, pas diminué. Le bundle de rapport (collecté après coup, bien sûr) a montré deux coupables.

D’abord, les options de montage et les valeurs sysctl s’étaient éloignées des valeurs par défaut de la distro sans raison écrite.
Ensuite, les logs noyau contenaient des timeouts NVMe pendant une forte activité de discard. L’« optimisation » avait aligné les opérations de discard
avec les écritures en rafale du pipeline. Le firmware du SSD n’a pas apprécié. Le pattern de reset du contrôleur est revenu, et les fenêtres manquées aussi.

La leçon : les ajustements de performance qui modifient les patterns d’I/O peuvent exposer des bugs firmware et des limites de contrôleur. Les valeurs par défaut ne sont pas sacrées,
mais elles sont éprouvées. Si vous voulez tuner, faites-le avec un plan de rollback et de l’instrumentation, pas des intuitions.

L’équipe est revenue à discard programmé/contrôlé (ou l’a désactivé quand le périphérique le gérait en interne),
a restauré des réglages dirty sensés, et a exigé que tout tuning noyau/stockage soit documenté dans le répertoire « meta » du bundle comme note de changement.
Le pipeline est redevenu ennuyeux. L’ennui est ce qu’on veut en finance.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation du secteur santé (réglementée, prudente, allergique aux surprises) maintenait un « snapshot de bundle de support » hebdomadaire
pour chaque hôte de base de données en production. Ce n’était pas sophistiqué : lancez le script, stockez la tarball, conservez une fenêtre roulante.
Les ingénieurs se plaignaient que c’était du travail fastidieux. Ça ne ressemblait pas à du progrès. Ça ressemblait à du fil dentaire.

Puis un cluster a commencé à générer des avertissements filesystem occasionnels. Rien de catastrophique, juste assez pour rendre tout le monde nerveux.
L’astreinte a récupéré le dernier bundle et l’a comparé à celui de la semaine précédente du même hôte et de son pair.
Les différences sont apparues immédiatement : une mise à jour du noyau avait été appliquée sur un nœud mais pas sur l’autre, et la version du pilote contrôleur stockage avait changé avec elle.

Ils ont aussi remarqué une petite hausse des entrées d’erreurs NVMe sur le nœud mis à jour — visible dans les logs SMART NVMe sauvegardés —
plus une augmentation correspondante des avertissements noyau. Sans les bundles historiques, il aurait été difficile de prouver la causalité.
Avec eux, c’était évident : ce n’était pas du « matériel aléatoire ». C’était un changement + symptôme.

L’équipe a figé la version du noyau sur le cluster, planifié une fenêtre de maintenance, et testé une combinaison pilote/firmware plus récente en staging.
Les avertissements ont cessé. La pratique des snapshots ennuyeux a été remboursée en un incident en transformant un mystère en rollback contrôlé.

Voilà le gain sous-estimé : les bundles de support ne sont pas seulement pour les fournisseurs. Ils servent aussi vous, une semaine plus tard, quand votre mémoire est fiction.

Erreurs courantes : symptôme → cause racine → correctif

Ce ne sont pas des abstractions. J’ai vu des équipes perdre des heures (ou des weekends) à cause de chacune d’elles.

1) Symptom : « Charge moyenne élevée » → Cause racine : attente I/O et tâches bloquées → Fix : vérifier latence stockage et logs noyau

Ce que vous voyez : La charge moyenne est élevée, le CPU semble en grande partie idle, les utilisateurs disent « le CPU est saturé ».
Cause racine : Les tâches sont en sommeil ininterruptible en attente d’I/O.
Fix : Utilisez vmstat, iostat et les logs noyau ; puis mappez les appareils lents via lsblk et le contrôleur via lspci.
Si dmesg montre des timeouts/resets, escaladez vers matérielle/firmware.

2) Symptom : « Erreurs filesystem aléatoires » → Cause racine : resets de périphérique sous-jacent → Fix : arrêter de traiter ça comme un problème filesystem d’abord

Ce que vous voyez : avertissements ext4/xfs, remontages en lecture seule occasionnels, messages de journal.
Cause racine : Le disque/contrôleur flanche ; le filesystem est le messager.
Fix : Collectez SMART/NVMe logs, versions pilote contrôleur, et recherchez erreurs PCIe dans dmesg. Remplacez/upgradez si nécessaire ; puis réparez le filesystem.

3) Symptom : « NIC perd des paquets sous charge » → Cause racine : mismatch pilote/firmware ou réglages offload → Fix : confirmer version pilote et état du lien

Ce que vous voyez : drops de paquets, retransmissions en hausse, applis qui timeout.
Cause racine : Mismatch firmware NIC et pilote noyau, ou mauvaise combinaison d’offloads.
Fix : Vérifiez lspci -nnk et modinfo. Standardisez pilote/firmware ; validez les offloads de façon contrôlée.

4) Symptom : « Le fournisseur n’aide pas; il veut plus d’info » → Cause racine : le rapport manque versions et topologie → Fix : inclure les fichiers de mapping

Ce que vous voyez : Vous envoyez des logs ; le fournisseur demande modèle matériel, versions pilote, révisions firmware, état RAID.
Cause racine : Vous avez collecté des symptômes mais pas l’identité ni la configuration.
Fix : Assurez-vous que le script inclut lspci -nnk, modinfo, sorties santé stockage, versions OS/noyau, et historique de démarrage.

5) Symptom : « Le bundle est énorme et inutile » → Cause racine : logs non bornés et dumps binaires → Fix : borner dans le temps et résumer

Ce que vous voyez : tarball de 500 Mo que personne ne télécharge.
Cause racine : export complet du journal, liste de paquets complète, copie de /var/log entière.
Fix : Capturez les logs récents (queue du démarrage, erreurs 24 h) et des résumés ciblés ; laissez le reste en option.

6) Symptom : « On ne peut pas partager; il contient des secrets » → Cause racine : collecte négligente → Fix : établir des valeurs sûres et des contrôles

Ce que vous voyez : La sécurité bloque le partage avec le fournisseur, l’incident traîne.
Cause racine : Le script a collecté des configs ou des arguments de processus contenant des identifiants.
Fix : Ne collectez pas de chemins sensibles ; redigez les sorties à risque ; stockez le bundle de façon sécurisée ; ayez une checklist de revue avant partage externe.

Listes de contrôle / plan étape par étape

Checklist A : Construisez votre script en sécurité (une fois)

Définissez l’objectif. Instantané pour réponse d’incident ? Bundle support fournisseur ? Détection de dérive ? (Choisissez un objectif principal.)
Choisissez une structure de sortie stable. identity/, hardware/, drivers/, storage/, network/, logs/, errors/, meta/.
Rendez chaque commande non interactive. Si elle peut bloquer, placez-la derrière un garde « have tool ».
Bornez les logs dans le temps. Queue du démarrage + erreurs 24 h est souvent le bon compromis.
Enregistrez les échecs. Un stderr.log n’est pas optionnel. Les échecs silencieux font perdre du temps.
Ne muter jamais l’état. Pas de rescans, pas de checks filesystem, pas de tuning, pas de mises à jour firmware dans le run par défaut.
Packager. Tarball plus manifeste des commandes lancées.

Checklist B : Lancer lors d’un incident (à chaque fois)

Lancez sur l’hôte affecté d’abord, puis sur un « pair sain » si disponible.
Attachez la tarball au ticket immédiatement. Ne la laissez pas sur votre laptop comme un artefact précieux.
Parcourez meta/stderr.log pour vérifier que vous avez bien capturé l’essentiel.
Commencez l’analyse par errors/. Puis mappez périphériques/pilotes. Ensuite confirmez l’état de redondance.
Notez le « premier horodatage problématique » dans les logs. Utilisez-le pour corréler avec déploiements et changements de config.

Checklist C : Rendre cela apte flotte (la différence entre un script et une pratique)

Stockez des snapshots hebdomadaires pour les tiers critiques (bases de données, nœuds de stockage, load balancers).
Standardisez bases kernel/pilote/firmware par classe matérielle.
Automatisez le diff contre un hôte gold pour la détection de dérive (même un diff grossier est mieux que rien).
Définissez rétention et contrôles d’accès ; les bundles peuvent contenir des détails opérationnels sensibles même si redigés.

FAQ

1) Dois-je exécuter ceci en root ?

Oui, si vous voulez un rapport réellement utile. Root vous donne accès aux logs noyau, à la santé SMART/NVMe, et aux détails de la pile stockage.
Si vous ne pouvez pas lancer en root, exécutez quand même, mais attendez-vous à des données manquantes et notez cette limitation dans le ticket d’incident.

2) La collecte de ces données impactera-t-elle la performance ?

Légèrement. Des commandes comme lspci, lsblk, requêtes journalctl et lectures SMART sont généralement peu impactantes.
Évitez les commandes lourdes (benchmarks, tests SMART longs) dans le script par défaut. Si vous avez besoin de tests actifs, faites-le explicitement et pendant une fenêtre.

3) Pourquoi ne pas tout envoyer à une plateforme de logs et considérer le travail terminé ?

La centralisation des logs est excellente — jusqu’à ce qu’elle échoue. Les bundles capturent la « vérité locale » incluant l’identité matérielle, le mapping pilote et la topologie stockage
qui souvent ne sont pas dans votre pipeline de logs. De plus, pendant les pannes, le pipeline de logs est parfois la première victime.

4) Pourquoi inclure à la fois dmesg et journalctl ?

Parce que les environnements varient. Certains systèmes restreignent dmesg pour les non-root, certains font tourner les logs agressivement, et parfois vous avez besoin des deux vues.
Journal ajoute des métadonnées de boot ; dmesg montre le ring buffer noyau tel quel. La redondance est une fonctionnalité, pas du désordre.

5) Comment comparer deux bundles ?

Décompressez-les et différez les fichiers clés : identity/uname.txt, hardware/lspci-nnk.txt, drivers/lsmod.txt,
storage/lsblk.txt, état RAID/ZFS, et logs d’erreurs. Ne differez pas d’abord les logs entiers ; vous allez vous noyer.

6) Et pour les conteneurs et nœuds Kubernetes ?

Exécutez le script sur le nœud, pas dans un conteneur, si vous tenez aux erreurs matériel/pilote. Les conteneurs ne voient pas la vue noyau complète.
Pour Kubernetes, ajoutez l’identité du nœud (version kubelet, info runtime) comme extension optionnelle — mais gardez le script de base générique.

7) Et si des outils comme nvme-cli ou smartmontools ne sont pas installés ?

Le script vérifie la présence des outils et saute proprement. En production, standardisez un jeu minimal d’outils diagnostics par distro.
Ne demandez pas à l’astreint d’installer des paquets pendant une panne sauf si vous aimez créer de nouvelles pannes.

8) Comment garder les secrets hors du rapport ?

D’abord : ne collectez pas de chemins sensibles. Ensuite : logs bornés dans le temps. Troisième : redaction sélective (comme le script le fait pour quelques cas).
Enfin : traitez le bundle comme sensible de toute façon — stockez-le dans des systèmes sécurisés et révisez avant partage externe.

9) Puis-je ajouter des logs applicatifs ?

Vous pouvez, mais soyez discipliné. Ajoutez un flag optionnel séparé (par exemple --app) et gardez-le désactivé par défaut.
Les logs applicatifs sont souvent volumineux et plus susceptibles de contenir des données clients. Le rapport système de base doit rester ciblé.

10) Quel est le fichier le plus précieux dans le bundle ?

Généralement errors/dmesg-warn-err.txt. C’est là où le matériel et les pilotes admettent leurs défaillances. Le deuxième le plus précieux est
hardware/lspci-nnk.txt, car il transforme des erreurs vagues en un périphérique/pilote spécifique sur lequel agir.

Conclusion : prochaines étapes que vous ferez réellement

Un rapport système complet n’est pas un artefact magique. C’est un instantané discipliné : identité, topologie, santé et erreurs — capturés en sécurité,
dans un format diffable et partageable. Le script ci‑dessus est la colonne vertébrale. La pratique est ce qui la rend rentable.

Ajoutez le script à votre repo ops et traitez-le comme du code produit : revu, versionné, testé.
Standardisez un jeu d’outils diagnostics sur vos images pour que le script puisse collecter NVMe/SMART et détails stockage de façon cohérente.
Faites de « collecter le bundle » l’étape zéro dans vos runbooks d’incident, avant tuning, redémarrages ou blâme.
Commencez à conserver des snapshots hebdomadaires pour les systèmes critiques. Vous détesterez ça jusqu’au jour où ça vous sauvera.
Utilisez le bundle pour imposer des baselines : noyau, pilotes, firmware, configuration stockage. La dérive est une panne par versements.