Monitoring serveur
Un serveur sans surveillance, c'est comme un rucher sans visite : tout semble aller bien jusqu'au jour ou une colonie s'effondre sans signe avant-coureur. La page de monitoring serveur existe pour eviter ce scenario. Elle regroupe trois panneaux de surveillance --- les metriques systeme via Beszel, l'etat des containers Docker et les statistiques de la base de donnees Supabase --- et se rafraichit automatiquement pour offrir une vue en temps reel de l'infrastructure, sans avoir a se connecter en SSH au serveur.
Page : /backoffice/monitoring | Sidebar : Section "MONITORING" (orange)
Widget Server Health (dashboard)
Avant de plonger dans les details, il est utile d'avoir un indicateur rapide de la sante du serveur des l'ouverture du backoffice. C'est le role de ce widget compact presente sur le dashboard principal (/backoffice). Il affiche 4 jauges SVG circulaires qui permettent de reperer un probleme en un coup d'oeil, sans avoir a naviguer vers la page de monitoring complete :
| Jauge | Source | Seuils de couleur |
|---|---|---|
| CPU | Beszel API (PocketBase) | Vert (moins de 70%), Ambre (70-90%), Rouge (plus de 90%) |
| RAM | Beszel API (PocketBase) | Vert (moins de 70%), Ambre (70-90%), Rouge (plus de 90%) |
| Disque | Beszel API (PocketBase) | Vert (moins de 70%), Ambre (70-90%), Rouge (plus de 90%) |
| Containers | Docker API (/api/admin/docker) | Vert (100% healthy), Ambre (moins de 100%), Rouge (0 running) |
- Polling automatique : toutes les 30 secondes (
useAutoRefreshinterval 30000) - Focus refetch : quand l'onglet reprend le focus
- Degradation gracieuse : si Beszel ou Docker sont indisponibles, les jauges affichent "---" au lieu de crasher
Composant : AdminServerHealth.tsx (import dynamique dans le layout dashboard).
Beszel (metriques systeme)
Les metriques systeme (CPU, memoire, disque) sont les signes vitaux du serveur, comme la temperature et le poids d'une ruche. Le panneau Beszel les collecte en temps reel grace a un agent leger deploye directement sur la machine hote, ce qui lui donne acces aux vraies ressources physiques du serveur Hetzner --- et pas seulement a celles d'un container isole.
Architecture Beszel
L'architecture repose sur deux composants. L'agent tourne sur la machine hote (pas dans un container isole) pour mesurer les vraies ressources physiques. Le hub centralise ces donnees et les rend accessibles via une interface web et une API :
beepass-beszel-agent (network_mode: host, TCP :45876)
|-- Metriques systeme (CPU, RAM, disque, reseau)
|-- Metriques Docker (/var/run/docker.sock:ro)
|
beepass-beszel (hub, port 8090)
|
Traefik --> https://beszel.beepass.io
| Composant | Image | Port | Description |
|---|---|---|---|
beepass-beszel | henrygd/beszel:latest | 8090 | Hub monitoring leger, auth native, expose via Traefik |
beepass-beszel-agent | henrygd/beszel-agent:latest | 45876 (TCP) | Agent metriques systeme + Docker, network_mode: host |
Acces direct : https://beszel.beepass.io (authentification native Beszel, creer un compte au premier lancement).
Metriques affichees
Chaque metrique est accompagnee d'un seuil d'alerte qui aide a anticiper les problemes avant qu'ils n'impactent les utilisateurs :
| Metrique | Format | Seuil d'alerte |
|---|---|---|
| CPU | Pourcentage d'utilisation + nombre de coeurs | > 80% |
| Memoire | Go utilises / Go totaux + pourcentage | > 85% |
| Disque | Go utilises / Go totaux + pourcentage | > 90% |
| Reseau I/O | KB/s entrant et sortant | --- |
| Uptime | Duree depuis le dernier redemarrage | --- |
L'indicateur de sante global affiche online (vert) ou offline (rouge) selon la disponibilite de l'agent. L'horodatage de la derniere mise a jour est affiche en bas du panneau.
Rafraichissement
Le panneau utilise useAutoRefresh avec un polling toutes les 30 secondes. Aucun canal Realtime n'est utilise car Beszel est une source de donnees externe (il ne passe pas par Supabase).
Les images Docker Beszel (henrygd/beszel et henrygd/beszel-agent) sont des binaires Go compiles dans des images scratch (des images Docker minimalistes qui ne contiennent rien d'autre que le programme lui-meme) --- aucun outil CLI n'est disponible (pas de wget, curl, ls, ni sh). Il est donc impossible de configurer un healthcheck Docker pour ces containers. Leur etat de sante est surveille uniquement via les metriques qu'ils exposent.
Docker Services
BeePass n'est pas un simple site web : c'est un ensemble de 18 services qui cooperent --- le site, le worker de calcul genetique, la base de donnees, le proxy reseau, l'IA, le support, etc. Le panneau Docker Services donne une vue d'ensemble de tous ces services, leur etat de fonctionnement, et permet d'intervenir rapidement (consulter les logs, redemarrer un service) sans avoir a se connecter en SSH.
Les 18 services Docker
L'infrastructure BeePass comprend 18 services Docker operationnels sur le serveur Hetzner. Chacun a un role precis dans l'ecosysteme :
| # | Service | Image | Port interne | Description | Healthcheck |
|---|---|---|---|---|---|
| 1 | beepass-web | Next.js 15 standalone | 3000 | Frontend + API Routes. Docker socket monte RO. Env HOSTNAME=0.0.0.0 obligatoire. | wget 127.0.0.1:3000 (start_period 15s) |
| 2 | beepass-worker | Python 3.11-slim + BLUPF90+ | 8000 | Worker Python (env_compute, XGBoost, BLUPF90, THRGIBBS, ONE SHOT). FastAPI + rq. Healthcheck zombie-aware. | curl 127.0.0.1:8000/health |
| 3 | beepass-redis | Redis 7.4-alpine | 6379 | File d'attente rq (5 queues). Volume persistant. | redis-cli ping |
| 4 | beepass-backup | postgres:17-alpine | --- | pg_dump cron quotidien 03:00 UTC, retention 7j, SHA256 checksum. | pgrep crond (interval 60s) |
| 5 | beepass-ollama | ollama/ollama:latest | 11434 | Ollama LLM (llama3.2:3b import IA + nomic-embed-text RAG). 4CPU/10G. | ollama list |
| 6 | beepass-docs | Docusaurus 3.9 (nginx:alpine) | 80 | Documentation statique beepass.io/docs. Multi-stage build. | curl 127.0.0.1:80 (start_period 10s) |
| 7 | beepass-traefik | traefik:v3.6 | 80, 443, 8082 | Reverse proxy Docker, SSL interne (Cloudflare Full Strict), Prometheus metrics. | traefik healthcheck --ping |
| 8 | beepass-prometheus | prom/prometheus:v3.9.1 | 9090 | Collecte metriques, retention 30j, web.enable-lifecycle. | wget 127.0.0.1:9090/-/healthy |
| 9 | beepass-grafana | grafana/grafana:v12.3.3 | 3000 | Dashboards monitoring.beepass.io. 5 dashboards importes. | wget 127.0.0.1:3000/api/health |
| 10 | beepass-node-exporter | prom/node-exporter:v1.10.2 | 9100 | Metriques systeme (CPU, RAM, Disk, Network). | wget 127.0.0.1:9100/metrics |
| 11 | beepass-postgres-exporter | postgres-exporter:v0.19.0 | 9187 | Metriques PostgreSQL (connexions, query time, table sizes). | wget 127.0.0.1:9187/metrics |
| 12 | beepass-beszel | henrygd/beszel:latest | 8090 | Hub monitoring leger beszel.beepass.io. Auth native. | Aucun (image scratch) |
| 13 | beepass-beszel-agent | henrygd/beszel-agent:latest | 45876 (TCP) | Agent metriques systeme + Docker. network_mode: host. | Aucun (image scratch) |
| 14 | beepass-peppermint | pepperlabs/peppermint:latest | 3000, 5003 | Helpdesk ticketing beepass.io/support. Frontend + API. | wget 127.0.0.1:3000 (start_period 30s) |
| 15 | beepass-peppermint-db | postgres:17-alpine | 5432 | Base PostgreSQL dediee Peppermint. | pg_isready |
| 16 | beepass-ainv | node:20-alpine + R | --- | AINV-honeybees v20 matrice A^-1 (run on-demand). | --- |
| 17 | beepass-zap | ghcr.io/zaproxy/zaproxy:stable | 8090 | OWASP ZAP scanner (daemon mode). 2CPU/2G. | curl 127.0.0.1:8090/JSON/core/view/version/ |
| 18 | beepass-nuclei | projectdiscovery/nuclei:latest | --- | Nuclei scanner (profile security, containers ephemeres on-demand). | --- |
14 des 18 services ont un healthcheck Docker configure (une commande qui verifie periodiquement que le service fonctionne correctement). Les 4 exceptions sont : beszel et beszel-agent (images scratch Go sans outil CLI), beepass-ainv et beepass-nuclei (run on-demand, pas de daemon permanent).
Colonnes du tableau
Le tableau Docker presente chaque container avec les informations essentielles pour evaluer rapidement sa sante :
| Colonne | Description |
|---|---|
| Container | Nom du container (ex : beepass-web, traefik) |
| Image | Image Docker + tag (ex : node:20-alpine) |
| State | Badge : Running (vert), Exited (rouge), Restarting (ambre) |
| Health | Badge : Healthy (vert dot), Unhealthy (rouge dot), Starting (ambre dot), "---" (pas de healthcheck). Les badges affichent les termes Docker natifs en anglais. |
| Uptime | Temps depuis la creation du container (relatif) |
| Restarts | Compteur de redemarrages (rouge si > 0) --- un nombre eleve de restarts est souvent signe d'un probleme recurrent |
| Actions | Icones : Logs (expand) + Restart (avec confirmation) |
Cartes de statistiques
Quatre cartes en haut de page donnent une vue synthetique avant d'examiner le detail :
| Carte | Description |
|---|---|
| Total containers | Nombre total de containers Docker (running + exited) |
| Running | Nombre de containers en cours d'execution (badge vert) |
| Unhealthy | Nombre de containers en etat unhealthy (badge rouge, 0 = vert) |
| Uptime serveur | Temps depuis le demarrage du container le plus ancien |
Actions par container
Depuis le tableau, deux actions sont disponibles pour chaque container. L'objectif est de pouvoir diagnostiquer et corriger un probleme sans quitter le navigateur :
| Action | Description |
|---|---|
| Voir les logs | Affiche les 50 dernieres lignes de logs en monospace dans un panneau deroulant. Logs recuperes via l'API Docker Engine (stream multiplexe, headers 8 octets supprimes automatiquement). |
| Redemarrer | Envoie un signal de redemarrage avec un timeout de 10 secondes. Modale de confirmation requise. |
Containers non restartables --- certains services sont trop critiques pour etre redemarres depuis l'interface :
beepass-web: auto-kill = perte de l'interface admin (on scierait la branche sur laquelle on est assis)traefik: proxy critique, coupure reseau totale (plus aucun service ne serait accessible)
Pour ces containers, le bouton restart est desactive avec un tooltip explicatif.
Tri des containers
Les containers sont tries dans un ordre predefini, les services les plus critiques en haut de la liste. Cela permet de reperer immediatement si un service essentiel est en difficulte :
beepass-webbeepass-workerbeepass-redisbeepass-backupbeepass-ollamabeepass-zapbeepass-nucleitraefik- Alphabetique pour le reste
Rafraichissement
- Polling automatique : toutes les 30 secondes
- Focus refetch : quand l'onglet reprend le focus
Prerequis Docker
Pour que l'interface puisse communiquer avec Docker et lire l'etat des containers, le socket Docker (le canal de communication avec le moteur Docker) doit etre monte en lecture seule sur beepass-web :
# docker-compose.yml -- service beepass-web
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
Le parametre Docker AutoRemove doit etre a false pour tous les containers persistants. Si AutoRemove: true est active, le container est supprime avant que les logs puissent etre lus, rendant le diagnostic impossible --- comme si un patient quittait l'hopital avant que le medecin ait pu lire ses resultats d'analyse.
Traefik v3 exclut automatiquement les containers marques unhealthy du routing HTTP. Concretement, cela signifie qu'un healthcheck defaillant sur un container critique (ex : beepass-web) provoque un 404 sur l'ensemble du site --- Traefik considere que le service ne fonctionne plus et cesse de lui envoyer du trafic. Verifiez toujours le bon fonctionnement des healthchecks avant un deploiement.
Dans les containers Alpine, BusyBox (la boite a outils systeme integree) resout localhost en IPv6 (::1) avant IPv4. Les healthchecks Docker doivent toujours cibler 127.0.0.1 explicitement pour eviter les faux negatifs (un service qui fonctionne mais dont le healthcheck echoue parce qu'il frappe la mauvaise adresse).
Next.js standalone et HOSTNAME
Le service beepass-web necessite la variable d'environnement HOSTNAME=0.0.0.0 dans sa configuration Docker. Par defaut, Next.js standalone ecoute uniquement sur le hostname interne du container (un nom genere par Docker), ce qui le rend invisible pour Traefik. Avec 0.0.0.0, Next.js ecoute sur toutes les interfaces reseau, permettant a Traefik de lui transmettre les requetes.
Responsive mobile/tablet
- Table avec
overflow-x-auto(scroll horizontal si necessaire) - Colonnes secondaires (Health, Restarts) cachees via
hidden md:table-cell - 4 stat cards en grille 2x2 (cols-2) au lieu de 4 colonnes
- Pagination responsive avec padding adapte
- Boutons Actions conservent 32px minimum
Serveur Hetzner
Toute l'infrastructure BeePass tourne sur un seul serveur cloud Hetzner. Le choix de Hetzner repond a un besoin de souverainete (serveur en Europe) avec un excellent rapport qualite-prix :
| Parametre | Valeur |
|---|---|
| Provider | Hetzner Cloud |
| Plan | CCX23 (4 vCPU / 16 GB RAM / 160 GB SSD) |
| OS | Ubuntu 24.04 |
| Location | Nuremberg (nbg1) |
Limites de ressources Docker
Certains services sont gourmands en ressources. Pour eviter qu'un seul service n'accapare toute la machine au detriment des autres, des limites de CPU et de memoire sont configurees :
| Service | CPU limit | RAM limit | CPU reserve | RAM reserve |
|---|---|---|---|---|
beepass-worker | 4 | 8G | 2 | 4G |
beepass-ollama | 4 | 10G | --- | --- |
beepass-zap | 2 | 2G | --- | --- |
Supabase Database
La base de donnees est le coeur de BeePass : elle stocke les profils utilisateurs, les reines, les evaluations genetiques, les contacts, les sessions, etc. Ce panneau de monitoring permet de surveiller sa sante sans avoir a ecrire des requetes SQL, en fournissant un tableau de bord visuel couvrant les performances, les connexions et le stockage.
Metriques globales
Ces metriques donnent une vue d'ensemble de l'activite et de la sante de la base de donnees PostgreSQL :
| Metrique | Description |
|---|---|
| Taille de la base | Volume total en Mo ou Go |
| Connexions actives | Nombre de connexions en etat active (en train d'executer une requete) |
| Connexions idle | Connexions ouvertes sans requete en cours (en attente) |
| Connexions totales | Somme active + idle |
| Cache hit ratio | Pourcentage de requetes servies depuis le cache PostgreSQL (la memoire rapide). Un ratio eleve (objectif > 99%) signifie que la base repond principalement depuis la memoire, sans aller lire le disque --- c'est beaucoup plus rapide. |
| Uptime | Duree depuis le dernier redemarrage de PostgreSQL |
Sante des services
Supabase est compose de plusieurs sous-services. Un indicateur de statut par service permet de savoir lequel fonctionne et lequel est en difficulte :
| Service | Description |
|---|---|
| REST API | PostgREST --- l'API REST auto-generee qui traduit les requetes HTTP en requetes SQL. Cap 1000 lignes par requete (pagination .range() obligatoire pour les grands ensembles de donnees). |
| Auth | GoTrue --- le service d'authentification qui gere les comptes utilisateurs, les mots de passe et les sessions |
| Storage | Service de stockage de fichiers (buckets S3-compatible) pour les photos, les documents, etc. |
| Realtime | Serveur WebSocket qui envoie des notifications instantanees quand une donnee change en base (utilise par useAutoRefresh) |
Chaque service affiche un voyant vert (operationnel), orange (degrade) ou rouge (hors service).
Statistiques PostgreSQL
Ces compteurs techniques permettent de detecter des anomalies dans le fonctionnement interne de la base :
| Statistique | Description |
|---|---|
| Commits | Nombre total de transactions validees (operations de lecture/ecriture reussies) |
| Rollbacks | Nombre total de transactions annulees (operations qui ont echoue ou ete annulees) |
| Deadlocks | Nombre de deadlocks detectes (situations ou deux requetes se bloquent mutuellement --- rare mais symptomatique) |
| Fichiers temporaires | Nombre de fichiers temp crees (indicateur de requetes couteuses qui debordent de la memoire disponible) |
Statistiques plateforme
| Compteur | Description |
|---|---|
| Utilisateurs totaux | Nombre de comptes dans auth.users |
| Buckets de stockage | Nombre de buckets configures |
Vue des tables
Ce tableau detaille permet d'identifier les tables qui grossissent trop, celles qui manquent d'index, ou celles qui necessitent une maintenance :
| Colonne | Description |
|---|---|
| Nom | Nom de la table |
| Lignes | Estimation du nombre de lignes |
| Dead rows | Lignes mortes en attente de vacuum (maintenance automatique). Un nombre eleve indique que le nettoyage prend du retard. |
| Taille table | Espace disque occupe par les donnees |
| Taille index | Espace disque occupe par les index (structures qui accelerent les recherches) |
| Dernier vacuum | Date du dernier nettoyage automatique |
| Sequential scans | Nombre de scans sequentiels --- des valeurs elevees peuvent indiquer qu'un index manque (la base parcourt toute la table au lieu d'utiliser un raccourci) |
Connexions actives
Cette section liste les requetes en cours d'execution. Elle est utile pour identifier une requete lente qui bloque les autres :
| Colonne | Description |
|---|---|
| Requete | Texte SQL de la requete en cours |
| Etat | active, idle, idle in transaction |
| Duree | Temps ecoule depuis le debut de la requete |
| Client | Informations sur l'application ou l'adresse IP du client |
Buckets de stockage
| Colonne | Description |
|---|---|
| Nom | Identifiant du bucket |
| Visibilite | public ou private (protege par RLS, le systeme de controle d'acces de Supabase) |
| Fichiers | Nombre de fichiers stockes |
| Taille totale | Volume total du bucket |
Un cache hit ratio inferieur a 99% peut indiquer un manque de memoire partagee (shared_buffers) ou des requetes trop volumineuses qui ne tiennent pas en memoire. Consultez les sequential scans dans la vue des tables pour identifier les tables necessitant un index --- c'est souvent la cause la plus simple a corriger.
Monitoring avance : Prometheus & Grafana
Pour aller au-dela des metriques instantanees et observer des tendances sur plusieurs jours ou semaines, BeePass utilise Prometheus (collecte et stockage de metriques) et Grafana (visualisation sous forme de graphiques interactifs). Ensemble, ils permettent de repondre a des questions comme "le CPU est-il plus charge qu'il y a une semaine ?" ou "les temps de reponse PostgreSQL se degradent-ils ?".
Prometheus
Prometheus collecte les metriques de 4 sources (appelees "targets") en les interrogeant a intervalles reguliers :
| Target | Port | Metriques |
|---|---|---|
prometheus | 9090 | Auto-monitoring (Prometheus se surveille lui-meme) |
node-exporter | 9100 | CPU, RAM, Disk, Network (metriques systeme du serveur) |
postgres-exporter | 9187 | Connexions, query time, table sizes (metriques de la base PostgreSQL) |
traefik | 8082 | Requetes HTTP, latence, status codes (metriques du reverse proxy) |
Prometheus est uniquement accessible en interne (pas de sous-domaine public). Retention : 30 jours.
Grafana
Grafana transforme les metriques brutes de Prometheus en tableaux de bord visuels avec des graphiques, des alertes et des vues historiques.
Acces : https://monitoring.beepass.io
5 dashboards importes :
| Dashboard | ID | Contenu |
|---|---|---|
| Node Exporter Full | 1860 | Metriques systeme detaillees (CPU, RAM, disque, reseau par interface) |
| PostgreSQL Database | 9628 | Performances PostgreSQL (requetes/s, temps de reponse, connexions) |
| Traefik Official | 17346 | Trafic et latence du reverse proxy (requetes par service, codes HTTP) |
| Prometheus All Metrics | 15489 | Vue d'ensemble de toutes les metriques collectees |
| Main - Prometheus Overview | 893 | Tableau de bord general |
Backups PostgreSQL
Les donnees sont l'actif le plus precieux de BeePass. Un bug, une fausse manipulation ou un probleme serveur pourrait les compromettre. Les backups automatiques constituent un filet de securite : ils permettent de restaurer la base de donnees a un etat anterieur en cas de probleme, avec une granularite quotidienne.
Backup automatique
| Parametre | Valeur |
|---|---|
| Planification | Quotidien 03:00 UTC (pendant les heures creuses pour minimiser l'impact) |
| Container | beepass-backup (postgres:17-alpine) |
| Format | pg_dump --format=custom (format compresse et restaurable selectivement) |
| Retention | 7 jours (les backups de plus de 7 jours sont supprimes) |
| Checksum | SHA256 sidecar (.sha256) --- un fichier de verification qui garantit que le backup n'est pas corrompu |
Carte Backup Monitor
Cette carte, presente sur la page de monitoring, donne un apercu immediat de l'etat des sauvegardes :
| Element | Description |
|---|---|
| Badge statut | Vert = dernier backup < 24h, Ambre = 24-48h, Rouge = > 48h ou aucun backup |
| Dernier backup | Date relative (ex: "il y a 8h"), taille du fichier (ex: "2.4 GB") |
| Checksum | Badge vert "Checksum verifie" si le fichier .sha256 sidecar existe |
| Liste expandable | Les 7+ derniers backups avec date, taille, checksum |
| Prochain backup | Heure estimee du prochain cron (03:00 UTC suivant) |
| Compteur | Nombre total de backups sur le volume |
Trigger manuel
Parfois, il est utile de lancer un backup avant une operation risquee (migration SQL, mise a jour majeure, etc.). Voici la procedure :
- Cliquer le bouton "Lancer un backup"
- Une modale de confirmation apparait (AlertDialog)
- Confirmer : un
pg_dumpest lance dans le containerbeepass-backup - Le spinner tourne pendant l'operation (1-3 minutes selon la taille de la DB)
- Un toast de succes/erreur s'affiche
- Le resultat brut (output du script) est affiche dans un bloc
<pre>monospace
Prerequis
Le volume backup-data doit etre monte en lecture seule sur beepass-web pour que l'interface puisse lister les backups existants :
volumes:
- backup-data:/data/backups:ro
Hetzner Snapshots API
En complement des backups pg_dump (qui sauvegardent uniquement la base de donnees), des snapshots Hetzner hebdomadaires capturent l'integralite du serveur --- systeme d'exploitation, configuration, fichiers, etc. C'est une deuxieme couche de protection en cas de defaillance materielle :
| Parametre | Valeur |
|---|---|
| Planification | Dimanche 04:00 UTC |
| Script | infra/scripts/hetzner_snapshot.sh |
| API | Hetzner Cloud API (HETZNER_API_TOKEN) |
Seuils d'alerte
Les seuils d'alerte permettent de definir a partir de quel niveau de charge une notification doit etre envoyee. Chaque infrastructure est differente : un serveur qui tourne habituellement a 60% de CPU n'a pas les memes seuils qu'un serveur a 20%. Cette page permet d'adapter les seuils a la realite de l'infrastructure BeePass.
Page : /backoffice/settings --- carte "Seuils d'alerte"
Parametres configurables
Sliders (0-100%, step 5)
| Parametre | Defaut | Description |
|---|---|---|
| CPU --- Avertissement | 80% | Seuil CPU pour notification (attention, la charge monte) |
| CPU --- Critique | 95% | Seuil CPU critique (intervention necessaire) |
| Memoire --- Avertissement | 80% | Seuil memoire pour notification |
| Memoire --- Critique | 95% | Seuil memoire critique |
| Disque --- Avertissement | 80% | Seuil disque pour notification |
| Disque --- Critique | 90% | Seuil disque critique (moins de marge car le disque ne se vide pas tout seul) |
Champs numeriques
| Parametre | Defaut | Plage | Description |
|---|---|---|---|
| Age max backup | 26h | 1-168h | Notification si le dernier backup depasse ce nombre d'heures (26h = une marge au-dela du cycle quotidien de 24h) |
| Certificat TLS | 30j | 1-90j | Alerte avant expiration du certificat TLS (reserve futur) |
| Seuil erreurs API | 10 | 1-1000 | Notification si le nombre d'erreurs en 24h depasse ce seuil |
Toggle
| Parametre | Defaut | Description |
|---|---|---|
| Worker non sain | Active | Notification si le container beepass-worker est unhealthy (le worker est critique pour les calculs genetiques) |
Stockage technique
Les seuils sont stockes dans la table site_settings (cle alert_thresholds, JSONB). Le helper src/lib/alert-thresholds.ts fournit :
loadAlertThresholds(): charge les seuils avec cache memoire 5 minutes (evite de re-lire la base a chaque verification)invalidateAlertCache(): invalide le cache apres modificationALERT_DEFAULTS: valeurs par defaut exportees
Notifications synthetiques
Les notifications classiques sont declenchees par des evenements (un utilisateur s'inscrit, un ticket est cree). Mais certains problemes ne declenchent aucun evenement --- ils se manifestent par l'absence de quelque chose (un backup qui n'a pas eu lieu, un CPU qui reste eleve). Les notifications synthetiques resolvent ce probleme : elles sont calculees a la volee en verifiant des conditions a chaque consultation.
Comment ca marche
Les notifications synthetiques sont calculees a chaque requete sur GET /api/admin/notifications. Elles ne sont pas stockees en base --- leur ID est prefixe synth_ pour eviter les collisions avec les notifications classiques. L'icone TbAlertTriangle (orange) les distingue visuellement.
Les 8 checks
Chaque check verifie une condition specifique et genere une notification si la condition est remplie :
| Notification | Condition | Source | Lien |
|---|---|---|---|
| Backup en retard | Age dernier backup > seuil | Fichiers /data/backups/*.dump | /backoffice/monitoring |
| Espace disque critique | Usage disque > seuil | Beszel API (PocketBase) | /backoffice/monitoring |
| CPU eleve | Usage CPU > seuil | Beszel API (PocketBase) | /backoffice/monitoring |
| Memoire elevee | Usage memoire > seuil | Beszel API (PocketBase) | /backoffice/monitoring |
| Worker non sain | Container beepass-worker = unhealthy | Docker Engine API | /backoffice/docker |
| Pic d'erreurs API | Erreurs 24h > seuil | Table api_error_logs | /backoffice/error-logs |
| Validation de role en attente | Comptes avec pending_* dans les roles | Table profiles | /backoffice/users |
| Tickets sans reponse | Tickets ouverts > 48h sans reponse admin | Peppermint API | /backoffice/support |
Resilience
Chaque check est enveloppe dans son propre try/catch. Si un check echoue (Beszel indisponible, Docker socket absent, etc.), les autres notifications continuent de fonctionner normalement. Aucun check defaillant ne bloque l'ensemble du systeme de notification --- c'est le principe du "fail gracefully" (echouer proprement).
Routes API
Toutes les routes suivantes sont protegees par l'authentification admin (cookie HMAC) et utilisent verifyAdminFromRequest() :
| Route | Methode | Description |
|---|---|---|
/api/admin/backups | GET | Liste des dumps + checksums + stats |
/api/admin/backups | POST | Trigger backup manuel (action: "trigger") |
/api/admin/docker | GET | Containers list + inspect + health |
/api/admin/docker | GET | Logs container (?logs=<name>&tail=50) |
/api/admin/docker | POST | Restart container (action: "restart") |
/api/admin/jobs | GET | 5 taches agregees multi-sources |
/api/admin/alerts/config | GET | Seuils actuels + defauts |
/api/admin/alerts/config | PUT | Sauvegarder seuils (validation + merge) |
/api/admin/notifications | GET | Notifications reelles + 8 synthetiques |
/api/admin/monitoring | GET | Metriques serveur (Beszel) |
/api/admin/server-upgrades | GET | Packages apt upgradable |
Layout de la page Monitoring
La page est organisee pour presenter les informations les plus urgentes en haut, et les details en bas :
+---------------------------------------------+
| Server Upgrades Card |
| (apt packages, check/upgrade) |
+----------------------+-----------------------+
| Backup Monitor Card | Cron Jobs Card |
| (dumps, trigger) | (5 taches planifiees) |
+----------------------+-----------------------+
| Beszel Monitoring Panel |
| (CPU, RAM, Disk, Network + containers) |
+---------------------------------------------+
Voir aussi : Monitoring reseau | Monitoring operations | Tableau de bord