📡 Storage Systems — Chapitre 38 : Monitoring système

Première page de la Partie 12 — Observabilité et monitoring. Ce chapitre couvre le monitoring système du stockage : outils Linux, SMART, NVMe CLI, usage filesystem, RAID monitoring, LVM, multipath, SAN/Fibre Channel, iSCSI, NFS, SMB, ZFS, Btrfs, Ceph, Kubernetes storage, Prometheus exporters, Grafana dashboards, logs système, alerting, capacity planning, détection d’anomalies, runbooks incidents, SLO stockage et checklist production.

Linux toolsSMARTNVMe CLIFilesystem usageRAID monitoringPrometheus / Grafana

38.1

Linux tools

iostat, vmstat, dstat, sar, lsblk, smartctl : boîte à outils de base pour diagnostiquer CPU, mémoire, bloc, FS et disques.

Linuxiostatsar

38.2

SMART

Santé disque, erreurs, température, secteurs réalloués, pending sectors, wear leveling, power-on hours et prédiction panne.

SMARTHealthTemperature

38.3

NVMe CLI

nvme smart-log, health, firmware, error-log, endurance, media errors, thermal throttling et namespace inventory.

NVMesmart-logFirmware

38.4

Filesystem usage

df, du, inodes, quotas, reserved blocks, fragmentation, top directories et détection croissance anormale.

dfduinodes

38.5

RAID monitoring

mdadm, storcli, perccli, arcconf, MegaRAID, BBU, patrol read, rebuild, consistency check et alerting.

RAIDmdadmstorcli

38.6

LVM monitoring

PV/VG/LV, thin pool metadata, snapshots, cache, usage, writecache, device mapper et alertes saturation.

LVMThin poolSnapshots

38.7

Multipath monitoring

DM-Multipath : paths actifs/passifs, ALUA, failover, queue_if_no_path, path errors et asymétrie.

MultipathALUAPaths

38.8

SAN / Fibre Channel

HBA, WWPN, link errors, CRC, buffer credits, zoning, fabric events, latency et path imbalance.

SANFCHBA

38.9

iSCSI monitoring

Sessions, portals, timeouts, retransmits, TCP, multipath, login errors, latency et réseau dédié.

iSCSITCPSessions

38.10

NFS monitoring

nfsstat, nfsiostat, mount stats, retrans, timeouts, rsize/wsize, nconnect, locks et server latency.

NFSnfsiostatretrans

38.11

SMB monitoring

smbstatus, locks, oplocks, sessions, shares, throughput, signing/encryption overhead et fichiers ouverts.

SMBsmbstatuslocks

38.12

ZFS monitoring

zpool status, scrub, resilver, ARC, L2ARC, SLOG, errors, fragmentation, snapshots et capacity headroom.

ZFSARCscrub

38.13

Btrfs monitoring

scrub, balance, device stats, metadata fullness, snapshots, qgroups, COW overhead et space cache.

Btrfsscrubbalance

38.14

Ceph monitoring

OSD, MON, MGR, PG states, recovery, backfill, slow ops, CRUSH, disk health et cluster capacity.

CephOSDPG

38.15

Kubernetes storage monitoring

PVC/PV, CSI, VolumeSnapshot, node disk pressure, kubelet eviction, Longhorn/Ceph/OpenEBS metrics.

K8sPVCCSI

38.16

Prometheus exporters

node_exporter, smartctl_exporter, nvme_exporter, ceph exporter, blackbox, custom scripts et labels.

PrometheusExportersMetrics

38.17

Grafana dashboards

Dashboards stockage : capacity, latency, IOPS, queue, SMART, RAID, NVMe, filesystems, alerts et drill-down.

GrafanaDashboardsDrill-down

38.18

Logs système

journalctl, dmesg, kernel I/O errors, SCSI sense, NVMe errors, filesystem warnings et corrélation temporelle.

Logsdmesgjournalctl

38.19

Alerting et seuils

Seuils critiques : capacity, inodes, latency p99, SMART failure, rebuild, snapshot growth, replication lag et backup failure.

AlertsThresholdsSLO

38.20

Capacity planning

Prévoir croissance : taux quotidien, saisonnalité, headroom, thin provisioning, snapshots, compression et seuils budget.

CapacityForecastHeadroom

38.21

Détection anomalies

Détecter dérives : IOPS spike, latency tail, mass delete, entropy, disk wear, temperature, noisy neighbor et runaway logs.

AnomalyDriftSpike

38.22

Runbooks incidents monitoring

Disque dégradé, FS full, inodes full, RAID rebuild, NVMe overheating, NFS timeouts, SAN path down.

RunbookIncidentTriage

38.23

SLO stockage

Définir SLO/SLA : disponibilité, latence p99, capacité, RPO/RTO, restore confidence et error budget.

SLOSLAError budget

38.24

Checklist monitoring stockage

GO/NO-GO : exporters, logs, alertes, dashboards, runbooks, tests alertes, owners, escalade et preuves.

ChecklistGO/NO-GOOwners

38.1 Linux tools

Définition opérationnelle

iostat, vmstat, dstat, sar, lsblk, smartctl : boîte à outils de base pour diagnostiquer CPU, mémoire, bloc, FS et disques.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.2 SMART

Définition opérationnelle

Santé disque, erreurs, température, secteurs réalloués, pending sectors, wear leveling, power-on hours et prédiction panne.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.3 NVMe CLI

Définition opérationnelle

nvme smart-log, health, firmware, error-log, endurance, media errors, thermal throttling et namespace inventory.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.4 Filesystem usage

Définition opérationnelle

df, du, inodes, quotas, reserved blocks, fragmentation, top directories et détection croissance anormale.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.5 RAID monitoring

Définition opérationnelle

mdadm, storcli, perccli, arcconf, MegaRAID, BBU, patrol read, rebuild, consistency check et alerting.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.6 LVM monitoring

Définition opérationnelle

PV/VG/LV, thin pool metadata, snapshots, cache, usage, writecache, device mapper et alertes saturation.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.7 Multipath monitoring

Définition opérationnelle

DM-Multipath : paths actifs/passifs, ALUA, failover, queue_if_no_path, path errors et asymétrie.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.8 SAN / Fibre Channel

Définition opérationnelle

HBA, WWPN, link errors, CRC, buffer credits, zoning, fabric events, latency et path imbalance.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.9 iSCSI monitoring

Définition opérationnelle

Sessions, portals, timeouts, retransmits, TCP, multipath, login errors, latency et réseau dédié.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.10 NFS monitoring

Définition opérationnelle

nfsstat, nfsiostat, mount stats, retrans, timeouts, rsize/wsize, nconnect, locks et server latency.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.11 SMB monitoring

Définition opérationnelle

smbstatus, locks, oplocks, sessions, shares, throughput, signing/encryption overhead et fichiers ouverts.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.12 ZFS monitoring

Définition opérationnelle

zpool status, scrub, resilver, ARC, L2ARC, SLOG, errors, fragmentation, snapshots et capacity headroom.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.13 Btrfs monitoring

Définition opérationnelle

scrub, balance, device stats, metadata fullness, snapshots, qgroups, COW overhead et space cache.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.14 Ceph monitoring

Définition opérationnelle

OSD, MON, MGR, PG states, recovery, backfill, slow ops, CRUSH, disk health et cluster capacity.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.15 Kubernetes storage monitoring

Définition opérationnelle

PVC/PV, CSI, VolumeSnapshot, node disk pressure, kubelet eviction, Longhorn/Ceph/OpenEBS metrics.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.16 Prometheus exporters

Définition opérationnelle

node_exporter, smartctl_exporter, nvme_exporter, ceph exporter, blackbox, custom scripts et labels.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.17 Grafana dashboards

Définition opérationnelle

Dashboards stockage : capacity, latency, IOPS, queue, SMART, RAID, NVMe, filesystems, alerts et drill-down.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.18 Logs système

Définition opérationnelle

journalctl, dmesg, kernel I/O errors, SCSI sense, NVMe errors, filesystem warnings et corrélation temporelle.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.19 Alerting et seuils

Définition opérationnelle

Seuils critiques : capacity, inodes, latency p99, SMART failure, rebuild, snapshot growth, replication lag et backup failure.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.20 Capacity planning

Définition opérationnelle

Prévoir croissance : taux quotidien, saisonnalité, headroom, thin provisioning, snapshots, compression et seuils budget.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.21 Détection anomalies

Définition opérationnelle

Détecter dérives : IOPS spike, latency tail, mass delete, entropy, disk wear, temperature, noisy neighbor et runaway logs.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.22 Runbooks incidents monitoring

Définition opérationnelle

Disque dégradé, FS full, inodes full, RAID rebuild, NVMe overheating, NFS timeouts, SAN path down.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.23 SLO stockage

Définition opérationnelle

Définir SLO/SLA : disponibilité, latence p99, capacité, RPO/RTO, restore confidence et error budget.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.

38.24 Checklist monitoring stockage

Définition opérationnelle

GO/NO-GO : exporters, logs, alertes, dashboards, runbooks, tests alertes, owners, escalade et preuves.

Point clé : observer le stockage exige une vision multi-couches : application, OS, filesystem, bloc, réseau, baie, cloud, sauvegarde et capacité. Une métrique isolée ne suffit presque jamais.

Pipeline observabilité

Metrics→Logs→Events→Dashboards→Alerts→Runbooks

Monitoring utile = signal actionnable + seuil justifié + owner + runbook + test d’escalade.

Composants à instrumenter

Composant	Rôle / explication
Metric source	Kernel, block layer, filesystem, controller RAID, NVMe, SMART, SAN/NAS, cloud API, application.
Collector	Commandes Linux, Prometheus exporters, agents, syslog, journald, SNMP, REST APIs, vendor tools.
Storage signals	Capacity, inodes, IOPS, latency, throughput, queue, errors, retries, temperature, wear, rebuild.
Correlation	Aligner métriques storage avec CPU, mémoire, réseau, application, backups, snapshots, replication and deploys.
Alerting	Seuils, burn rate, alert fatigue, escalation, ownership, severity, maintenance windows and deduplication.
Evidence	Dashboards, logs, incident timeline, commands outputs, before/after graphs and postmortem artifacts.

Cas d’usage

Détecter disque en pré-failure avant panne
Diagnostiquer latence storage p99
Prévenir filesystem full ou inodes full
Surveiller RAID rebuild ou path SAN down
Corréler erreurs kernel et problèmes application
Construire dashboards NOC/SRE pour stockage

Collect→Normalize→Correlate→Alert→Triage→Postmortem

Apports

Transforme les incidents storage en signaux actionnables
Permet capacity planning et budget prévisible
Réduit MTTR avec runbooks et corrélation temporelle
Détecte dérives avant panne utilisateur
Rend exploitation auditée et transmissible

Risques / limites

Trop d’alertes non priorisées génèrent fatigue
Dashboard joli mais sans owner ni runbook
Seuils statiques non adaptés aux workloads
Métriques hôte sans métriques baie/cloud
Absence de test d’alerte et d’escalade réelle

Matrice de décision monitoring storage

Question	Décision à prendre
Quel niveau observer ?	Hôte, filesystem, bloc, RAID, SAN/NAS, object, cloud, Kubernetes, application et backup.
Quelle métrique critique ?	Capacity, inodes, p99 latency, IOPS, throughput, error rate, SMART health, rebuild state, replication lag.
Quel seuil ?	Seuil statique, baseline dynamique, burn rate, seuil par workload, fenêtre temporelle et maintenance.
Quel owner ?	Chaque alerte doit avoir responsable, escalade, documentation, impact et runbook.
Quelle preuve ?	Dashboard, logs, commands output, incident timeline, ticket, postmortem et actions correctives.
Quel test ?	Simuler disk full, inode full, exporter down, SMART warning, path down, backup fail et vérifier escalade.

Règle pratique : pas d’alerte sans action ; pas de dashboard sans owner ; pas de monitoring sans test d’incident.

Runbook monitoring système storage

Inventorier disques, volumes, filesystems, RAID, SAN/NAS mounts, PVC, buckets et backups.
Activer collecte : node_exporter, smartctl/nvme exporter, logs kernel, vendor tools, SNMP/API.
Créer dashboards : capacity, latency, IOPS, throughput, queue, errors, health, rebuild, snapshots.
Définir alertes critiques : disk failing, FS full, inode full, path down, RAID degraded, high p99, backup fail.
Documenter runbook par alerte avec commandes, owner, escalade, rollback et validation.
Tester alertes en environnement contrôlé et corriger bruit/faux positifs.
Revoir seuils chaque trimestre avec croissance capacité et incidents réels.

# Linux storage monitoring quick checks
iostat -x 1
vmstat 1
sar -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT,FSTYPE
df -hT
df -ih
du -xhd1 /data | sort -h
journalctl -k -p warning --since "24 hours ago"
dmesg -T | egrep -i "error|fail|timeout|reset|nvme|scsi|blk|xfs|ext4"

# Disk / NVMe health
smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
nvme list

# RAID / multipath
cat /proc/mdstat
mdadm --detail /dev/md0
storcli /c0 show all
perccli /c0 show all
multipath -ll

# NFS / SMB / ZFS
nfsstat -m
nfsiostat 1
smbstatus
zpool status -v
zpool iostat -v 1

NO-GO : production sans alerte disk full/inode full, sans santé disque, sans logs kernel, sans runbook RAID/path down, ou sans test de restauration/backup associé.