Dans une entreprise, l’astreinte (on-call), c’est le système qui décide qui est réveillé quand ça casse. Il y a des plannings, des remplaçants, des escalades.
Chez toi, c’est plus simple et plus rude : il n’y a que toi, et tu es potentiellement d’astreinte 24 h sur 24. Si tu ne règles pas ça, deux choses arrivent : soit tu ignores toutes les notifications (et tu rates la vraie urgence), soit tu es réveillé à 3 h du matin parce que le tableau de bord a du retard.
Voici comment organiser une astreinte de une personne qui respecte ton sommeil.
La règle d’or : une alerte qui réveille doit demander d’agir
Si tu ne peux rien faire avant demain matin, l’alerte ne doit pas sonner la nuit. C’est la règle numéro un de l’astreinte, et elle s’applique parfaitement ici.
Pour savoir si une alerte mérite de te réveiller, pose-toi deux questions :
- Est-ce que ça casse quelque chose d’important maintenant ? (Pas « ça pourrait casser un jour ».)
- Est-ce que je peux y remédier à distance, tout de suite ?
Si l’une des deux réponses est non, l’alerte attend le matin.
Trois niveaux de gravité
Je répartis tout ce que je surveille en trois niveaux :
| Niveau | Exemples | Ce que ça déclenche |
|---|---|---|
| Critique | Le DNS maison ne répond plus. Le disque des données est plein. | Notification urgente, jour et nuit |
| Avertissement | Un disque dépasse 85 %. Un service a redémarré plusieurs fois. | Notification normale, seulement en journée |
| Information | Une sauvegarde s’est bien passée. Une mise à jour est disponible. | Un message discret, ou un résumé du matin |
Presque tout est dans les deux dernières catégories. La catégorie « critique » doit rester minuscule : deux ou trois alertes, pas plus.
Mettre en place les niveaux avec Alertmanager
Si tu utilises Prometheus, Alertmanager gère l’acheminement des alertes. Chaque règle reçoit une étiquette severity, et Alertmanager décide où l’envoyer et quand.
Dans la règle d’alerte, tu poses l’étiquette :
- alert: DisqueDonneesPlein
expr: node_filesystem_avail_bytes{mountpoint="/data"} / node_filesystem_size_bytes{mountpoint="/data"} < 0.05
for: 10m
labels:
severity: critical
annotations:
summary: "Moins de 5 % d'espace libre sur /data"Puis dans alertmanager.yml, tu définis le routage et les plages de silence :
route:
receiver: notif-normale
group_by: [alertname]
routes:
- matchers: [ severity="critical" ]
receiver: notif-urgente
- matchers: [ severity="warning" ]
receiver: notif-normale
mute_time_intervals: [nuit]
time_intervals:
- name: nuit
time_intervals:
- times:
- start_time: "00:00"
end_time: "07:00"
- start_time: "23:00"
end_time: "24:00"
receivers:
- name: notif-urgente
webhook_configs:
- url: http://127.0.0.1:8080/urgente
- name: notif-normale
webhook_configs:
- url: http://127.0.0.1:8080/normaleLes deux récepteurs sont des exemples : à toi de brancher le canal de ton choix. Pour recevoir ça sur le téléphone, il te faut un petit pont entre Alertmanager et ton service de notifications (c’est ce que j’explique dans Être alerté sur son téléphone quand ça plante, avec un script maison pour les cas simples).
À retenir de ce fichier :
- Les alertes critiques passent toujours.
- Les avertissements sont mis en sourdine la nuit (entre 23 h et 7 h) et reviendront le matin si le problème persiste.
Éviter le déluge : regrouper et attendre
Trois réglages évitent de recevoir vingt messages pour un seul problème :
route:
group_wait: 30s # attendre un peu pour regrouper les alertes liées
group_interval: 5m # ne pas renvoyer un groupe plus souvent
repeat_interval: 6h # relancer au plus toutes les 6 heuresSans ça, une panne de réseau qui rend dix services injoignables te donne dix notifications. Avec, tu en reçois une seule, qui liste tout.
Autre réglage précieux : les inhibitions. Si la machine entière est injoignable, inutile d’être alerté séparément pour chacun de ses services. On dit à Alertmanager : « si l’alerte machine éteinte est active, ne me parle pas des services de cette machine. »
Et la famille dans tout ça ?
Une astreinte de homelab a une particularité : les « utilisateurs » vivent avec toi. Ça a deux conséquences utiles :
- Tu sais souvent avant l’alerte, parce que quelqu’un râle. Tant mieux, ça te donne un signal de plus.
- Tu peux négocier tes SLO avec eux : « ça ne vous dérange pas si le Wi-Fi invité est coupé une heure pendant la nuit pour une mise à jour ? » C’est du SRE, version dîner.
Dis-leur aussi ce qui est critique (internet, le DNS, les photos) et ce qui ne l’est pas. Les attentes claires évitent les malentendus.
L’hygiène de l’astreinte
Un système d’alerte se dégrade vite si on ne s’en occupe pas. Une fois par mois, passe cinq minutes à relire :
- Quelle alerte t’a le plus dérangé ? Si elle n’a mené à aucune action, supprime-la ou baisse-la d’un niveau.
- Y a-t-il eu une panne sans alerte ? Alors crée la règle qui manquait.
- Est-ce que les notifications arrivent encore ? Teste en provoquant une alerte volontairement.
C’est la maintenance la plus rentable qui soit : elle garde ton téléphone silencieux, et fiable le jour où il vibre.
À retenir
- Une alerte nocturne doit demander d’agir. Sinon, elle attend le matin.
- Trois niveaux : critique, avertissement, information. Le premier reste minuscule.
- Regroupe les alertes liées et espace les rappels.
- Teste ta chaîne de notification régulièrement.
- Fais le ménage une fois par mois.
Dans l’article sur les runbooks, on prépare l’étape suivante : savoir quoi faire quand le téléphone vibre, même à moitié endormi.
