KPI, alerting et recette de mise en production

01Un indicateur, une question, une décision

La dérive habituelle consiste à alerter sur tout ce qui est mesurable. Au bout de trois mois, plus personne ne lit les notifications, et l'alerte importante passe inaperçue au milieu du bruit.

Nous appliquons une règle simple : toute alerte doit avoir un destinataire, un délai de traitement et une action documentée. Si l'une des trois manque, l'indicateur reste sur un tableau de bord mais ne déclenche pas de notification.

02Le tableau des indicateurs et de leurs seuils

Cluster et quorum

Stockage Ceph

Capacité et charge

Sauvegardes et matériel

03Construire l'alerting dans Grafana

L'alerting unifié de Grafana repose sur quatre briques : les règles, les points de contact, les politiques de notification et les périodes de silence.

// âge de la dernière sauvegarde réussie, en heures
from(bucket: "proxmox")
  |> range(start: -72h)
  |> filter(fn: (r) => r._measurement == "pbs_backup" and r._field == "success")
  |> filter(fn: (r) => r._value == 1)
  |> last()
  |> map(fn: (r) => ({r with _value: (float(v: uint(v: now())) -
        float(v: uint(v: r._time))) / 3600000000000.0}))

Quelques réglages qui changent tout au quotidien.

• Durée avant déclenchement : une latence Ceph au-delà du seuil pendant quinze minutes est un signal, pendant trente secondes c'est un nettoyage en cours. Sans cette durée, l'alerting est inexploitable.
• Regroupement : grouper par cluster et par gravité évite de recevoir quarante messages quand un noeud tombe.
• Périodes de silence : déclarez les fenêtres de maintenance à l'avance. Une équipe qui prend l'habitude de couper les alertes à la main finit par oublier de les réactiver.
• Alerte témoin : une règle qui se déclenche toujours et envoie un message quotidien. Si ce message n'arrive pas, c'est la chaîne d'alerte elle-même qui est en panne. C'est la seule façon de détecter un silence trompeur.

04Routage par gravité et astreinte

Un cluster en bonne santé génère zéro P1 et zéro P2 par semaine. Si ce n'est pas le cas, soit la plateforme a un problème de fond, soit les seuils sont mal calibrés. Les deux se corrigent, mais pas de la même façon.

05La recette de mise en production

Aucun service n'est ouvert avant que ces tests soient passés, chronométrés et consignés. C'est aussi ce document que nous produisons à l'issue d'un audit.

Tests de résilience

• Coupure brutale d'un noeud, alimentation débranchée. Les machines sous HA doivent redémarrer ailleurs en moins de trois minutes, sans perte de données.
• Retrait d'un OSD en pleine activité. Le rééquilibrage doit se dérouler sans dégradation perceptible du service.
• Perte d'un lien corosync. Le cluster doit basculer sur le second lien sans aucune isolation de noeud.
• Perte d'un commutateur complet, si l'architecture le prévoit.
• Retour du noeud après réparation, et vérification du retour à HEALTH_OK sans intervention manuelle.

Tests de restauration

• Restauration complète d'une machine virtuelle sur un autre noeud, durée mesurée. Ce chiffre devient l'engagement de rétablissement communiqué.
• Restauration d'un fichier unique.
• Restauration depuis la copie distante, et non depuis le PBS principal.

Tests de performance

• Mesure de référence avec fio depuis une machine virtuelle : lecture et écriture aléatoires en 4 Ko, séquentiel en 1 Mo, latence au 99e centile.
• Ces valeurs sont conservées. Elles servent de point de comparaison lors de la prochaine plainte sur les performances, six mois plus tard.

Tests de la chaîne d'alerte

• Déclenchement volontaire d'une alerte de chaque niveau, et vérification de la réception sur chaque canal, y compris en dehors des heures ouvrées.
• Vérification que la personne d'astreinte sait quoi faire à réception : chaque alerte renvoie à une procédure écrite.

Documentation livrée

• Plan d'adressage et schéma d'architecture à jour.
• Secrets dans un coffre, avec une procédure d'accès en cas d'indisponibilité du responsable.
• Procédures d'exploitation : ajout d'un noeud, remplacement d'un disque, mise à jour du cluster, restauration.
• Registre des seuils d'alerte et de leur justification.

06Rythme d'exploitation