Activer les notifications

Mis à jour le

Par défaut, une anomalie s’affiche dans la boîte de réception du cockpit et nulle part ailleurs. Tout envoi sortant est un choix explicite.

E-mail

Paramètres → Notifications : cochez ce que vous voulez recevoir. Les e-mails partent à l’adresse de votre compte, vérifiée à l’inscription.

Notification push

Ouvrez l’application mobile, connectez-vous, acceptez l’invite du système. L’appareil apparaît ensuite dans Paramètres → Notifications, où vous pouvez le retirer. Refuser l’invite n’empêche rien d’autre : l’application fonctionne entièrement sans.

Telegram

  1. Créez un bot auprès de @BotFather et copiez son jeton.
  2. Démarrez une conversation avec votre bot, puis récupérez l’identifiant de la discussion.
  3. Paramètres → Notifications → Ajouter un canal → Telegram, collez les deux valeurs, puis envoyez un message de test — le canal n’est activé qu’après un test réussi.

Webhook

Une URL en HTTPS, signée à l’envoi : chaque requête porte une signature que vous vérifiez avec le secret partagé affiché à la création. Les adresses internes et les plages privées sont refusées.

Heures calmes

Une plage horaire pendant laquelle rien ne part, sauf les alertes de niveau P0 — celles qui n’attendent pas le matin. Les autres sont mises en file et envoyées à la sortie de la plage.

Pourquoi vous recevez peu d’alertes

C’est l’intention. Une alerte n’est envoyée que si elle est actionnable : un pic d’une minute n’ouvre rien, un cœur saturé n’est pas une machine saturée, une prévision incertaine se tait plutôt que de deviner. Une alerte qui se trompe trois fois n’est plus lue à la quatrième.

Une machine d’intégration continue

Un runner (GitLab, Jenkins…) sature son processeur à chaque job : c’est son travail, pas un incident. Dans la configuration du serveur, onglet Alertes, cochez Runner CI : les alertes processeur et charge par défaut se taisent, et tout ce qui casse vraiment un runner reste surveillé — disque qui se remplit (cache Docker), mémoire, swap, température, SMART, service du runner, agent. Un seuil que vous posez à la main dans le tableau reste appliqué, comme une règle écrite pour cette machine ou son groupe ; une règle générale, définie pour tous les serveurs, ne défait pas le profil. Quand GitLab Runner tourne sur la machine, le cockpit vous le propose ; il ne l’active jamais tout seul.

Les conteneurs éphémères qu’un job GitLab crée (nommés runner-…-project-…-concurrent-…) sont ignorés partout, sans réglage : ils naissent et meurent avec le job, et leur état n’est pas celui de la machine.

Lire une alerte

Chaque alerte montre quoi et combien : le disque, le service ou le certificat touché, la valeur mesurée avec son unité, et le repère auquel elle se compare — seuil, habitude ou plancher. Une jauge situe la valeur quand la grandeur est bornée (un disque à 90,6 % pour un seuil à 90 %), une échéance s’affiche pour une saturation prévue (« Plein dans 38 h »). Juste dessous, Comprendre et agir dit ce que ça casse, quoi faire, et donne les commandes de lecture qui le vérifient.