Connexion
"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !
Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.
Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.
Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.
Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.
Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.
Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.
Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...
Vous connaissez le duo Prometheus et Grafana ? C'est le grand classique pour surveiller ses serveurs, mais configurer tout ce bazar et le garder propre, c'est vite l'enfer. Alors pour ceux qui veulent juste garder un oeil sur leur homelab plutôt que de perdre le peu de cheveux qu'il leur reste à configurer Grafana durant des heures, j'ai trouvé pour vous Beszel .
Beszel est un outil de monitoring de serveurs ultra-léger et surtout super simple à mettre en place. Le projet est tout récent et développé en Go, ce qui permet d'avoir des binaires minuscules et une consommation de ressources ridicule
Donc si vous cherchez un outil de monitoring Linux self-hosted aussi simple à prendre en main que Kula dont je vous ai déjà parlé, ça vaut le coup d'aller jeter un oeil.
La mécanique de Beszel repose sur deux morceaux, à savoir le hub et l'agent. Le hub, c'est l'interface web construite au-dessus de PocketBase, qui sert de tableau de bord centralisé quant à l'agent, lui, il tourne discrètement sur chaque machine à surveiller et remonte les métriques au hub. "Discrètement", ça veut dire qu'il consomme à peine 10 à 15 Mo de RAM donc c'est parfait pour le faire tourner sur une vieille machine ou un tout petit Raspberry Pi sans que ça tousse-tousse !
Le truc vraiment cool aussi, c'est la gestion native des conteneurs Docker. Au lieu de simplement suivre l'état général comme avec un outil de suivi des processus classique (je pense à pstop par exemple), il liste chaque conteneur et affiche sa consommation individuelle en CPU, mémoire et réseau. Donc pour tous ceux qui auto-hébergent des dizaines de services, c'est un pur bonheur.
Côté métriques, y'a aussi tout ce qu'il faut pour ne rien louper. L'outil permet de suivre la consommation CPU, la mémoire (incluant le swap et le ZFS ARC), l'espace disque, les entrées/sorties réseau, la moyenne de charge et même la température des composants. En 15 secondes, tout s'affiche proprement.
Il gère aussi des trucs plus poussés comme la santé des disques via les données S.M.A.R.T., l'état de la batterie et même la consommation de vos cartes graphiques Nvidia, AMD ou Intel. Attention, pour le S.M.A.R.T. et le GPU par contre, il faudra que vous installiez les utilitaires système correspondants sur la machine hôte (smartmontools, nvidia-smi...) pour que l'agent puisse remonter les infos.
Et la configuration ? Hé bien c'est un simple fichier docker-compose.yml et voilà c'est plié !
Lors du premier lancement du hub, vous devrez vous créer un compte administrateur, puis cliquer sur "Ajouter un système", et l'interface vous génèrera une clé publique. Il suffira ensuite de filer cette clé à votre agent via sa variable d'environnement (dans son docker-compose.yml, par exemple) et les deux copains commenceront à causer. C'est pas plus compliqué que ça ! Même un notaire pourrait le faire ^^.
Le hub intègre également une gestion multi-utilisateur bien foutue puisque chaque utilisateur peut avoir accès à ses propres machines, tandis que l'administrateur peut décider de partager certains systèmes. Si vous voulez sécuriser le tout, l'outil supporte aussi de nombreux fournisseurs OAuth2 et OIDC comme Google, GitHub ou Keycloak, et vous pouvez même couper complètement la connexion par mot de passe.
Beszel s'occupe aussi des sauvegardes automatiques de vos données de surveillance, en local ou directement sur un stockage compatible S3. Et pour les alertes, pas de panique, car l'outil est compatible avec Shoutrrr . Cela vous permettra de configurer des notifications par Discord, Telegram, Teams ou mail si le CPU s'affole ou si un disque commence à saturer.
Par contre, si vous cherchez un outil d'analyse de logs complet ou de détection de bug réseau ultra-précis, laissez tomber car c'est pas la "mission de vie" de Beszel. Sauf si bien sûr, vous le couplez avec un autre outil. Après pour le reste, c'est parfait.
Vous pouvez tester la version v0.18.7 en vous rendant sur le site officiel .
HydroTracker, c'est une app Android open source pour suivre votre consommation d'eau au quotidien. C'est sans pub, ça fonctionne hors-ligne et ça a été mis au point par Ali Cem Çakmak, physicien et développeur passionné !
L'écran d'accueil d'HydroTracker, sobre et lisible
Côté fonctionnalités, vous avez donc le suivi quotidien classique avec objectif personnalisé, des graphiques hebdo, des cartes thermiques mensuelles, le suivi des séries de jours réussis et 3 widgets à mettre sur écran d'accueil.
Par contre, ça marche pas pour suivre votre conso de bière, désolé mes amis Chouffinistes ^^
Et puis surtout, y'a l'intégration Health Connect ce qui permet à HydroTracker de lire et écrire dans la base santé Android partagée par Samsung Health, Google Fit, Fitbit, Garmin ou Strava. Comme ça, toutes vos données sont centralisées !
Alors j'sais pas si vous avez déjà tracké votre consommation d'eau mais la plupart des apps d'hydratation se contentent de compter les verres d'eau. Cem, lui, s'appuie sur le Beverage Hydration Index (y'a une étude à ce sujet publiée dans l'American Journal of Clinical Nutrition ) et applique des coefficients différents selon les boissons, avec les seuils EFSA pour l'Europe et IOM pour les US. Un verre de lait équivaut par exemple à 1,5 fois sa quantité d'eau, et un soluté de réhydratation orale aussi. C'est logique vu la composition réelle, et pourtant aucune app grand public ne pousse le bouchon aussi loin niveau finesse !
Les analytics d'HydroTracker, façon dashboard scientifique
Et le gros morceau, vous l'aviez deviné, c'est surtout la confidentialité. Prenez par exemple Water Reminder, une app concurrente bien installée sur Android. Hé bien avec elle, vos heures de prise d'eau, votre régularité, votre comportement, tout part chez Google.
Alors que HydroTracker, lui, garde tout en local et la synchro Health Connect reste bien sûr à 100% optionnelle. Bref, si vous tenez à votre indépendance numérique vis-à-vis des géants américains , et que vous aimez rester hydraté, c'est l'app idéale !
L'app est sous licence GPL v3, dispo sur le Play Store (et bientôt sur F-Droid), ou en APK direct depuis les releases GitHub . Par contre, pas de version iOS pour l'instant. Ah et j'oubliais, les notifications de l'app s'adaptent à votre cycle de sommeil, donc elle ne vous harcelera pas la nuit. C'est con dit comme ça, mais peu d'apps le font.
Voilà, si vous voulez creuser le code, c'est sur GitHub et Cem a même sa page perso sur cmckmk.com .
Merci à Alex pour le tip !
Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !
KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !
C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.
KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.
Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"
Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.
Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.
Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.
Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.
Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.
Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !
Le déploiement Docker c'est comme ça :
docker run -d --name kula --pid host --network host
-v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest
Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.
Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...
Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.
Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !
Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.
Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.
Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.
C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.
Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !
Datadog Labs vient de sortir pup , un outil CLI codé en Rust qui donne à vos agents IA un accès complet à leur plateforme. L'idée c'est que pendant que Vercel et AWS galèrent de ouf à rendre leurs trucs « agent-friendly », Datadog, lui, dégaine un outil dédié qui expose +200 commandes sur plus de 33 de leurs produits, du monitoring aux SLOs en passant par la sécurité et les incidents.
Côté install c'est du classique, brew tap datadog-labs/pack && brew install pup, puis pup auth login pour le flow OAuth2 avec PKCE.
Plus besoin comme ça de balader vos clés API à vie dans des variables d'env, même si le fallback DD_API_KEY reste là quand même pour d'éventuels cas "headless". Une fois loggué, vous tapez alors par exemple :
pup monitors list
ou
pup metrics query --query="avg:system.cpu.user{*}" --from="1h"
et l'agent récupère du JSON 100% clean, prêt à être bouffé et digéré par Claude Code, Cursor ou peu importe ce que vous utilisez.
Pour détecter le mode agent, Pup regarde les variables d'environnement type CLAUDE_CODE ou CURSOR_AGENT, et bascule tout seul en sortie machine, avec tout ce qui va bien, genre les metadonnées, les hints et autres auto-approbation des prompts destructifs (oui, c'est à utiliser avec prudence, mais je vous fais confiance, vous êtes des pro).
Les commandes sont aussi auto-découvrables via pup --help ou pup agent schema, donc l'agent peut introspecter ce qu'il a à disposition sans que vous lui mâchiez le travail.
Y'a même un moteur de runbooks en YAML pour chaîner des étapes (commandes pup, shell, HTTP, workflows Datadog) avec interpolation de variables, conditions et polling. Pratique donc pour scripter un triage d'incident ou un déploiement, sans sortir un Argo ou un Temporal pour ça. Et pour les setups un peu plus velus, pup se compile aussi en WASM, donc vous pouvez le faire tourner dans Wasmtime ou un Cloudflare Worker.
À noter, le projet est encore en Preview, et que certaines API ne sont pas implémentées (Session Replay, Powerpacks, IP Allowlist).
