Cours Supervision et journaux — métriques, logs, alertes, journaux macOS et SLO

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. distinguer métriques, journaux, traces et alertes, et dire à quelle question chacun répond ;
2. concevoir une alerte utile : symptôme, seuil, durée, destinataire, action ;
3. reconnaître et réduire le bruit d'alerte ;
4. lire des journaux macOS avec log show et log stream, sans modifier le système ;
5. décrire le format syslog et ses niveaux de gravité ;
6. expliquer la rotation et la centralisation des journaux et leurs risques ;
7. définir un SLI et un SLO simples et calculer un budget d'erreur ;
8. relier tout cela dans une chaîne mesure, règle, alerte, action.

Prérequis

• Terminal macOS ; notion de processus, de service et de fichier.
• Notions de réseau (cours « Réseau ») pour comprendre la centralisation.
• Aucun accès à un système réel n'est requis ; pratiquer sur son propre Mac uniquement, en lecture.

Parcours et chapitres

1. Observer un système : métriques, journaux, traces

La documentation OpenTelemetry définit trois « signaux » :

• trace : « le chemin d'une requête à travers votre application » ;
• métrique : « une mesure capturée à l'exécution » ;
• journal (log) : « l'enregistrement d'un événement ».

(Traductions libres de l'original anglais.) La page indique que les traces, métriques et journaux sont stables ; les événements et les profils sont encore en développement ou en projet.

Les métriques servent à détecter, les journaux et les traces à comprendre. Une alerte est une conclusion d'une règle appliquée aux métriques (ou à des journaux), pas une donnée brute.

2. Alertes, seuils et bruit

Le guide « Alerting » de Prometheus conseille d'alerter sur les symptômes liés à la douleur de l'utilisateur plutôt que sur chaque cause possible : surveiller la latence et les erreurs « aussi haut que possible dans la pile », ne pas « paginer » (réveiller quelqu'un) pour un défaut de bas niveau sans effet visible, viser le plus petit ensemble d'alertes possible, laisser de la marge pour les petites fluctuations, et compléter par des tableaux de bord pour localiser le composant fautif. Il cite aussi : signaler les travaux par lots qui ne finissent pas sur plus de deux cycles, et surveiller les limites de capacité avant la panne. Il recommande de compléter la surveillance interne par une surveillance externe (« boîte noire »), qui subsiste si le système de supervision tombe.

Une bonne alerte répond à cinq questions :

1. Quel symptôme ? (erreurs, lenteur, indisponibilité, saturation proche) ;
2. Quel seuil et sur quelle durée ? (« plus de 5 % d'erreurs pendant 10 minutes », pas « une erreur ») ;
3. Qui est prévenu, par quel canal, avec quelle urgence ?
4. Quelle action est attendue ? (lien vers la procédure) ;
5. Quand l'alerte se tait-elle ?

Le bruit d'alerte (fatigue d'alerte) : trop d'alertes inutiles, répétées ou sans action possible, et les vraies alertes sont ignorées. Remèdes : supprimer les alertes sans action, allonger la durée avant déclenchement, regrouper les doublons, séparer page (urgent, humain tout de suite) et ticket (à traiter en journée), mesurer le taux d'alertes utiles.

3. Journaux macOS : log show et log stream

Selon la page de manuel (miroir), log donne accès aux messages système des mécanismes de journalisation d'Apple. Sous-commandes de lecture :

• show : affiche le contenu du journal (magasin, archive ou fichiers tracev3) ;
• stream : flux en direct ;
• collect : crée une archive .logarchive (écrit un fichier) ;
• stats : statistiques par événements.

Sous-commandes qui modifient (droits root) : erase (supprime des données de journal) et config (change la configuration de la journalisation).

Options utiles : --last 10m (période : nombre suivi de s, m, h ou d), --predicate (filtre en syntaxe NSPredicate ou abrégée, clés courantes subsystem, category, process, messageType), --style (default, compact, json, ndjson, syslog), --info et --debug (niveaux de détail supplémentaires, plus volumineux).

log show --last 10m --style compactlog show --last 1h --predicate 'process == "Finder"' --style compactlog show --last 1h --predicate 'messageType == error' --style compactlog stream --predicate 'process == "Finder"' --style compact

• Contexte : Terminal macOS, version non confirmée.
• Droits : utilisateur ; certaines entrées ne sont visibles qu'avec des droits d'administrateur (non vérifié commande par commande).
• Effet : lecture seule, sortie sur le terminal ; peut être volumineuse. Rien n'est écrit.
• Vérification : les lignes retournées correspondent à la période et au processus demandés.
• Retour arrière : sans objet.

log stream ne s'arrête qu'avec Control-C. Le nom de processus (Finder) est un exemple ; la syntaxe exacte des prédicats est non vérifiée au-delà des clés citées par la page lue.

4. Syslog en concept

Le RFC 5424 (mars 2009, voie des normes, remplace le RFC 3164 informel) définit le protocole syslog. Un message comporte :

• PRI : (facilité × 8) + gravité entre chevrons ;
• VERSION (1), TIMESTAMP (format dérivé du RFC 3339), HOSTNAME, APP-NAME, PROCID, MSGID ;
• des données structurées facultatives ;
• le message libre.

Les facilités vont de 0 (noyau) à 23 (local7). La gravité va de 0 (urgence) à 7 (débogage). Le RFC impose de prendre en charge au moins 480 octets par message (2048 recommandés), exige le transport TLS et recommande l'UDP, et précise qu'il n'y a pas de garantie de livraison.

(Seules les gravités 0 et 7 figurent dans le résumé lu ; les valeurs intermédiaires sont dans le RFC et n'ont pas été relues ici.)

Lien avec macOS. Le journal unifié d'Apple n'est pas un fichier syslog texte ; log show --style syslog produit un affichage de ce style. Comment macOS reçoit ou émet des messages syslog réseau : non vérifié.

5. Rotation, rétention, centralisation

Le NIST SP 800-92 « Guide to Computer Security Log Management » (septembre 2006, final, seule la présentation a été lue) structure la gestion des journaux en génération, analyse, stockage et élimination, avec une infrastructure et des processus définis dans l'organisation.

Trois notions pratiques (le contenu détaillé du NIST n'a pas été lu : ce sont des principes à valider) :

• Rotation : fermer un fichier de journal quand il atteint une taille ou un âge, en ouvrir un nouveau, compresser et supprimer les plus anciens, pour éviter de saturer le disque. Les outils (newsyslog sur macOS, logrotate sous Linux) n'ont pas été étudiés : non vérifiés.
• Rétention : durée de conservation, fixée par le besoin (diagnostic, enquête, obligation légale : à décider, aucune durée n'est donnée ici).
• Centralisation : envoyer les journaux de plusieurs machines vers un point unique. Avantages : recherche globale, survie de la preuve si une machine est compromise ou détruite, corrélation. Risques : le point central devient critique, les journaux voyagent sur le réseau (les chiffrer, par exemple par TLS, comme le RFC 5424 l'exige pour son transport) et peuvent contenir des données sensibles (limiter qui lit).

6. SLI, SLO et budget d'erreur

Le chapitre « Service Level Objectives » du livre SRE de Google définit :

• SLI : « mesure quantitative soigneusement définie d'un aspect du niveau de service fourni » (disponibilité, latence, taux d'erreur, débit) ;
• SLO : valeur cible ou plage pour un SLI (exemple du livre : 99 % des requêtes de recherche en moins de 100 millisecondes) ;
• SLA : contrat avec conséquences (souvent financières) si les SLO qu'il contient ne sont pas tenus ; un SLO n'en a pas.

Le livre conseille de choisir ce qui compte pour l'utilisateur plutôt que ce qui est facile à mesurer, d'utiliser des percentiles (50e, 95e, 99e) plutôt que des moyennes qui masquent les cas lents, et de fixer un taux d'échec acceptable (le budget d'erreur) plutôt que de viser 100 %.

Exemple chiffré (fictif). SLI : part des requêtes réussies. SLO : 99,5 % sur 30 jours. Sur 1 000 000 de requêtes, le budget d'erreur est de 0,5 % : 5 000 requêtes peuvent échouer. Si 3 000 ont déjà échoué en dix jours, 60 % du budget est consommé : alerter sur la vitesse de consommation du budget est plus pertinent qu'alerter sur chaque erreur. (Calcul simple ; les méthodes d'alerte sur le budget ne sont pas dans la page lue : non vérifiées.)

7. La chaîne complète

Chaque maillon peut tomber : le service peut ne plus émettre, la collecte peut échouer, la règle peut être fausse, le canal d'alerte peut être coupé, la personne peut être indisponible. D'où : une supervision externe de la supervision (conseil Prometheus), et des tests périodiques qui déclenchent volontairement une alerte (sur un système de test).

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule.

1. Signaux. Classer en métrique, journal, trace : « 42 requêtes/s », « échec de connexion à 10:03 », « une requête dure 800 ms dans le service B ».
2. Alerte. Écrire une alerte complète (symptôme, seuil, durée, destinataire, action, extinction) pour la lenteur d'une page web fictive.
3. Bruit. Sur trois alertes fictives très fréquentes, proposer pour chacune de la supprimer, de l'allonger, ou de la passer en ticket.
4. Journaux. Lire log show --last 10m --style compact sur son Mac et repérer un message d'erreur ; ne rien recopier dans le dépôt.
5. Syslog. Calculer la valeur PRI pour la facilité 1 et la gravité 3 avec la formule du RFC (réponse : 1 × 8 + 3 = 11).
6. SLO. Avec un SLO de 99,9 % sur 30 jours et 2 000 000 de requêtes, calculer le budget d'erreur (réponse : 2 000 requêtes).
7. Centralisation. Citer deux avantages et deux risques.

Critères de réussite

• Distinguer détecter (métriques, alertes) et comprendre (journaux, traces).
• Écrire une alerte qui propose une action, pas seulement un chiffre.
• Lire des journaux macOS sans rien modifier et sans partager de donnée sensible.
• Calculer un budget d'erreur simple.
• Dire ce qui n'a pas été vérifié.