Pourquoi avez-vous besoin d'un système de sonde de serveur gratuit
Si vous avez plus de 3 VPS répartis dans différents datacenters et régions, vous avez certainement vécu cette situation : un serveur tombe soudainement en panne, vous ne le savez pas, jusqu'à ce que les clients se plaignent ou que le service soit découvert hors ligne depuis plusieurs heures.
Les solutions traditionnelles sont limitées : payer pour des services de surveillance commerciale comme UptimeRobot, ou monter vous-même un Prometheus + Grafana — le premier est limité en fonctionnalités, le second nécessite un serveur de surveillance supplémentaire à maintenir. Pour les développeurs individuels et les petites équipes, ces deux solutions ne sont pas assez élégantes.
CF-Server-Monitor offre un choix plus intelligent : Un système de surveillance multi-serveur fonctionnant entièrement avec le quota gratuit de Cloudflare. Pas de serveur propre requis, pas d'abonnement payant, le tableau de bord, l'API, la base de données et le push en temps réel fonctionnent tous sur le réseau edge de Cloudflare. À ce jour, ce projet a obtenu plus de 1 500 étoiles sur GitHub et est adopté par de nombreux passionnés de VPS et petites équipes.
Aperçu du projet : Qu'est-ce que CF-Server-Monitor
CF-Server-Monitor est un tableau de bord de surveillance multi-serveur léger déployé sur Cloudflare Workers. La stack technologique principale comprend :
- Cloudflare Workers : Fonctions de calcul edge, traitent les requêtes API et les rapports des agents
- Cloudflare D1 : Base de données SQLite edge, stockage persistant des données de surveillance
- Durable Objects : Objets avec état, push en temps réel vers le frontend via WebSocket
- Frontend Vue.js : Tableau de bord de surveillance réactif et backend d'administration
- Agent Go : Sonde légère installée sur les serveurs surveillés
Son concept de conception est simple : L'agent rapporte unidirectionnellement les métriques au Worker, le Worker écrit dans D1 et diffuse au frontend. Pas de WebSSH, pas d'exécution de commandes à distance, pas de canal maître — ce qui le rend plus sûr que les sondes traditionnelles.
Aperçu des fonctionnalités principales
| Module fonctionnel | Capacités spécifiques |
|---|---|
| Surveillance en temps réel | CPU, GPU, mémoire, swap, disque, IO disque, trafic réseau, connexions, processus, charge, temps de fonctionnement |
| Données historiques | Graphiques sur 7 jours, échantillonnage longue durée, vitesse réseau en temps réel, statistiques et correction du trafic mensuel |
| Qualité réseau | Suivi de latence et taux de perte de paquets pour les nœuds China Telecom/Unicom/Mobile/BGP |
| Tableau de bord multi-vues | Diagrammes en barres, diagrammes en anneau, tableaux, vue cartographique, adaptation desktop et mobile |
| Backend d'administration | Ajout/suppression/modification de serveurs, tri par glisser-déposer, masquage de serveurs, import/export, opérations par lot |
| Agent multiplateforme | Linux, Alpine, OpenWrt, Synology DSM, fnOS, FreeBSD, macOS, Windows |
| Push en temps réel | Durable Objects + WebSocket, rafraîchissement instantané du frontend après rapport de l'agent |
| Notifications d'alerte | Alertes hors ligne, notifications de récupération, rappels d'expiration, alertes de charge des ressources |
| Écosystème de thèmes | Thèmes intégrés, boutique de thèmes, proxy inverse et prévisualisation de thèmes tiers |
| Multilingue | Commutation chinois/anglais intégrée dans le frontend |
Pourquoi choisir Cloudflare Workers + D1
Fonctionnement sans coût
Le quota gratuit de Cloudflare est assez généreux :
- Workers : 100 000 requêtes par jour
- D1 : 5 millions de lignes en lecture, 100 000 lignes en écriture par jour
- Durable Objects : 100 000 requêtes par jour
CF-Server-Monitor a été spécialement optimisé pour ces quotas : l'intervalle de rapport par défaut de 60 secondes peut prendre en charge environ 60 serveurs, passer à 120 secondes peut théoriquement doubler la capacité. Les requêtes historiques utilisent des stratégies d'échantillonnage, les tables de données mensuelles tournent automatiquement, combinées avec la mise en cache et la limitation de débit, pour s'assurer de ne pas dépasser le quota gratuit.
Calcul edge mondial
Cloudflare a des nœuds edge dans plus de 300 villes dans le monde. Les Workers fonctionnent sur les nœuds les plus proches des utilisateurs, la latence de réponse API est extrêmement faible. La base de données D1 est également basée sur l'architecture edge, les opérations de lecture et d'écriture sont toutes effectuées en edge, pas besoin de revenir à un serveur central.
Sans maintenance
Pas de serveur à patcher, pas de conteneurs Docker à redémarrer, pas de base de données à sauvegarder. Cloudflare héberge toute l'infrastructure, vous n'avez qu'à vous concentrer sur les serveurs surveillés eux-mêmes.
Comparaison avec d'autres outils de surveillance
| Fonctionnalité | CF-Server-Monitor | UptimeRobot | Prometheus + Grafana | Netdata |
|---|---|---|---|---|
| Coût | Gratuit (quota gratuit Cloudflare) | Gratuit pour 50 surveillances | Gratuit (serveur propre requis) | Gratuit (serveur propre requis) |
| Serveur propre requis | Non | Non | Oui | Oui |
| Métriques serveur | CPU/mémoire/disque/réseau toutes métriques | Codes d'état HTTP uniquement | Toutes métriques (configuration requise) | Toutes métriques |
| Push en temps réel | Push instantané WebSocket | Scrutation | Configuration supplémentaire requise | Temps réel |
| Coût de maintenance | Zéro (hébergé par Cloudflare) | Zéro | Élevé (serveur à maintenir) | Moyen |
| Alertes hors ligne | Pris en charge (Telegram/WeChat/DingTalk etc.) | Pris en charge (limité) | Configuration Alertmanager requise | Pris en charge |
| Données historiques | 7 jours | Dépend de la solution | Illimité (dépend du stockage) | Limité |
| Sécurité | Rapport unidirectionnel, pas de canal distant | N/A | À sécuriser soi-même | Risque WebSSH |
Pour les développeurs individuels et petites équipes possédant plusieurs VPS, CF-Server-Monitor présente des avantages évidents en termes de coût et de commodité. Si vous avez besoin de données historiques de taille PB ou d'un SLA d'entreprise, Prometheus + Thanos pourrait être plus approprié.
Analyse de l'architecture système
┌─────────────────┐ POST /update ┌──────────────────────┐
│ Server Agent │ ───────────────────> │ Cloudflare Worker │
│ (Go/Shell/PS) │ │ (Fonction edge) │
└─────────────────┘ └──────────┬───────────┘
│
┌───────────┼───────────┐
│ │ │
┌────▼───┐ ┌────▼────┐ ┌───▼────┐
│ D1 │ │Durable │ │ Vue │
│ SQLite │ │Objects │ │Frontend│
│ Base │ │WebSocket│ │Tableau │
│ données│ │ │ │de bord │
└────────┘ └────┬────┘ └───┬────┘
│ │
┌────▼──────────▼───┐
│ Navigateur/Mobile │
│ Affichage temps │
│ réel des données │
└───────────────────┘
Flux de données principal :
- Ajouter un serveur dans le backend d'administration, copier la commande d'installation
- Installer l'agent sur le serveur cible, envoie les métriques au Worker à l'intervalle configuré
- Le Worker valide
API_SECRET, écrit dans D1 et diffuse les données en temps réel via Durable Object - Le tableau de bord frontal, la page de détails, le backend d'administration et le widget iOS lisent la même API
Déploiement en pratique : Construire un système de surveillance de zéro
Préparation préalable
- Un compte Cloudflare (version gratuite suffisante)
- Un compte GitHub
- Un
API_SECRETsuffisamment complexe (sert simultanément de clé de rapport de l'agent et de mot de passe initial du backend)
Méthode 1 : Cloudflare Workers connecte GitHub (recommandé)
C'est la méthode de déploiement la plus pratique, les mises à jour ultérieures sont également faciles à synchroniser.
Étape 1 : Forker le dépôt
Visitez le dépôt GitHub CF-Server-Monitor, cliquez sur le bouton Fork.
Étape 2 : Créer le Worker
- Se connecter au tableau de bord Cloudflare
- Aller dans Workers & Pages
- Cliquer sur "Créer un Worker"
- Sélectionner "Connecter un dépôt GitHub", importer votre dépôt forké
Étape 3 : Configurer le build
- Commande de build :
npm run build:frontend - Commande de déploiement :
npx wrangler deploy
Étape 4 : Ajouter les variables d'environnement
Dans les Variables and Secrets du Worker, ajouter :
| Nom de variable | Valeur | Description |
|---|---|---|
API_SECRET |
Votre mot de passe fort | Clé de rapport de l'agent + mot de passe initial du backend |
Étape 5 : Déployer
Cliquer sur Déployer, attendre la fin du build. Après un déploiement réussi, vous obtiendrez un domaine xxx.workers.dev.
Méthode 2 : Déploiement automatique GitHub Actions
Convient aux utilisateurs qui souhaitent gérer entièrement le processus de déploiement via GitHub.
- Forker le dépôt
- Créer une base de données D1 dans Cloudflare (nom suggéré :
server-monitor-db) - Copier l'ID de compte Cloudflare
- Créer un jeton API Cloudflare (nécessite les permissions d'édition Workers et de déploiement D1)
- Dans le dépôt forké, Settings → Secrets → Actions, ajouter :
CF_API_TOKEN: Votre jeton API Cloudflare
CF_ACCOUNT_ID: Votre ID de compte Cloudflare
D1_DATABASE_ID: ID de la base de données D1
API_SECRET: Votre mot de passe fort
CORS_ALLOWED_ORIGINS: (optionnel) Sources cross-origin autorisées
Un push vers la branche main déclenche le déploiement automatique.
Méthode 3 : Déploiement en un clic
Le déploiement en un clic convient pour une expérience rapide, mais pour une maintenance à long terme, il est recommandé de migrer vers les deux premières méthodes.
Première utilisation : Connexion au backend et ajout de serveurs
Connexion au backend d'administration
Après un déploiement réussi, accéder à :
https://votre-domaine-Worker/admin#/admin
Identifiants par défaut :
- Nom d'utilisateur :
admin - Mot de passe : Votre
API_SECRETconfiguré
Après la connexion, changez immédiatement le nom d'utilisateur et le mot de passe de l'administrateur. Le mot de passe du backend peut être séparé du API_SECRET — le rapport de l'agent utilise toujours le API_SECRET des variables d'environnement, mais le mot de passe de connexion au backend peut être défini indépendamment.
Ajouter le premier serveur
- Aller dans
/admin#/admin - Dans "Gestion des serveurs", remplir le nom du serveur
- Cliquer sur "Ajouter un serveur"
- Cliquer sur le bouton de copie, sélectionner le système cible et la version de l'agent
- Exécuter la commande d'installation générée sur le serveur cible
Les commandes générées par le backend incluent automatiquement l'ID du serveur, l'URL du Worker, le Secret, l'intervalle de rapport et d'autres paramètres, ce qui est plus fiable que de les assembler manuellement.
Configuration des serveurs surveillés : Installation de l'agent et rapport de données
Agent Go (recommandé)
À partir de la v2.8.3, l'cfsm-agent indépendant (écrit en Go) est utilisé par défaut, après installation le nom du service est cf-probe.
Installation non-root (recommandée)
Pour les environnements Linux supportant systemd --user, il est recommandé d'installer en tant qu'utilisateur non-root :
# Passer à l'utilisateur normal
su - votreutilisateur
# Exécuter la commande d'installation générée par le backend (exemple)
curl -sSL https://votre-worker.example.com/install | bash -s -- \
-id 1 \
-secret "votre-api-secret" \
-url "https://votre-worker.example.com" \
-interval 60
Après installation, les fichiers sont écrits dans ~/.cf-probe/, systemd --user gère le démarrage automatique.
Si vous souhaitez que le service continue de fonctionner après la déconnexion de l'utilisateur :
# Exécuté par root
loginctl enable-linger votreutilisateur
Installation root
Si l'utilisation d'un utilisateur non-root n'est pas pratique, vous pouvez également installer directement en root :
curl -sSL https://votre-worker.example.com/install | bash -s -- \
-id 1 \
-secret "votre-api-secret" \
-url "https://votre-worker.example.com"
Paramètres courants de l'agent
| Paramètre | Description | Valeur par défaut |
|---|---|---|
-id |
ID unique du serveur | Requis |
-secret |
Clé de rapport de l'agent, doit être égale à API_SECRET |
Requis |
-url |
Adresse de rapport du Worker | Requis |
-collect_interval |
Intervalle de collecte local supplémentaire, 0 signifie pas d'échantillonnage supplémentaire |
0 |
-interval |
Intervalle de rapport (secondes) | 60 |
-ct / -cu / -cm / -bd |
Nœuds de test de qualité réseau personnalisés | Nœuds intégrés |
-reset_day |
Jour de réinitialisation du trafic mensuel | 1 |
-rx_correction |
Correction du trafic mensuel descendant (GB) | Vide |
-tx_correction |
Correction du trafic mensuel montant (GB) | Vide |
Plates-formes prises en charge
- Linux : Ubuntu, Debian, CentOS, Rocky Linux, AlmaLinux et autres distributions principales
- Alpine Linux : Utilise OpenRC pour la gestion
- OpenWrt : Adapté aux routeurs
- Synology DSM : Surveillance NAS
- fnOS : Système NAS chinois
- FreeBSD : Support des systèmes BSD
- macOS : Surveillance des machines de développement
- Windows : Version PowerShell
Détails des fonctionnalités du tableau de bord de surveillance
Affichage de l'état en temps réel
Le tableau de bord frontal prend en charge quatre modes de vue :
- Mode diagramme en barres : Affichage intuitif de l'utilisation CPU/mémoire/disque de chaque serveur
- Mode diagramme en anneau : Affichage compact, adapté aux scénarios avec de nombreux serveurs
- Mode tableau : Liste de données détaillée, prend en charge le tri et le filtrage
- Mode carte : Affichage de la distribution des serveurs basé sur la géolocalisation
Chaque mode prend en charge l'adaptation desktop et mobile.
Données historiques et graphiques
- Graphiques sur 7 jours : Séries temporelles pour CPU, mémoire, disque, trafic réseau
- Échantillonnage longue durée : Les requêtes historiques utilisent des stratégies d'échantillonnage pour éviter le dépassement de D1
- Vitesse réseau en temps réel : Courbes en temps réel des taux d'upload/download
- Statistiques de trafic mensuel : Prend en charge le jour de réinitialisation du trafic et la correction montant/descendant
Surveillance de la qualité réseau
Prend en charge le suivi de latence et taux de perte de paquets pour les quatre réseaux China Telecom, Unicom, Mobile, BGP. Après activation des détails des trois réseaux, la page d'accueil affiche à partir des dernières 2 heures de D1 un maximum de 20 points de données réels, mis en cache pendant 5 minutes.
Notifications d'alerte
Configurables dans Backend d'administration → Paramètres globaux → Notifications. Canaux de notification pris en charge :
| Plateforme | Méthode de configuration |
|---|---|
| Telegram | BotFather Bot Token + Chat ID |
| WeCom | URL Webhook du bot de groupe |
| Lark | URL Webhook du bot de groupe |
| DingTalk | URL Webhook du bot personnalisé |
| Bark | https://api.day.app/xxxx/ |
| ServerChan | https://sctapi.ftqq.com/<SendKey>.send |
| Gotify | https://gotify.example.com/message?token=xxx |
| Webhook personnalisé | Tout point de terminaison HTTP POST |
Les types d'alerte incluent : Alerte hors ligne, notification de récupération, rappel d'expiration, alerte de charge des ressources.
Configuration avancée
Domaine personnalisé
Dans le tableau de bord Cloudflare, lier un domaine personnalisé au Worker :
- Aller dans Paramètres du Worker → Déclencheurs
- Ajouter un domaine personnalisé (par exemple
monitor.votredomaine.com) - Cloudflare gère automatiquement les certificats SSL et la résolution DNS
Agrégation multi-Workers
Si vous avez plusieurs instances de Worker (réparties sur différents comptes Cloudflare), vous pouvez agréger via la variable d'environnement API_BASE :
API_BASE: "https://worker1.example.com,https://worker2.example.com"
Le frontend demandera simultanément plusieurs Workers et affichera les résultats fusionnés.
Frontend statique GitHub Pages
Le projet prend en charge la construction du frontend en tant que site statique pour GitHub Pages, récupérant les données via l'API Worker distante :
# Commande de build
npm run build:github-page
API_BASE doit être configuré dans les GitHub Secrets pour pointer vers votre adresse Worker.
Widget iOS Scriptable
Le projet fournit des scripts de widget iOS Scriptable, pouvant afficher l'état d'un seul serveur sur le bureau de l'iPhone :
- Installer l'application Scriptable
- Créer un nouveau script, coller le contenu de
scripts/ios-scriptable-widget.js - Modifier
CONFIG.baseURLen haut pour votre adresse de site - Ajouter un widget Scriptable, remplir le Paramètre avec l'ID du serveur
Le widget affiche l'état en ligne, CPU, mémoire, disque, trafic mensuel, taux en temps réel et heure de mise à jour.
Renforcement de la sécurité
- Vérification Turnstile : Activer Cloudflare Turnstile dans les paramètres de sécurité du backend pour prévenir les attaques par force brute
- Liste blanche CORS : Restreindre les sources d'accès API via
CORS_ALLOWED_ORIGINS - Politique CSP : Politique de sécurité de contenu personnalisée pour prévenir les attaques XSS
- JWT Secret : Clé de signature JWT définie indépendamment, séparée de
API_SECRET
Optimisation des performances et contrôle des coûts
Optimisation du quota gratuit Cloudflare
CF-Server-Monitor intègre plusieurs conceptions respectueuses du quota :
- Rotation des tables de données mensuelles : Les données historiques sont divisées par mois pour éviter les tables trop grandes
- Échantillonnage des requêtes historiques : Les requêtes de longue période utilisent un échantillonnage automatique pour réduire les lignes lues de D1
- Stratégie de mise en cache : Les détails des trois réseaux sont mis en cache pendant 5 minutes pour réduire les requêtes répétées
- Conception de limitation de débit : Limitation de la fréquence des requêtes API pour prévenir le spam malveillant de l'interface
Optimisation de l'intervalle de rapport
| Scénario | Intervalle recommandé | Nombre de serveurs pris en charge |
|---|---|---|
| Surveillance en temps réel (60 secondes) | -interval 60 |
~60 serveurs |
| Surveillance normale (120 secondes) | -interval 120 |
~120 serveurs |
| Surveillance basse consommation (300 secondes) | -interval 300 |
~300 serveurs |
Si vous avez de nombreux serveurs, il est recommandé d'ajuster l'intervalle de rapport à 120 secondes ou plus. Pour la plupart des scénarios, une granularité de surveillance de 2 minutes est suffisante.
Optimisation du rapport WSS
La v2.8.4 a introduit la capacité de rapport WSS (WebSocket Secure). L'agent peut utiliser WSS pour le rapport pendant certaines périodes, améliorant la rapidité du push de données en temps réel ; hors des périodes cibles, il passe automatiquement à POST pour réduire la consommation de durée des Durable Objects.
Limitations et précautions
Limites du quota gratuit
- Limite de stockage D1 : La base de données D1 gratuite a une taille maximale de 500 Mo, en cas d'exécution à long terme, les données historiques doivent être nettoyées régulièrement
- Requêtes Workers : 100 000 requêtes par jour, 60 serveurs × intervalle de 60 secondes ≈ 86 400 fois/jour, proche de la limite
- Durable Objects : La version gratuite a des limites de concurrence, de nombreuses connexions frontend simultanées peuvent déclencher une limitation de débit
Limitations fonctionnelles
- Données historiques sur 7 jours uniquement : Limité par le quota gratuit D1, les données de plus de 7 jours sont échantillonnées ou nettoyées
- Pas de WebSSH : Pour des raisons de sécurité, aucune fonction de terminal distant n'est fournie (ce qui est en fait un avantage)
- Dépendance à Cloudflare : Si le service Cloudflare est interrompu, le système de surveillance sera également indisponible
Recommandations de sécurité
- Mot de passe fort :
API_SECRETdoit être un mot de passe fort aléatoire, ne pas utiliser les valeurs par défaut - Changer le mot de passe rapidement : Après la première connexion, changer immédiatement le nom d'utilisateur et le mot de passe de l'administrateur
- Exécution non-root : Installer l'agent autant que possible en tant qu'utilisateur non-root
- Mises à jour régulières : Suivre les mises à jour du projet, mettre à jour les versions Worker et Agent en temps opportun
Résumé
CF-Server-Monitor est l'une des solutions de surveillance de serveur gratuites les plus élégantes. Il utilise habilement le quota gratuit de Cloudflare, hébergeant le tableau de bord, l'API, la base de données et le push en temps réel entièrement sur le réseau edge, réalisant un vrai coût zéro et maintenance zéro.
Convient à :
- Développeurs individuels possédant plusieurs VPS
- Petites équipes ayant besoin d'une surveillance légère
- Utilisateurs ne souhaitant pas maintenir de serveur de surveillance
- Utilisateurs soucieux de la sécurité (rapport unidirectionnel, pas de canal distant)
Ne convient pas à :
- Utilisateurs d'entreprise ayant besoin de données historiques de taille PB
- Utilisateurs ayant besoin de WebSSH et d'exécution de commandes à distance
- Environnements de production avec des exigences SLA strictes
Si vous recherchez une solution de surveillance multi-serveur gratuite, sécurisée et facile à utiliser, CF-Server-Monitor vaut le coup d'essai. Il ne remplacera peut-être pas la solution d'entreprise Prometheus + Grafana, mais pour les développeurs individuels et les petites équipes, c'est largement suffisant.
Adresse du projet : https://github.com/huilang-me/CF-Server-Monitor Démo en ligne : https://demo.huilang.me/
Questions fréquemment posées (FAQ)
1. CF-Server-Monitor est-il vraiment entièrement gratuit ?
Oui, tant que votre échelle de surveillance est dans le quota gratuit de Cloudflare (100 000 requêtes Workers par jour, 5 millions de lectures D1), vous n'avez pas besoin de dépenser un centime. L'intervalle de rapport par défaut de 60 secondes prend en charge environ 60 serveurs, passer à 120 secondes peut doubler la capacité.
2. Où sont stockées les données ? Est-ce sécurisé ?
Les données sont stockées dans Cloudflare D1 (base de données SQLite edge), hébergées par Cloudflare. L'agent utilise une conception de rapport unidirectionnel, ne fournit pas de fonctions WebSSH ou d'exécution de commandes à distance, même si l'agent est compromis, le serveur ne peut pas être contrôlé à distance.
3. Quels systèmes d'exploitation sont pris en charge ?
Prend en charge les distributions Linux principales (Ubuntu, Debian, CentOS etc.), Alpine Linux, OpenWrt, Synology DSM, fnOS, FreeBSD, macOS et Windows. Utilise par défaut l'agent écrit en Go, offrant de meilleures performances et une compatibilité multiplateforme plus forte.
4. Comment recevoir les notifications d'alerte hors ligne ?
Configurable dans Backend d'administration → Paramètres globaux → Notifications. Prend en charge Telegram, WeCom, Lark, DingTalk, Bark, ServerChan, Gotify et les webhooks personnalisés. Après configuration, les notifications sont envoyées immédiatement lorsque le serveur est hors ligne.
5. Puis-je lier un domaine personnalisé ?
Oui. Ajoutez un domaine personnalisé dans les paramètres du Worker du tableau de bord Cloudflare, Cloudflare gère automatiquement les certificats SSL et la résolution DNS. Prend également en charge le déploiement du frontend sur GitHub Pages avec un domaine personnalisé.