☁️ Storage Systems — Chapitre 39 : Monitoring enterprise et cloud

Chapitre dense consacré au monitoring stockage à l’échelle entreprise et cloud : Prometheus exporters, Grafana dashboards, CloudWatch, Azure Monitor, Google Cloud Monitoring, alerting, capacity planning, SLO/SLA, multi-cloud, AWS/Azure/GCP storage metrics, object storage, backup, snapshots, réplication, sécurité, FinOps, outils constructeurs, SNMP/REST/syslog, CMDB/tags, incident management, AIOps, dashboards direction, runbooks et checklist production.

Prometheus exportersGrafana dashboardsCloud monitoringAlertingCapacity planningFinOps

39.1

Prometheus exporters

node_exporter, smartctl_exporter, ceph_exporter : collecter métriques stockage hôte, disques, clusters et services.

PrometheusExportersMetrics

39.2

Grafana dashboards

Latence, IOPS, capacité, erreurs, santé disque, saturation, snapshots, réplication et drill-down opérationnel.

GrafanaDashboardsLatency

39.3

Cloud monitoring

CloudWatch, Azure Monitor, Google Cloud Monitoring : disques, buckets, files, snapshots, API, quotas et throttling.

CloudWatchAzure MonitorGCP

39.4

Alerting

Capacité, erreurs disque, latence, snapshots échoués, backup failed, replication lag, public buckets et SLO burn rate.

AlertingSLOIncidents

39.5

Capacity planning

Prévision d’épuisement stockage : croissance, saisonnalité, snapshots, retention, compression, thin provisioning et budget.

CapacityForecastBudget

39.6

SLO/SLA enterprise storage

Définir objectifs : disponibilité, latence p99, RPO/RTO, restore confidence, error budget et engagements métiers.

SLOSLAError budget

39.7

Monitoring multi-cloud

Comparer AWS, Azure, GCP, OVH, Scaleway : métriques hétérogènes, tags, coûts, latence, régions et quotas.

Multi-cloudTagsRegions

39.8

AWS storage monitoring

EBS, EFS, FSx, S3 : BurstBalance, VolumeQueueLength, latency, request metrics, replication, lifecycle et costs.

AWSEBSS3

39.9

Azure storage monitoring

Managed Disks, Blob, Files, NetApp Files : transactions, ingress/egress, throttling, availability, capacity et alerts.

AzureBlobDisks

39.10

Google Cloud storage monitoring

Persistent Disk, Hyperdisk, Filestore, GCS : IOPS, throughput, latency, operations, quota, bucket metrics.

GCPGCSHyperdisk

39.11

Object storage monitoring

S3-compatible : request rate, 4xx/5xx, lifecycle, Object Lock, replication lag, inventory, size, versions et delete markers.

ObjectS3API

39.12

Backup monitoring

Suivre jobs, succès/échec, durée, throughput, immutability, last restore test, RPO réel et capacity repository.

BackupRPORestore

39.13

Snapshot monitoring

Snapshots échoués, croissance, âge, orphan snapshots, consistency groups, retention, quota et coûts cachés.

SnapshotsRetentionCosts

39.14

Replication monitoring

Lag, RPO réel, broken sessions, resync, bandwidth, queue, consistency, failover readiness et alertes DR.

ReplicationLagDR

39.15

Security monitoring stockage

Buckets publics, IAM changes, KMS decrypt spike, mass delete, ransomware behavior, admin logins et policy drift.

SecurityIAMKMS

39.16

FinOps monitoring stockage

Coûts stockage, egress, retrieval, API calls, snapshots, versions, orphan volumes, cold tiers et rightsizing.

FinOpsEgressRightsizing

39.17

Outils constructeurs enterprise

Dell CloudIQ, NetApp Active IQ/BlueXP, HPE GreenLake/InfoSight, IBM Storage Insights, Pure1, Hitachi Ops Center.

Vendor toolsAIOpsEnterprise

39.18

SNMP, REST API et syslog

Intégrer baies, NAS, SAN switches, UPS, tape libraries : traps, polling, REST, syslog et normalisation.

SNMPRESTSyslog

39.19

CMDB, tags et ownership

Relier métriques à applications, owners, coûts, environnements, criticité, RPO/RTO, data classification et tickets.

CMDBTagsOwners

39.20

Incident management

PagerDuty/Opsgenie/ServiceNow/Jira : sévérité, escalade, déduplication, maintenance windows et postmortems.

IncidentEscalationPostmortem

39.21

AIOps et détection d’anomalies

Détecter dérives : seasonality, burst, p99, capacity runway, noisy neighbor, ransomware, firmware regression et forecast.

AIOpsAnomalyForecast

39.22

Dashboards direction / executive

Vue C-level : capacité, risque, coûts, disponibilité, cyber readiness, RPO/RTO, incidents, compliance et dette technique.

ExecutiveRiskCost

39.23

Runbooks enterprise monitoring

Alertes storage : qui reçoit, quoi vérifier, comment escalader, quelle preuve collecter, comment clôturer et améliorer.

RunbookOpsEvidence

39.24

Checklist monitoring enterprise/cloud

GO/NO-GO : exporters, cloud metrics, alert routing, dashboards, tags, cost, security, RPO/RTO, owners et tests.

ChecklistGO/NO-GOCloud

39.1 Prometheus exporters

Définition opérationnelle

node_exporter, smartctl_exporter, ceph_exporter : collecter métriques stockage hôte, disques, clusters et services.

Point clé : le monitoring enterprise ne consiste pas seulement à collecter des métriques. Il doit relier stockage, cloud, coûts, owners, SLA, sécurité, RPO/RTO et décisions d’exploitation.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.2 Grafana dashboards

Définition opérationnelle

Latence, IOPS, capacité, erreurs, santé disque, saturation, snapshots, réplication et drill-down opérationnel.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.3 Cloud monitoring

Définition opérationnelle

CloudWatch, Azure Monitor, Google Cloud Monitoring : disques, buckets, files, snapshots, API, quotas et throttling.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.4 Alerting

Définition opérationnelle

Capacité, erreurs disque, latence, snapshots échoués, backup failed, replication lag, public buckets et SLO burn rate.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.5 Capacity planning

Définition opérationnelle

Prévision d’épuisement stockage : croissance, saisonnalité, snapshots, retention, compression, thin provisioning et budget.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.6 SLO/SLA enterprise storage

Définition opérationnelle

Définir objectifs : disponibilité, latence p99, RPO/RTO, restore confidence, error budget et engagements métiers.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.7 Monitoring multi-cloud

Définition opérationnelle

Comparer AWS, Azure, GCP, OVH, Scaleway : métriques hétérogènes, tags, coûts, latence, régions et quotas.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.8 AWS storage monitoring

Définition opérationnelle

EBS, EFS, FSx, S3 : BurstBalance, VolumeQueueLength, latency, request metrics, replication, lifecycle et costs.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.9 Azure storage monitoring

Définition opérationnelle

Managed Disks, Blob, Files, NetApp Files : transactions, ingress/egress, throttling, availability, capacity et alerts.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.10 Google Cloud storage monitoring

Définition opérationnelle

Persistent Disk, Hyperdisk, Filestore, GCS : IOPS, throughput, latency, operations, quota, bucket metrics.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.11 Object storage monitoring

Définition opérationnelle

S3-compatible : request rate, 4xx/5xx, lifecycle, Object Lock, replication lag, inventory, size, versions et delete markers.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.12 Backup monitoring

Définition opérationnelle

Suivre jobs, succès/échec, durée, throughput, immutability, last restore test, RPO réel et capacity repository.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.13 Snapshot monitoring

Définition opérationnelle

Snapshots échoués, croissance, âge, orphan snapshots, consistency groups, retention, quota et coûts cachés.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.14 Replication monitoring

Définition opérationnelle

Lag, RPO réel, broken sessions, resync, bandwidth, queue, consistency, failover readiness et alertes DR.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.15 Security monitoring stockage

Définition opérationnelle

Buckets publics, IAM changes, KMS decrypt spike, mass delete, ransomware behavior, admin logins et policy drift.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.16 FinOps monitoring stockage

Définition opérationnelle

Coûts stockage, egress, retrieval, API calls, snapshots, versions, orphan volumes, cold tiers et rightsizing.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.17 Outils constructeurs enterprise

Définition opérationnelle

Dell CloudIQ, NetApp Active IQ/BlueXP, HPE GreenLake/InfoSight, IBM Storage Insights, Pure1, Hitachi Ops Center.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.18 SNMP, REST API et syslog

Définition opérationnelle

Intégrer baies, NAS, SAN switches, UPS, tape libraries : traps, polling, REST, syslog et normalisation.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.19 CMDB, tags et ownership

Définition opérationnelle

Relier métriques à applications, owners, coûts, environnements, criticité, RPO/RTO, data classification et tickets.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.20 Incident management

Définition opérationnelle

PagerDuty/Opsgenie/ServiceNow/Jira : sévérité, escalade, déduplication, maintenance windows et postmortems.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.21 AIOps et détection d’anomalies

Définition opérationnelle

Détecter dérives : seasonality, burst, p99, capacity runway, noisy neighbor, ransomware, firmware regression et forecast.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.22 Dashboards direction / executive

Définition opérationnelle

Vue C-level : capacité, risque, coûts, disponibilité, cyber readiness, RPO/RTO, incidents, compliance et dette technique.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.23 Runbooks enterprise monitoring

Définition opérationnelle

Alertes storage : qui reçoit, quoi vérifier, comment escalader, quelle preuve collecter, comment clôturer et améliorer.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.

39.24 Checklist monitoring enterprise/cloud

Définition opérationnelle

GO/NO-GO : exporters, cloud metrics, alert routing, dashboards, tags, cost, security, RPO/RTO, owners et tests.

Architecture monitoring enterprise

Exporters→Cloud metrics→Vendor APIs→Dashboards→Alerting→Runbooks

Observabilité enterprise = métriques + logs + owners + coûts + risques + runbooks + preuves.

Composants à instrumenter

Composant	Rôle / explication
Metric plane	Prometheus, cloud metrics, vendor APIs, SNMP, syslog, logs, traces and synthetic checks.
Data model	Labels, tags, owners, environment, region, account, workload, service tier, cost center and CMDB link.
Dashboards	Operational drill-down, service dashboard, capacity runway, executive risk view and FinOps view.
Alert routing	Severity, escalation, maintenance windows, deduplication, grouping, on-call schedule and ownership.
Governance	SLO/SLA, RPO/RTO, compliance evidence, audit trail, postmortem, review cadence and budget planning.
Automation	Runbooks, remediation scripts, IaC checks, anomaly detection, ticketing and evidence collection.

Cas d’usage

Surveiller un parc stockage hybride datacenter + cloud
Centraliser alertes AWS/Azure/GCP et baies enterprise
Prévoir saturation capacité et budget
Suivre RPO/RTO réel et état des snapshots/backups
Détecter incidents sécurité : buckets publics, mass delete, KMS spikes
Produire dashboards direction et preuves d’audit

Collect→Normalize labels→Correlate cost/risk→Alert route→Runbook→Postmortem

Apports

Unifie vision technique, financière et risque
Réduit MTTR avec alert routing et runbooks
Améliore capacity planning et FinOps
Rend le stockage compréhensible par métiers et direction
Transforme observabilité en gouvernance opérationnelle

Risques / limites

Trop de métriques sans modèle de données commun
Tags/owners absents rendant alertes inexploitées
Cloud metrics non corrélées avec application et coûts
Alert fatigue si seuils et déduplication mal conçus
Dashboards non testés en situation d’incident

Matrice de décision monitoring enterprise/cloud

Question	Décision à prendre
Quel périmètre ?	Datacenter, cloud, multi-cloud, NAS/SAN/Object, backup, Kubernetes, databases, vendors et applications critiques.
Quel modèle de tags ?	owner, app, env, region, account, cost_center, data_class, service_tier, rpo, rto, retention.
Quelle plateforme ?	Prometheus/Grafana, cloud-native monitoring, vendor AIOps, SIEM, ITSM ou plateforme unifiée.
Quelles alertes ?	Capacity runway, latency p99, error rate, failed snapshots, replication lag, backup failure, public exposure, cost anomaly.
Quel routage ?	On-call, severity, escalation, maintenance windows, suppression rules, deduplication et ownership.
Quelle preuve ?	Dashboards exportés, tickets, postmortems, runbooks testés, alert history, cost reports et compliance evidence.

Règle pratique : une métrique cloud sans tag owner et sans coût associé est rarement actionnable en entreprise.

Runbook monitoring enterprise/cloud

Définir taxonomie des tags : owner, application, environnement, criticité, région, compte, coût et RPO/RTO.
Brancher sources : Prometheus exporters, CloudWatch, Azure Monitor, Google Cloud Monitoring, vendor APIs, syslog/SNMP.
Créer dashboards : ops, capacity, DR, security, cloud cost, executive risk et service-level views.
Définir alertes et routage : sévérité, déduplication, maintenance, escalation et ownership.
Tester incidents : bucket public, snapshot failed, replication lag, disk full, cost spike, exporter down.
Collecter preuves : graphes, logs, ticket, commandes, décisions, postmortem et actions correctives.
Revoir chaque mois : coûts, capacité, seuils, owners, dette technique et alert fatigue.

# Prometheus examples
up{job=~"node|smartctl|ceph"}
node_filesystem_avail_bytes / node_filesystem_size_bytes
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])
node_disk_io_time_seconds_total
smartctl_device_smart_healthy
ceph_health_status

# AWS CLI examples
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeQueueLength --start-time 2026-01-01T00:00:00Z --end-time 2026-01-01T01:00:00Z --period 300 --statistics Average --dimensions Name=VolumeId,Value=vol-xxxx
aws s3api get-bucket-metrics-configuration --bucket my-bucket --id EntireBucket
aws backup list-backup-jobs --by-state FAILED

# Azure / GCP examples
az monitor metrics list --resource  --metric "Transactions"
gcloud monitoring metrics list --filter="storage.googleapis.com"

# Alert test checklist
# 1. simulate exporter down
# 2. simulate capacity threshold
# 3. simulate failed snapshot/backup
# 4. verify routing, escalation, ticket and runbook link

NO-GO : monitoring cloud/enterprise sans tags owners, sans alert routing testé, sans dashboard coûts, sans RPO/RTO observable, ou sans preuve de backup/restore.