Supervision et métriques

sh0 relève le serveur et chaque conteneur d'application toutes les 10 secondes et garde la dernière heure. Les alertes et les contrôles de disponibilité vous préviennent quand quelque chose tourne mal.

Ce qui est mesuré

Un collecteur lit les statistiques de Docker et les chiffres de l'hôte toutes les 10 secondes et les range dans la base de données de sh0. Rien n'est envoyé hors du serveur.

• Serveur -- CPU, mémoire utilisée, pourcentage de mémoire, mémoire totale, occupation du disque.
• Chaque conteneur d'application en marche -- CPU, mémoire utilisée, mémoire en pourcentage de sa limite, réseau reçu et émis.

Rétention

Les métriques sont conservées une heure. Les mesures plus anciennes sont supprimées par une purge qui passe toutes les heures. Sur un serveur en marche, la dernière heure d'une série compte donc environ 360 mesures (sortie réelle) :

$ curl -s -H "Authorization: Bearer $SH0_TOKEN" \
    "https://panel.example.com/api/v1/metrics?metric_type=server_cpu" \
  | jq -c '{n:(.data|length), oldest:([.data[].recorded_at]|min), newest:([.data[].recorded_at]|max)}'
{"n":360,"oldest":"2026-10-02 02:10:27","newest":"2026-10-02 03:10:17"}

Les deux valeurs sont des options de sh0 serve : --metric-interval (en secondes, 0 désactive la collecte) et --metric-retention (en secondes, 3600 par défaut). Pour les changer, modifiez la ligne ExecStart du service sh0 et redémarrez-le.

Dans le tableau de bord

• Monitoring, onglet Vue d'ensemble -- CPU, mémoire, disque et réseau actuels du serveur.
• Onglet Applications -- les applications en marche avec leur CPU et leur mémoire, triables.
• Onglet Disponibilité -- les contrôles de disponibilité et leurs incidents (licence Pro).
• Onglet Alertes -- les règles d'alerte, avec Créer une alerte et Tester (licence Pro).

API des métriques

Les mêmes chiffres par l'API (réponse réelle pour une application limitée à 256 Mo) :

$ curl -s -H "Authorization: Bearer $SH0_TOKEN" https://panel.example.com/api/v1/apps/<app-id>/stats
{"data":{"cpu_percent":0.0,"memory_bytes":8355840,"memory_limit_bytes":268435456,"memory_percent":3.11279296875,"network_rx_bytes":3124,"network_tx_bytes":542}}

• GET /api/v1/metrics/server -- chiffres actuels du serveur.
• GET /api/v1/apps/<id>/stats -- chiffres actuels d'une application, comme ci-dessus ; GET /api/v1/apps/stats pour toutes les applications à la fois ; GET /api/v1/apps/<id>/metrics -- les mesures conservées d'une application.
• GET /api/v1/metrics -- les mesures conservées, filtrées par app_id, metric_type (cpu, memory, memory_percent, network_rx, network_tx, server_cpu, server_memory, server_memory_percent, server_disk…) et since.

Alertes

Les alertes exigent une licence Pro ou supérieure. Créez-les depuis Monitoring, Alertes, ou par l'API. channel_config est un objet JSON passé sous forme de chaîne (réponse réelle) :

$ curl -X POST https://panel.example.com/api/v1/alerts \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"app_id":"<app-id>","alert_type":"high_memory","threshold":90,"channel":"webhook","channel_config":"{\"url\":\"https://hooks.example.com/sh0\"}"}'
{"data":{"alert_type":"high_memory","app_id":"<app-id>","channel":"webhook","channel_config":"{\"url\":\"https://hooks.example.com/sh0\"}","created_at":"2026-10-02 03:10:54","enabled":true,"id":"ca506b3d-b91a-4ca3-941e-be42c6ad2ef3","last_fired":null,"threshold":90.0}}

Une alerte portant un app_id exige le rôle developer sur le projet de cette application ; une alerte sans app_id vaut pour tout le serveur et exige le rôle admin ou owner. Un lecteur de rôle viewer voit l'alerte sans son channel_config, qui contient les identifiants.

Types d'alerte

• high_cpu, high_memory -- la dernière mesure dépasse threshold (un pourcentage). Évaluées toutes les 30 secondes ; une alerte déclenchée reste muette 5 minutes.
• app_down -- aucune mesure CPU de l'application depuis 30 secondes, ce qui arrive quand son conteneur ne tourne pas.
• disk_full -- vérifiée toutes les 15 minutes contre le threshold de l'alerte, ou 80 % à défaut ; le même avertissement n'est pas renvoyé avant 6 heures. Au-delà de 90 %, les déploiements sont refusés.
• deploy_failed -- envoyée quand un déploiement de l'application échoue.
• uptime, uptime_down, uptime_up -- envoyées par les contrôles de disponibilité (plus bas).
• ssl_expiry -- Depuis 1.10.3 : se déclenche quand un certificat de l'application de l'alerte (ou de n'importe quel domaine, sans application) expire dans moins de jours que le seuil, 14 par défaut. Le seuil est un nombre de jours, pas un pourcentage. Évaluée sur le certificat que sh0 détient sur disque ; les adresses *.sh0.app et les certificats que vous avez fournis vous-même ne sont pas couverts. Envoyée au plus une fois par jour et par alerte.

Canaux de notification

• email -- recipients, une liste d'adresses. Le courriel passe par le serveur SMTP configuré pour le service sh0 avec les variables d'environnement SH0_SMTP_HOST, SH0_SMTP_PORT (587 par défaut), SH0_SMTP_USER, SH0_SMTP_PASSWORD, SH0_SMTP_FROM et SH0_SMTP_TLS ; sans elles, aucun courriel ne part.
• slack, discord -- webhook_url, l'URL du webhook entrant du canal.
• telegram -- bot_token et chat_id.
• webhook -- url, et en option secret et headers. sh0 envoie un POST JSON ; avec un secret, l'en-tête X-sh0-Signature: sha256=… porte un HMAC du corps.

Tester (POST /api/v1/alerts/<id>/test) envoie une notification d'exemple par le canal configuré ; c'est limité à 10 essais par minute et par utilisateur.

Contrôles de disponibilité

Un contrôle de disponibilité interroge une URL à intervalle fixe et ouvre un incident quand elle échoue plusieurs fois de suite. Créez-le depuis l'onglet Disponibilité de l'application ou depuis Monitoring : méthode GET ou HEAD, intervalle de 10 à 86 400 secondes, délai de 1 à 30 secondes, code de statut attendu et seuil d'échecs. Les contrôles de disponibilité exigent une licence Pro ; leurs notifications passent par les alertes de type uptime.