[{"data":1,"prerenderedAt":215},["ShallowReactive",2],{"seo-verification":3,"blog-alertes-disque-ram-vps-monitoring-proactif-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-alertes-disque-ram-vps-monitoring-proactif-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":155,"ctaBody":156,"ctaButton":157,"ctaUrl":158,"relatedPosts":159},506,"alertes-disque-ram-vps-monitoring-proactif",{"fr":10,"en":12,"ar":13,"es":14},"disk-full-and-ram-alerts-on-a-vps-no-monitoring-stack-needed","تنبيهات-امتلاء-القرص-والذاكرة-على-vps-دون-منظومة-مراقبة","alertas-de-disco-lleno-y-ram-en-un-vps-sin-pila-de-supervision","Alertes disque plein et RAM sur VPS, sans stack de supervision","Six alertes shell pour vos VPS clients : disque, inodes, OOM, services systemd, certificats, sauvegardes, avec un battement de cœur qui surveille le contrôle.",13,0,false,"2026-10-27T00:00:00+00:00","2026-10-27T23:58:39+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Falertes-disque-ram-vps-monitoring-proactif-poster.svg","Un disque se remplit, la base de données s'arrête, et le client l'apprend avant vous. Le coût est une intervention en urgence et une confiance entamée. Une stack de supervision complète est un second serveur à entretenir, donc beaucoup d'agences y renoncent et ne surveillent rien. Ce guide pose six alertes minimales en shell sur chaque VPS : disque, inodes, mémoire, services, certificats, sauvegardes. Le contrôle est surveillé à son tour par un battement de cœur externe.",[35,39,50,53,56,87,90,93,96,132,136,139,149,152],{"type":36,"title":37,"body":38},"h2","Le disque plein ne prévient personne","Le scénario revient sans cesse. Un VPS client tourne depuis des mois, la base de données écrit ses journaux, les sauvegardes s'empilent, et un matin le service s'arrête. Aucune alerte n'est partie, le client l'apprend avant vous. Sur PostgreSQL, un cas rapporté sur la liste officielle du projet montre la ligne exacte : `PANIC: could not write to file \"pg_wal\u002Fxlogtemp.11399\": No space left on device`. Un PANIC n'est pas un simple avertissement : le serveur ne peut plus journaliser ses écritures, il s'arrête, et il ne redémarre proprement qu'une fois de la place libérée.\n\nLa difficulté n'est pas de détecter un disque plein, c'est de le détecter avant. Entre 80 % d'occupation et la panne, il reste souvent des heures ou des jours, et c'est exactement la fenêtre qu'une alerte bien réglée doit capter. Ce guide ne refait pas l'installation d'une stack de supervision : il pose le minimum utile sur chaque VPS, en shell, sans second serveur à entretenir.",{"type":40,"title":41,"items":42},"ul","Les six alertes minimales et le battement de cœur, sur chaque VPS",[43,44,45,46,47,48,49],"**Disque** — deux seuils, 80 % en avertissement et 90 % en critique, sur chaque point de montage utile.","**Inodes** — un disque peut refuser d'écrire alors qu'il reste de la place en octets, si les inodes sont épuisés.","**Mémoire et OOM** — détecter qu'un processus a été tué par le noyau, pas seulement que la RAM est haute.","**Services systemd** — être prévenu quand la base, le serveur web ou le proxy passe à l'état failed.","**Certificats** — alerter 21 jours avant l'échéance, quand le renouvellement automatique a échoué en silence.","**Sauvegardes** — alerter sur l'absence de succès récent, pas seulement sur une erreur explicite.","**Le contrôle lui-même** — un battement de cœur externe qui prévient quand les alertes cessent de partir.",{"type":36,"title":51,"body":52},"Prérequis chiffrés : presque rien","Tout ce qui suit tient dans quelques dizaines de lignes de shell POSIX. Il faut un VPS Linux avec `curl`, `cron` ou les timers systemd, un accès root pour écrire dans `\u002Fusr\u002Flocal\u002Fbin` et `\u002Fetc`, et environ 1 Mo de disque.\n\nDeux éléments externes complètent le dispositif : un canal de réception (un bot Telegram, ou n'importe quel webhook accessible en HTTP) et un service de battement de cœur, qui reçoit un ping régulier et vous prévient quand il s'arrête. Pour ce second point, Healthchecks.io propose un plan gratuit limité à 20 jobs et 100 entrées de journal par job, ce qui couvre largement un parc de petite taille ; vérifiez ces limites à la source avant de vous y fier. Le mode push d'Uptime Kuma remplit le même rôle sur une machine à vous.",{"type":36,"title":54,"body":55},"Disque et inodes : les seuils et ce qui les déplace","La commande utile est `df -h --output=pcent,target` : elle n'affiche que le pourcentage et le point de montage, ce qui se lit et se parse facilement. Pour les inodes, la même idée devient `df --output=ipcent,target`. Un dossier de sessions ou de petits fichiers de cache peut consommer tous les inodes d'un système de fichiers ext4 alors que `df -h` affiche encore 40 % d'occupation : l'écriture échoue pourtant avec le même `No space left on device`.\n\nIl y a une seconde subtilité. Sur ext4, 5 % des blocs sont réservés par défaut aux processus privilégiés, d'après la page de manuel de `tune2fs` ; c'est ce qui permet aux démons système de continuer à écrire quand un utilisateur ordinaire a rempli le disque. Conséquence : un service qui tourne sous un compte non privilégié, comme la base de données, voit `df` afficher 100 % alors que le disque est occupé à environ 95 %. D'où les seuils retenus : 80 % pour avoir le temps d'agir, 90 % pour agir tout de suite. Attendre 100 % revient à alerter après la panne.",{"type":57,"title":58,"steps":59},"steps","Poser le dispositif en une heure",[60,63,66,69,72,75,78,81,84],{"title":61,"body":62},"Créer le canal d'alerte","Créez un bot Telegram avec BotFather, notez son jeton et l'identifiant de la conversation qui doit recevoir les messages. Toutes les requêtes de l'API Bot suivent la forme `https:\u002F\u002Fapi.telegram.org\u002Fbot\u003Ctoken>\u002FMETHOD_NAME`, et la méthode d'envoi est `sendMessage`.",{"title":64,"body":65},"Écrire le fichier d'environnement","`sudo mkdir -p \u002Fvar\u002Flib\u002Falerte-vps`\n`sudo install -m 600 \u002Fdev\u002Fnull \u002Fetc\u002Falerte-vps.env`\nPuis ajoutez-y quatre lignes : `TG_TOKEN=...`, `TG_CHAT=...`, `HC_URL=https:\u002F\u002Fhc-ping.com\u002F\u003Cuuid>` (check toutes les cinq minutes) et `HC_URL_JOUR=https:\u002F\u002Fhc-ping.com\u002F\u003Cautre-uuid>` (check quotidien). Le mode 600 garde le jeton lisible par root seul.",{"title":67,"body":68},"Écrire le script d'envoi avec anti-répétition","Enregistrez ces lignes dans `\u002Fusr\u002Flocal\u002Fbin\u002Falerte-envoi` puis rendez le fichier exécutable avec `sudo chmod 755`. Le fichier de verrou par message évite d'être réveillé toutes les cinq minutes pour la même alerte : un message identique n'est renvoyé qu'après une heure.\n`#!\u002Fbin\u002Fsh`\n`. \u002Fetc\u002Falerte-vps.env`\n`f=\u002Fvar\u002Flib\u002Falerte-vps\u002F$(echo \"$1\" | md5sum | cut -c1-12)`\n`[ -n \"$(find \"$f\" -mmin -60 2>\u002Fdev\u002Fnull)\" ] && exit 0`\n`touch \"$f\"`\n`curl -fsS -m 10 --retry 3 \"https:\u002F\u002Fapi.telegram.org\u002Fbot${TG_TOKEN}\u002FsendMessage\" -d chat_id=\"${TG_CHAT}\" --data-urlencode text=\"$(hostname) $1\"`",{"title":70,"body":71},"Contrôler disque et inodes","Dans `\u002Fusr\u002Flocal\u002Fbin\u002Falerte-rapide` (shebang `#!\u002Fbin\u002Fsh`), ajoutez les deux boucles suivantes. Le filtre `grep -v` écarte les systèmes de fichiers qui n'exposent pas d'inodes et affichent un tiret.\n`df --output=pcent,target -x tmpfs -x devtmpfs | tail -n +2 | while read p m; do n=${p%\\%}; if [ \"$n\" -ge 90 ]; then alerte-envoi \"CRIT disk $m\"; elif [ \"$n\" -ge 80 ]; then alerte-envoi \"WARN disk $m\"; fi; done`\n`df --output=ipcent,target -x tmpfs -x devtmpfs | tail -n +2 | grep -v '^ *-' | while read p m; do [ \"${p%\\%}\" -ge 90 ] && alerte-envoi \"INODES $m\"; done`",{"title":73,"body":74},"Détecter les processus tués par l'OOM killer","Le compteur `oom_kill` de `\u002Fproc\u002Fvmstat` ne fait que croître depuis le démarrage. On le compare à la valeur précédente, conservée dans un fichier ; après un redémarrage le compteur repart de zéro, la comparaison est fausse une fois, puis se rétablit.\n`n=$(awk '\u002F^oom_kill\u002F {print $2}' \u002Fproc\u002Fvmstat)`\n`old=$(cat \u002Fvar\u002Flib\u002Falerte-vps\u002Foom 2>\u002Fdev\u002Fnull || echo 0)`\n`[ \"$n\" -gt \"$old\" ] && alerte-envoi \"OOM kill\"`\n`echo \"$n\" > \u002Fvar\u002Flib\u002Falerte-vps\u002Foom`",{"title":76,"body":77},"Ajouter le battement de cœur et planifier","Terminez `alerte-rapide` par le ping. Il n'est atteint que si le script a tourné jusqu'au bout ; si cron s'arrête, si le disque est en lecture seule ou si le script plante, le ping cesse et le service externe vous prévient. Ajoutez ensuite les lignes de cron dans `\u002Fetc\u002Fcron.d\u002Falerte-vps`.\n`. \u002Fetc\u002Falerte-vps.env; curl -fsS -m 10 --retry 5 -o \u002Fdev\u002Fnull \"$HC_URL\"`\n`PATH=\u002Fusr\u002Flocal\u002Fbin:\u002Fusr\u002Fbin:\u002Fbin`\n`*\u002F5 * * * * root \u002Fusr\u002Flocal\u002Fbin\u002Falerte-rapide`\n`30 7 * * * root \u002Fusr\u002Flocal\u002Fbin\u002Falerte-quotidien`",{"title":79,"body":80},"Contrôler certificats et sauvegardes une fois par jour","Dans `\u002Fusr\u002Flocal\u002Fbin\u002Falerte-quotidien`, ajoutez ces lignes. L'option `-checkend` d'`openssl x509` échoue si le certificat expire dans le nombre de secondes donné ; 1814400 secondes valent 21 jours. Le test de sauvegarde alerte quand aucun fichier `.gz` non vide n'est plus récent que 1560 minutes, soit 26 heures. Le script se termine par son propre ping, vers le second check : sans lui, un contrôle quotidien tombé en silence passerait inaperçu.\n`echo | openssl s_client -servername votre-domaine.com -connect votre-domaine.com:443 2>\u002Fdev\u002Fnull | openssl x509 -noout -checkend 1814400 || alerte-envoi \"CERT votre-domaine.com\"`\n`find \u002Fvar\u002Fbackups\u002Fapp -name '*.gz' -mmin -1560 -size +1k | grep -q . || alerte-envoi \"BACKUP absent\"`\n`. \u002Fetc\u002Falerte-vps.env; curl -fsS -m 10 --retry 5 -o \u002Fdev\u002Fnull \"$HC_URL_JOUR\"`",{"title":82,"body":83},"Brancher les services critiques sur OnFailure","Créez `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fnotify-failure@.service` avec le contenu suivant, puis `sudo systemctl daemon-reload`.\n`[Unit]`\n`Description=Alerte echec de %i`\n`[Service]`\n`Type=oneshot`\n`ExecStart=\u002Fusr\u002Flocal\u002Fbin\u002Falerte-envoi \"FAILED %i\"`\nPour chaque service à surveiller, ouvrez un drop-in avec `sudo systemctl edit mariadb.service` et ajoutez ces deux lignes.\n`[Unit]`\n`OnFailure=notify-failure@%n.service`",{"title":85,"body":86},"Forcer une alerte pour tester, puis nettoyer","Une alerte jamais déclenchée n'est pas une alerte. Vérifiez d'abord l'espace libre, créez un fichier assez gros pour franchir le seuil, lancez le script à la main, puis supprimez le fichier. Si le message n'arrive pas, le défaut est dans le canal, et il vaut mieux le découvrir maintenant.\n`df -h --output=pcent,target \u002Fvar\u002Ftmp`\n`sudo fallocate -l 2G \u002Fvar\u002Ftmp\u002Ftest-alerte.img`\n`sudo \u002Fusr\u002Flocal\u002Fbin\u002Falerte-rapide`\n`sudo rm \u002Fvar\u002Ftmp\u002Ftest-alerte.img`",{"type":36,"title":88,"body":89},"Mémoire : OOM du noyau ou limite de cgroup","Deux mécanismes tuent un processus pour manque de mémoire, et ils ne se lisent pas au même endroit. Le premier est l'OOM killer du noyau, quand la machine entière manque de RAM : le journal du noyau contient alors un message du type `Out of memory: Killed process`, que `journalctl -k` permet de retrouver. Le second est la limite d'un cgroup. Selon la documentation de systemd, quand l'usage d'une unité ne peut pas être contenu sous `MemoryMax=`, l'OOM killer est invoqué à l'intérieur de l'unité : le reste de la machine peut avoir de la mémoire libre.\n\nLe compteur `oom_kill` de `\u002Fproc\u002Fvmstat` couvre le premier cas à l'échelle de la machine. Pour une unité précise, le fichier `memory.events` de son cgroup expose un compteur `oom_kill` propre, défini par la documentation du noyau comme le nombre de processus du cgroup tués par n'importe quel type d'OOM killer. Sur un VPS qui héberge une application gourmande, comme celle décrite dans \u003Ca href=\"\u002Fblog\u002Fn8n-erreurs-memoire-oom-production-vps\">le guide n8n et OOM en production\u003C\u002Fa>, c'est ce second compteur qui explique les arrêts que `free -h` ne montre jamais.",{"type":36,"title":91,"body":92},"OnFailure : ce qu'il couvre et ce qu'il ne couvre pas","Selon la documentation de systemd, `OnFailure=` liste les unités activées quand l'unité entre dans l'état failed. Le gabarit `notify-failure@.service` reçoit le nom de l'unité fautive grâce au spécificateur `%n`, et le message d'alerte peut y joindre la sortie de `systemctl status` ou de `journalctl -u` pour le contexte.\n\nLa limite est structurelle : un service qui tourne mais ne répond plus n'est jamais passé par l'état failed, donc `OnFailure=` ne dit rien. Un service relancé par `Restart=` n'y arrive qu'une fois la limite de démarrage atteinte. Pour ces cas, ajoutez une sonde applicative simple, par exemple un `curl` sur l'adresse de santé de l'application, dans le script rapide. La syntaxe des timers et de cron est traitée dans \u003Ca href=\"\u002Fblog\u002Fcron-systemd-timers-automatisation-vps\">le guide cron et timers systemd\u003C\u002Fa>, et il n'y a pas lieu de la répéter ici.",{"type":36,"title":94,"body":95},"Certificats et sauvegardes : alerter sur l'absence de succès","Un renouvellement automatique de certificat peut échouer en silence pendant des semaines : un enregistrement DNS modifié, un port bloqué, un plugin cassé. Le test `openssl` interroge ce que le visiteur reçoit réellement, ce qui vaut mieux que de lire un fichier sur le disque. Sur un serveur géré par Certbot, `certbot certificates` liste les certificats et leur échéance, et `certbot renew --dry-run` vérifie que le renouvellement futur aboutira.\n\nMême logique pour les sauvegardes. Une alerte déclenchée par l'échec d'un script de sauvegarde ne voit pas le cas où le script ne s'est jamais lancé. L'alerte correcte se pose sur l'absence : aucun fichier récent, ou un fichier de taille nulle. C'est ce que fait la ligne `find -mmin` du script quotidien, et c'est pourquoi elle reste muette quand tout va bien et bavarde dès que la chaîne de sauvegarde s'arrête, quelle qu'en soit la raison.",{"type":97,"title":98,"headers":99,"rows":103},"comparison","Scripts maison ou stack de supervision",[100,101,102],"Critère","Scripts shell et OnFailure","Beszel ou Uptime Kuma",[104,108,112,116,120,124,128],[105,106,107],"Mise en place","Une heure, quelques fichiers dans `\u002Fusr\u002Flocal\u002Fbin`","Un hub à héberger, des agents à installer sur chaque VPS",[109,110,111],"Parc visé","1 à 5 VPS, jusqu'à 10 si les seuils sont identiques","Au-delà de 5 à 10 VPS, ou dès qu'il faut comparer",[113,114,115],"Historique et courbes","Aucun, seulement l'instant de l'alerte","Graphiques, tendances, comparaison entre machines",[117,118,119],"Entretien","Rien à mettre à jour hors du shell","Un second serveur et ses mises à jour à tenir",[121,122,123],"Services applicatifs","Sonde `curl` à écrire soi-même","Sondes HTTP, TCP et page de statut prêtes à l'emploi",[125,126,127],"Panne du moniteur","Détectée par le battement de cœur externe","À surveiller séparément, le hub est lui-même une machine",[129,130,131],"Quand le choisir","Alertes minimales, parc réduit, zéro serveur en plus","Historique voulu, parc en croissance, équipe partagée",{"type":133,"title":134,"body":135},"tip","Surveillez le surveillant","Le piège de ces scripts est de devenir une fausse assurance : ils se taisent parce que tout va bien, ou parce qu'ils sont cassés, et le silence ressemble dans les deux cas. Le ping de battement de cœur règle le problème. Réglez la période attendue du check un peu au-dessus de l'intervalle de cron, avec une marge de tolérance. Gardez aussi `\u002Fetc\u002Falerte-vps.env` en mode 600 et ne versionnez jamais le jeton.",{"type":36,"title":137,"body":138},"Dépannage : les erreurs qui reviennent","Les alertes elles-mêmes tombent en panne de façon prévisible. Chaque cas se vérifie à la main avant de chercher plus loin.",{"type":40,"title":140,"items":141},"Messages et symptômes avec leur remède",[142,143,144,145,146,147,148],"**`PANIC: could not write to file \"pg_wal\u002F...\": No space left on device`** — le volume qui porte les journaux de PostgreSQL est plein. Libérez d'abord de la place hors de PostgreSQL (journaux tournants, anciennes sauvegardes), ne supprimez jamais les fichiers de `pg_wal` à la main, puis redémarrez le service.","**`No space left on device` alors que `df -h` annonce de la place** — les inodes sont épuisés. Lancez `df --output=ipcent,target`, repérez le dossier qui contient des millions de petits fichiers (sessions, cache) et purgez-le.","**Disque plein mais `du` ne retrouve pas l'espace** — des fichiers supprimés restent ouverts par un processus. `sudo lsof +L1` les liste ; redémarrer le processus concerné libère l'espace.","**`oom_kill` augmente, rien dans `journalctl -k`** — le noyau a roulé ses journaux ou la mort vient d'une limite `MemoryMax=`. Lisez `memory.events` dans le répertoire du cgroup de l'unité et `journalctl -u` pour l'unité.","**Une unité tourne mais ne répond plus, aucune alerte** — c'est la limite de `OnFailure=`. Ajoutez une sonde `curl` sur l'adresse de santé et alertez sur le code de retour.","**Aucun message Telegram, aucune erreur visible** — cron envoie la sortie du script par courrier local, que personne ne lit. Lancez `alerte-envoi test` à la main avec `sudo` et lisez la réponse de `curl`.","**Le certificat approche de l'échéance alors que Certbot est installé** — lancez `certbot renew --dry-run` et lisez l'erreur de validation, puis corrigez le DNS ou le port concerné.",{"type":36,"title":150,"body":151},"La documentation officielle","Chaque comportement décrit ici vient d'une source primaire. Pour `OnFailure=`, \u003Ca href=\"https:\u002F\u002Fwww.freedesktop.org\u002Fsoftware\u002Fsystemd\u002Fman\u002Flatest\u002Fsystemd.unit.html\">la page de manuel de systemd.unit\u003C\u002Fa> ; pour `MemoryMax=`, \u003Ca href=\"https:\u002F\u002Fwww.freedesktop.org\u002Fsoftware\u002Fsystemd\u002Fman\u002Flatest\u002Fsystemd.resource-control.html\">systemd.resource-control\u003C\u002Fa> ; pour les compteurs `oom` et `oom_kill`, \u003Ca href=\"https:\u002F\u002Fdocs.kernel.org\u002Fadmin-guide\u002Fcgroup-v2.html\">la documentation des cgroups v2 du noyau\u003C\u002Fa> ; pour les 5 % réservés, \u003Ca href=\"https:\u002F\u002Fman7.org\u002Flinux\u002Fman-pages\u002Fman8\u002Ftune2fs.8.html\">la page de manuel de tune2fs\u003C\u002Fa>. Côté envoi, \u003Ca href=\"https:\u002F\u002Fcore.telegram.org\u002Fbots\u002Fapi#making-requests\">l'API Bot de Telegram\u003C\u002Fa> décrit la forme des requêtes, et \u003Ca href=\"https:\u002F\u002Fhealthchecks.io\u002Fdocs\u002Fhttp_api\u002F\">la documentation de l'API Healthchecks\u003C\u002Fa> les adresses de ping, avec \u003Ca href=\"https:\u002F\u002Fhealthchecks.io\u002Fpricing\u002F\">la page des tarifs\u003C\u002Fa> pour les limites du plan gratuit. Pour le renouvellement, \u003Ca href=\"https:\u002F\u002Feff-certbot.readthedocs.io\u002Fen\u002Fstable\u002Fusing.html\">la documentation de Certbot\u003C\u002Fa>. Le message PostgreSQL cité vient d'\u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002Fmessage-id\u002FBL0PR04MB6499BC32502F223A7BDF9BF2D0B30%40BL0PR04MB6499.namprd04.prod.outlook.com\">un fil de la liste officielle du projet\u003C\u002Fa>.",{"type":36,"title":153,"body":154},"Des alertes simples, la même sur chaque VPS","Six alertes et un battement de cœur ne remplacent pas une stack de supervision, ils couvrent ce qui fait réellement tomber un serveur : disque, inodes, mémoire, services, certificats, sauvegardes. Le gain principal est l'homogénéité : mêmes seuils et mêmes messages sur chaque machine. Quand le parc grandit ou que l'historique devient nécessaire, la bascule vers une stack se prépare dans \u003Ca href=\"\u002Fblog\u002Fself-host-beszel-vps\">le guide Beszel\u003C\u002Fa> et dans \u003Ca href=\"\u002Fblog\u002Fmonitoring-alerte-proactif-self-hosted-vps\">le guide des alertes proactives Beszel et Uptime Kuma\u003C\u002Fa>, qui traitent l'installation de bout en bout.","Un parc de VPS clients, des seuils homogènes","Sur ServOrbit.com, domaines, hébergements et serveurs d'un parc client se regroupent au même endroit, avec le même espace de gestion. L'option administration VPS existe pour les clients qui ne veulent pas administrer leur serveur.","Voir les solutions agences","\u002Fsolutions\u002Fagences",[160,176,197],{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":18,"isPinned":19,"publishedAt":170,"updatedAt":171,"category":172,"categories":173,"featuredImage":30,"bgImage":31,"posterImage":175,"relatedSolution":30},440,"monitoring-alerte-proactif-self-hosted-vps",{"fr":162,"en":164,"ar":165,"es":166},"proactive-vps-monitoring-beszel-uptime-kuma-v2","مراقبة-استباقية-vps-beszel-uptime-kuma","monitorizacion-proactiva-vps-beszel-uptime-kuma-v2","Stack monitoring proactif VPS : Beszel + Uptime Kuma v2","Déployez Beszel et Uptime Kuma v2 sur un VPS pour surveiller tout votre parc et recevoir des alertes Telegram ou SMTP avant que vos clients ne constatent la panne.",11,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[174],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg",{"id":177,"slug":178,"slugs":179,"title":183,"excerpt":184,"readTime":185,"views":186,"isPinned":19,"publishedAt":187,"updatedAt":188,"category":189,"categories":194,"featuredImage":30,"bgImage":31,"posterImage":196,"relatedSolution":30},230,"cron-systemd-timers-automatisation-vps",{"fr":178,"en":180,"ar":181,"es":182},"cron-vs-systemd-timers-automate-your-linux-vps","cron-مقابل-systemd-timers-أتمتة-vps-linux","cron-vs-systemd-timers-automatizar-vps-linux","cron vs systemd timers : automatiser son VPS Linux","Comparatif pratique cron et systemd timers : syntaxe, logs, migration et dépannage pour vos tâches récurrentes sur VPS Linux.",12,1,"2026-08-06T00:00:00+00:00","2026-09-20T21:13:53+00:00",{"id":190,"name":191,"slug":192,"color":193,"icon":192},2,"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[195],{"id":190,"name":191,"slug":192,"color":193,"icon":192},"\u002Fblog\u002Fcovers\u002Fcron-systemd-timers-automatisation-vps-poster.svg",{"id":198,"slug":199,"slugs":200,"title":204,"excerpt":205,"readTime":23,"views":186,"isPinned":19,"publishedAt":206,"updatedAt":207,"category":208,"categories":209,"featuredImage":30,"bgImage":31,"posterImage":211,"relatedSolution":212},133,"self-host-beszel-vps",{"fr":199,"en":201,"ar":202,"es":203},"self-host-beszel-multi-server-monitoring-hub-on-your-vps","استضف-beszel-على-vps-مركز-مراقبة-متعدد-الخوادم","alojar-beszel-hub-monitorizacion-vps","Beszel sur VPS : supervision multi-serveurs, alertes et sécurité","Supervisez un parc de VPS depuis un hub Beszel unique : alertes Telegram\u002Fe-mail, 2FA, agents déclarés automatiquement et dépannage des connexions silencieuses.","2026-02-14T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[210],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-beszel-vps-poster.svg",{"categorySlug":213,"appSlug":214},"monitoring","beszel",1793145872565]