Sujet : monitoring
-
Surveiller l'expiration des certificats TLS sur chaque point d'accès, pas seulement sur le site web principal
Un certificat expiré est une panne dont l'heure est exactement prévisible : sonder depuis l'extérieur la date notAfter de chaque certificat réellement présenté (web, API, messagerie, interfaces internes, répartiteurs de charge), alerter assez tôt pour permettre un renouvellement manuel, et vérifier les certificats intermédiaires comme le certificat final.
-
Concevoir un tableau de bord d'exploitation : une question par panneau, un écran par public
Partir des questions auxquelles une personne d'astreinte doit répondre, attribuer un panneau à chaque question, ordonner les panneaux du général au particulier, normaliser les unités et les axes, utiliser des variables de modèle plutôt que des copies, relier chaque alerte déclenchant un appel au tableau de bord dont elle a besoin, et conserver la définition du tableau de bord sous contrôle de version.
-
Les contrôles de fraîcheur et de nombre de lignes sur les tables sources brutes détectent la plupart des incidents de pipeline plus tôt que les tests au niveau des colonnes en aval
Hypothèse : dans un entrepôt de données à modèles en couches, la majorité des incidents qui finissent par être visibles pour les personnes consultant les rapports se manifestent d'abord par un chargement source brut périmé ou de taille insuffisante, si bien que les contrôles de fraîcheur et de volume au niveau de la couche source les détectent plus tôt que les tests de non-nullité, d'unicité et de valeurs acceptées sur les modèles en aval ; une comparaison est proposée sur des incidents enregistrés.
-
Concevoir des alertes utiles : peu de notifications, chacune avec une prochaine étape
Une alerte qui réveille quelqu'un doit être urgente, guider vers une action et être perceptible par les utilisateurs ; tout le reste est un ticket. Alerter sur les symptômes ressentis à la frontière des utilisateurs, lier les seuils aux objectifs et au taux de consommation du budget d'erreur, poser un délai d'attente contre le flottement, lier le runbook, et chaque semaine, supprimer ou réajuster toute alerte restée sans action.
-
Hygiène des alertes pour la supervision d'hôtes : taux de variation plutôt que seuil fixe, unités en échec et fenêtres de durée
Une page d'astreinte doit signifier qu'un humain doit agir immédiatement ; un disque d'hôte proche de la saturation doit déclencher une page sur son taux de remplissage, pas sur un pourcentage fixe qu'une partition à croissance lente peut frôler pendant des mois, et un seuil franchi un instant ne doit pas déclencher de page du tout. Les documents SRE de Google sur la discipline de paging et l'alerting multifenêtre fournissent le raisonnement, appliqué ici aux signaux d'hôte de cette série.
-
Contrôles de qualité des données : fraîcheur, volume, valeurs nulles et unicité comme ensemble de tests minimal
Quatre contrôles peu coûteux détectent la plupart des chargements défaillants : la source a été mise à jour assez récemment (fraîcheur), l'intervalle a livré un nombre plausible de lignes (volume), les clés et les mesures requises ne sont pas nulles, et le grain déclaré est unique. Exprimer chacun comme une requête qui renvoie les lignes en échec, l'exécuter après le chargement et avant la publication, et séparer les avertissements des erreurs bloquantes.
-
Combien d'emplacements de sondes externes, et quel seuil d'échec, rendent fiables les alertes de disponibilité pour un petit site ?
Question ouverte : un seul emplacement de sonde produit des alertes correspondant aux propres problèmes réseau de la sonde, tandis qu'exiger un accord entre de nombreux emplacements retarde les vraies alertes ; pour un petit site avec une seule origine, quelle combinaison d'emplacements, d'intervalles et de règles de confirmation a permis de garder un faible taux de fausses alertes sans manquer d'interruptions, et comment les deux catégories ont-elles été comptabilisées ?
-
Surveillance synthétique et contrôles de disponibilité : sonder de l'extérieur ce que voient les personnes utilisatrices
Un contrôle synthétique envoie une requête scriptée depuis l'extérieur du système à intervalle fixe et enregistre si la réponse était correcte et combien de temps elle a pris ; il s'agit d'une surveillance en boîte noire au sens SRE, qui détecte des défaillances que l'instrumentation interne ne peut pas voir (DNS, TLS, le répartiteur de charge, un domaine expiré), et doit être sondé depuis plus d'un endroit avant de déclencher une alerte pour quiconque.
-
Vérifier l'état de NFS, Samba, chrony, Unbound et Kea en ligne de commande : une checklist
Une vérification de cinq minutes en ligne de commande pour confirmer que chaque service d'infrastructure fonctionne et répond correctement : rpcinfo -p et showmount -e pour NFSv3 (exportfs -v et sockets connectées sur un serveur NFSv4 seul), smbstatus pour Samba, chronyc tracking et chronyc clients pour l'heure, unbound-control status pour le résolveur, et le fichier de baux Kea ou kea-shell pour le DHCP.
-
SNMPv3 sous Linux avec net-snmp : un utilisateur SHA/AES au niveau de sécurité priv, sans communautés
Le démon snmpd de net-snmp prend en charge le modèle de sécurité USM de SNMPv3, avec authentification et chiffrement par utilisateur, configuré via createUser et imposé par le niveau de sécurité priv sur rouser/rwuser. Supprimer toutes les lignes rocommunity/rwcommunity et tout mappage com2sec ferme l'accès SNMPv1/v2c par communauté en clair, que USM est censé remplacer.
-
Surveiller la dérive d'un modèle déployé : entrées, sorties et étiquettes différées
Le score hors ligne d'un modèle cesse d'être vrai dès que la distribution des entrées, celle des étiquettes ou la relation entre les deux change ; il faut surveiller les distributions des caractéristiques et des prédictions par rapport à une référence d'entraînement, journaliser les caractéristiques servies pour détecter un écart entraînement-service, et réconcilier les étiquettes différées pour calculer la métrique réelle avec un décalage.
-
Surveiller la santé des disques avec smartctl, nvme smart-log et des auto-tests planifiés par smartd
smartctl -H donne rapidement un verdict de santé (réussite ou échec) et -a la table complète des attributs SMART sur les disques ATA/SCSI ; nvme smart-log fait de même pour les périphériques NVMe, et smartd.conf planifie des auto-tests récurrents et des alertes par e-mail, de sorte qu'un disque défaillant soit signalé plutôt que découvert après une perte de données.
-
Quelle métrique mémoire les alertes et les autoscalers devraient-ils utiliser pour un service conteneurisé : RSS, PSS, working set ou memory.current de cgroup ?
Question ouverte : le RSS d'un processus compte les pages partagées par processus, memory.current de cgroup inclut le cache de pages et la mémoire noyau, et Kubernetes rapporte un working set heuristique ; lequel de ces indicateurs a été utilisé comme signal d'alerte et de mise à l'échelle pour un service de longue durée, sans déclencher d'alerte inutile sur du cache récupérable ni manquer une approche de la limite OOM ?
-
Vérifier la synchronisation de l'heure du serveur : timedatectl, chronyc tracking et sur quoi alerter
La dérive d'horloge casse silencieusement la validation des certificats, l'expiration des jetons, la corrélation des journaux et les baux de verrou ; sur chaque hôte, vérifier qu'un service de temps tourne et est synchronisé, lire le décalage, le stratum et le statut de seconde intercalaire auprès du démon, alerter sur « non synchronisé » et sur un décalage dépassant un seuil choisi localement, et revérifier après chaque redémarrage et reconstruction d'image.
-
Bilan de santé d'un hôte avant et après modification, exécutable par un agent sous Linux et Windows
Avant et après toute modification d'un serveur en service, un agent peut relever sur l'un ou l'autre système le même instantané en quatre points (services en échec ou arrêtés, ports en écoute, marge disque et mémoire, erreurs récentes des journaux), puis comparer les deux relevés pour voir précisément ce que la modification a fait bouger, indépendamment de son effet attendu.
-
Les alertes avec lien vers une procédure sont acquittées plus vite et mises en silence moins souvent que celles sans lien
Hypothèse : les règles d'alerte peuvent porter des annotations telles que des descriptions ou des liens vers une procédure (runbook), comme le décrit la documentation de Prometheus ; la proposition est que les alertes provenant de règles disposant d'un lien de procédure fonctionnel sont acquittées et résolues plus vite, et mises en silence (silence) ou en sourdine moins souvent que les alertes provenant de règles sans un tel lien, pour la même équipe et sur la même période.
-
Sous-échantillonnage et niveaux de rétention pour les données de séries temporelles
Conserver les échantillons bruts pour une courte fenêtre, les agréger en compartiments fixes avec le nombre, la somme, le minimum et le maximum pour une fenêtre plus longue, et supprimer par partition lorsqu'un niveau expire ; choisir des agrégats ré-agrégeables, aligner les compartiments sur une origine fixe, et n'exécuter l'agrégation qu'une fois les données tardives du compartiment arrivées.
Lisible par machine : JSON