EXPLOITATION

Supervision, logs et alertes

Lisez métriques et logs, définissez des règles d’alerte, et soyez prévenu sur Discord ou par email.

Des métriques pour chaque serveur et chaque conteneur, des logs pour chaque application, et des règles d’alerte qui vous préviennent quand une limite est franchie — sur Discord, Slack, par email ou vers un webhook à vous.

Métriques

Deux niveaux, échantillonnés en continu et conservés en historique :

Serveur: CPU, mémoire et disque de la machine, utilisés et totaux. C’est ce que lisent les règles d’alerte.
Conteneur: CPU, mémoire, réseau entrant/sortant et E/S bloc par conteneur — pour une application, une base ou une instance Linux.

Vous voyez les serveurs auxquels votre appartenance à un projet vous donne accès ; un administrateur plateforme voit toute la flotte. Lire les métriques exige monitoring:view, qui fait partie du rôle en lecture seule.

L’historique des conteneurs est purgé automatiquement — c’est la table qui croît le plus vite du système, et une rétention illimitée devient un problème de disque bien avant de devenir une archive utile.

Logs

Trois flux de logs existent et répondent à des questions différentes — voir déploiements pour savoir lequel consulter. Les logs de conteneur sont le flux en direct du processus en marche : ce sont ceux qu’il faut quand l’application tourne mais se comporte mal.

Si votre application écrit ses logs dans un fichier à l’intérieur du conteneur plutôt que sur la sortie standard, le tableau de bord n’affiche rien. Docker collecte stdout et stderr — le reste est invisible pour tous les outils de cette catégorie, pas seulement celui-ci.

Règles d’alerte

Une règle, c’est un serveur, une métrique, un opérateur, un seuil et un canal :

TEXT

cpu     >=  90    → Discord
memory  >=  85    → email
disk    <   10    → Slack

Les seuils sont des pourcentages : memory >= 90 signifie donc quatre-vingt-dix pour cent, quelle que soit la RAM de la machine. Métriques disponibles : cpu, memory, disk. Opérateurs : >, >=, <, <=, =.

Le sens de la comparaison change ce qui est mesuré, et c’est là tout l’intérêt. disk >= 90 signifie « l’utilisé a franchi un plafond ». disk < 10 signifie « l’espace libre est passé sous un plancher » — la lecture qu’on attend réellement de cette formulation, et non « le disque est presque vide ». Le CPU n’a pas d’équivalent « libre » : l’opérateur ne l’inverse jamais.

Les règles sont évaluées toutes les trente secondes sur l’échantillon le plus récent. Deux comportements à connaître :

Une règle franchie ne se redéclenche pas toutes les trente secondes. Les notifications répétées sont supprimées — une alerte qui crie toutes les trente secondes pendant une heure vous apprend à l’ignorer.
Un serveur qui a cessé de remonter des données cesse de déclencher des alertes. Son dernier échantillon est figé, et un échantillon figé rejouerait indéfiniment une alerte de ressource. La mise hors ligne de l’hôte est signalée à part, pour ce qu’elle est.

Ce second comportement compte dans la conception de votre alerting : une règle silencieuse ne prouve pas que tout va bien. Surveillez la joignabilité du serveur comme un signal à part entière, et non comme l’absence d’alertes de ressources.

Où partent les alertes

Canal	Nécessite
Email	Le SMTP configuré sur l’installation. Voir installation.
Discord	L’URL d’un webhook de salon.
Slack	L’URL d’un webhook entrant.
Webhook	N’importe quelle URL à vous — pour un système d’astreinte, un bot interne, ou votre propre outillage.

Un canal en échec — webhook révoqué, serveur SMTP qui refuse — est journalisé puis ignoré. Il ne met jamais la boucle d’évaluation à l’arrêt : une destination mal configurée ne peut donc pas empêcher toutes les autres règles de se déclencher.

Envoyez une notification de test à la création de la règle. Une URL de webhook mal saisie est indiscernable d’un serveur calme jusqu’à la nuit où vous aviez besoin de l’alerte.