FrugalSentinel est un système de monitoring serverless complet, écrit en Python 3.13 avec la bibliothèque standard uniquement (zéro dépendance pip), exécuté sur le free tier Scaleway Functions, stockant son état sur Scaleway Object Storage (S3), et alertant via ntfy.sh. Résultat : monitoring professionnel pour exactement 0€ par mois.
Le problème que FrugalSentinel résout
Toutes les solutions de monitoring modernes suivent le même schéma : un tier gratuit séduisant, puis un mur de facturation. Datadog, UptimeRobot, Uptime Kuma autohébergé (mais qui nécessite Docker et une VM), Grafana Cloud — toutes imposent soit un coût mensuel, soit une infrastructure dédiée à maintenir.
FrugalSentinel part d’une hypothèse différente : si votre cloud fournit un tier gratuit serverless avec stockage S3, vous pouvez y faire tourner un monitoring complet sans sortir la carte bleue. L’astuce n’est pas dans l’optimisation des coûts — elle est dans l’absence totale de coût, par construction.
Ce que ça change concrètement :
- Aucune VM à maintenir — pas de Docker, pas de systemd, pas de mises à jour de système
- Aucune dépendance externe — pas de
pip installqui casse six mois plus tard - Aucune base de données — l’état est du JSON sur S3, avec rotation automatique
- Aucune facture — tout tient dans le free tier Scaleway (256 MB, 75 GB S3)
Architecture et choix techniques
FrugalSentinel est un monolithe minimaliste conçu pour l’immobilité : une fois déployé, il ne nécessite aucune maintenance.
Python 3.13, stdlib uniquement
Le runtime est volontairement réduit à l’os : urllib pour les requêtes HTTP, json pour la sérialisation, concurrent.futures pour le parallélisme, ssl pour l’analyse des certificats. Aucun framework, aucune bibliothèque tierce. Le code que vous écrivez aujourd’hui fonctionnera dans 5 ans sans modification.
Le choix de Python a un tradeoff : les cold starts sont légèrement plus lents qu’avec Go ou Rust. Mais l’avantage est considérable : Python permet d’écrire des probes complexes en quelques lignes — comme l’API de liste des serveurs Luanti, qui nécessite du parsing JSON et de la logique de matching. Si vous avez besoin d’un notifier autre que ntfy.sh (email, webhook, Slack), l’implémentation est un module de 20 lignes, pas un conteneur complet.
S3 comme seule base de données
L’état est stocké sous forme de fichiers JSON sur Scaleway Object Storage. Le client S3 est pur Python, implémentant AWS Signature Version 4 avec urllib uniquement. Pas de boto3, pas de libcurl. Cela élimine un point de défaillance majeur : si une dépendance externe devient obsolète ou incompatible, le monitoring continue de fonctionner.
Rotation des données : fenêtre temps réel → quotidien → mensuel gz
Les données ne s’accumulent pas indéfiniment. Le système utilise une rotation en trois niveaux :
| Niveau | Contenu | Durée de rétention | Taille (19 checks) |
|---|---|---|---|
| Temps réel | 48 dernières mesures (window glissante) | Écrasé à chaque run | ~70 KB |
| Quotidien | Résumé par jour (moyennes, statuts) | 30 jours | ~15 KB/jour |
| Mensuel gzip | Archive compressée des données brutes | 18 mois+ | ~200 KB/mois |
À l’échelle de l’infrastructure pivert.org (19 services, toutes les 5 minutes), l’empreinte totale sur S3 est d’environ 2 MB/mois. Le free tier Scaleway Object Storage offre 75 GB — soit théoriquement plus de 30 ans de monitoring avant d’atteindre la limite.
Dashboard statique sur S3 : zéro latence, zéro coût
Le dashboard est une page HTML/CSS/JS vanilla hébergée sur le même bucket S3 que les données. Il charge dashboard.json (snapshot régénéré à chaque run) via une requête statique — aucun appel à la fonction Scaleway n’est nécessaire pour consulter le dashboard.
C’est un détail architectural crucial : la visualisation ne coûte rien, même si vous rafraîchissez la page toutes les 10 secondes. Le fichier JSON fait ~23 KB et se charge en moins de 500 ms sur un PC standard. L’auto-refresh est activé par défaut car le nombre de clients est sans importance — il n’y a aucun re-processing, seuls des fichiers statiques (JSON/JS/HTML) sont servis depuis S3.
Modularité : ajouter un check en 4 lignes
Le système de checks est conçu pour l’extensibilité. Chaque protocole vit dans son propre module sous monitoring/modules/. Pour ajouter un nouveau type de surveillance, il suffit de créer un fichier check_{protocole}.py avec une fonction unique :
def check(config: dict) -> dict:
return {"success": bool, "msg": str, ...champs_optionnels}
Les modules existants couvrent déjà les cas les plus courants :
| Module | Ce qu’il vérifie | Extras |
|---|---|---|
check_https.py |
HTTPS + keyword | Certificat TLS AVANT la requête HTTP — même si le backend renvoie 401 ou 502. Auth basique supportée. |
check_http.py |
HTTP statut + keyword | Vérification de contenu par mot-clé |
check_tcp.py |
Connectivité TCP brute | Timeout configurable, port arbitraire |
check_smtp.py |
SMTP HELO | Port 587 (STARTTLS) car 25/465 bloqués en serverless |
check_luanti.py |
API serveur de jeu Luanti | Joueurs, lag, version, uptime |
L’exemple de check_https.py mérite une attention particulière : le certificat TLS est vérifié avant la requête HTTP. Si votre backend renvoie une erreur 502 Bad Gateway, le certificat est quand même analysé et son expiration rapportée. Cela évite les faux positifs où un service est marqué “certificat expiré” simplement parce que le check HTTP a échoué avant d’atteindre la couche TLS.
Le dashboard : conçu pour tous les écrans
Le dashboard n’est pas une console d’administration — c’est un tableau de bord d’information conçu pour être consulté rapidement sur n’importe quel appareil.
- Multi-langue (EN/FR) avec détection automatique du navigateur
- Responsive — de la smart TV au téléphone portable
- Mode TV — interface simplifiée avec tailles de police agrandies, lisible de loin sans interaction
- Plein écran au clic — chaque carte s’ouvre en modal avec URL cliquable, historique, métriques détaillées
- Auto-refresh activé par défaut avec compte à rebours visible
- Sparkline — mini-graphique des 48 dernières mesures sur chaque carte
- Groupes — organisation par catégories (gaming, wordpress, infra, web-apps…)
Alertes : confirmation progressive + récupération
Le système d’alerting évite le bruit. Une notification n’est envoyée que si un service échoue sur 2 checks consécutifs sur 3 (required=2, sample=3). Cela filtre les micro-coupures réseau sans perdre les vrais incidents.
Quand un service revient en ligne après une panne, une notification de récupération est automatiquement envoyée. Vous savez exactement quand le problème a commencé et quand il s’est terminé, sans avoir à constamment surveiller le dashboard.
Le notifier par défaut utilise ntfy.sh, mais le système supporte n’importe quel endpoint ntfy compatible : il suffit de renseigner ntfy_url dans le profil d’alerte pour pointer vers votre instance auto-hébergée.
Souveraineté et versatility : n’importe quel cloud
FrugalSentinel n’est pas lié à Scaleway. Il fonctionne sur tout cloud serverless fournissant une exécution Python + un stockage S3-compatible : AWS Lambda + S3, Google Cloud Functions + Cloud Storage, Azure Functions + Blob Storage, ou des clouds souverains français comme Scaleway ou OVHcloud.
L’absence de dépendance externe est un avantage de souveraineté : vous n’êtes pas verrouillé par un écosystème npm, pip, ou Docker. Un fichier ZIP de quelques dizaines de kilo-octets contient tout le code nécessaire. Déployé sur un cloud souverain, vos données de monitoring (URLs, historique, alertes) ne quittent jamais le territoire européen si vous ne le souhaitez pas.
Coût : 0€, et scalable à ~1€ par nouveau service
Le free tier Scaleway Functions offre 1 million de requêtes/mois et 400 000 GB-s/mois. À 256 MB et 3 secondes par run, cela représente :
- 533 333 checks à 5 minutes d’intervalle avant d’atteindre la limite
- Soit ~62 services surveillés toutes les 5 minutes avant le premier centime
Quand vous dépassez le free tier, le coût marginal est dérisoire :
| Scénario | Invocations/mois | GB-s/mois | Coût réel |
|---|---|---|---|
| 19 checks toutes les 5 min | 8 640 | 6 480 | 0.00 € |
| 50 checks toutes les 5 min | 22 680 | 17 010 | 0.00 € |
| 100 checks toutes les 1 min | 43 200 | 32 400 | 0.00 € |
| 1 nouveau service (5 min, 256MB, 3s) | +8 640 | +6 480 | ~0.03 € (hors free tier) |
L’Object Storage est également gratuit jusqu’à 75 GB. Avec une empreinte de ~2 MB/mois, la limite est théoriquement inatteignable. Vous pouvez donc augmenter la fréquence de monitoring (toutes les 1 minute, voire 30 secondes) sans crainte — le coût marginal reste inférieur à 1€ par dizaine de services supplémentaires.
Démarrer en 3 commandes
FrugalSentinel est conçu pour être opérationnel en quelques minutes :
cp .env.example .env— renseigner vos credentials S3 Scalewaypython3 handler.py— test local (mode filesystem si pas de S3 configuré)./package.sh— génèrefrugalsentinel.zipprêt pour Scaleway Functions
Le fichier config.json (template fourni via config.json.example) définit les targets, les profils d’alerte, et les groupes d’affichage. Il couvre tous les cas d’usage : HTTPS avec ou sans keyword, avec ou sans auth basique, HTTP simple, TCP brut, SMTP, et l’API Luanti. Aucune recompilation, aucun schéma de base de données à migrer.
→ Voir le README complet et le code source sur GitLab (architecture détaillée, configuration S3/IAM, endpoints API, ajout de checks personnalisés, ntfy.sh auto-hébergé)
Un exemple d’utilisation : pivert.org
FrugalSentinel est utilisé en production pour surveiller l’infrastructure de pivert.org : 4 sites WordPress, 5 applications web (Wekan, Grafana, MyGentext…), 3 hyperviseurs Proxmox, un NAS, la connectivité email (IMAP/SMTP), un serveur de jeu Luanti, et un site externe d’association. 18 services OK, 1 en FAIL — toutes les informations sont visibles en un coup d’œil sur le dashboard.
C’est un exemple concret, pas une démonstration. Le système tourne 24/7 depuis plusieurs semaines, consomme une fraction du free tier Scaleway, et n’a nécessité aucune intervention de maintenance.
Licence et code source
FrugalSentinel est publié sous licence GNU GPL, dépôt public :
gitlab.com/pivert/FrugalSentinel
Le dépôt contient le code Python complet, le dashboard HTML/JS, les templates de configuration (.env.example, config.json.example avec exemples pour tous les protocoles), les scripts de packaging/déploiement, et la documentation technique.
En résumé
FrugalSentinel prouve qu’un monitoring professionnel n’a pas besoin de :
- Docker, Kubernetes, ou serveurs dédiés
- pip install et gestion de dépendances
- Base de données ou stack complexe
- Budget mensuel
Python 3.13 + stdlib + n’importe quel cloud serverless + ntfy.sh = monitoring complet pour 0€, scalable à moins de 1€ par dizaine de services supplémentaires.