Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

KULA - Le monitoring serveur Linux qui tient dans un seul binaire

Par : Korben ✨
1 mai 2026 à 06:53

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):

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 !

Source

Snitch - Le netstat qui ne pique plus les yeux

Par : Korben
27 février 2026 à 07:56

Si vous avez déjà tapé [ss -tulnp](https://www.it-connect.fr/lister-les-ports-en-ecoute-sous-linux-avec-lsof-netstat-et-ss/) dans un terminal, vous savez que c'est moche. Genre, VRAIMENT moche. Les colonnes qui se chevauchent, les adresses tronquées, bref c'est un festival du bordel. Mais c'était sans compter sur ce dev qui a pondu Snitch , un outil en Go sous licence MIT qui vient concurrencer ss et netstat... sauf que pour une fois, c'est lisible, regardez :

L'interface de Snitch en action, sobre et lisible

En gros, c'est un ss moderne avec une interface TUI interactive. Vous lancez la commande dans votre terminal et tadaaa, vous avez un tableau propre avec toutes vos connexions réseau, les processus associés, les ports, les protocoles... le tout avec des couleurs et une navigation au clavier. Rien à voir donc avec le pavé monochrome habituel !

Le truc cool aussi ce sont les filtres. Vous pouvez taper snitch ls proto=tcp state=listen pour ne voir que les sockets TCP en écoute, ou snitch ls proc=nginx pour traquer votre serveur web. Y'a même un filtre contains= pour chercher dans les adresses... genre contains=google pour voir tout ce qui cause avec Mountain View.

D'ailleurs, côté commandes c'est en fait bien fichu. snitch ls pour un tableau statique, snitch json pour du JSON brut si vous voulez scripter, et snitch watch -i 1s pour streamer les connexions en temps réel. Du coup ça s'intègre nickel dans vos pipelines.

La TUI elle-même vaut le détour. Vous naviguez avec j/k (comme dans Vim, forcément), vous basculez TCP/UDP avec t/u, et le plus jouissif... vous pouvez killer un processus directement avec la touche K. Plus besoin de noter le PID et d'ouvrir un autre terminal ! Sauf que attention, sur Linux faut quand même lancer en root pour avoir les infos complètes sur les processus, parce que l'outil va lire dans /proc/net/*. Ça ne marche pas non plus sur Windows, c'est Linux et macOS uniquement.

Pour ceux qui aiment personnaliser leur terminal (oui, je vous connaîs...), y'a une quinzaine de thèmes, Catppuccin, Dracula, Nord, Tokyo Night, Gruvbox... la config se fait dans ~/.config/snitch/snitch.toml et l'outil peut aussi conserver vos préférences de filtres entre les sessions (faut activer remember_state dans la config).

Côté installation, c'est pas la mer à boire. brew install snitch sur macOS, go install github.com/karol-broda/snitch@latest si vous avez Go, yay -S snitch-bin sur Arch, et y'a même des images Docker pour les plus prudents !

Donc si vous êtes du genre à surveiller votre trafic réseau ou à garder un oeil sur vos outils de diagnostic Linux , c'est clairement à tester.

Perso, pour du debug réseau rapide, je trouve que c'est carrément plus agréable que de se taper un ss -tulnp.

MonitorBox - Le monitoring qui réveille votre vieux pager

Par : Korben
1 février 2026 à 11:48

Brice, un lecteur de Korben, m'a bel et bien scotché. Il y a quelques semaines, je vous parlais du Pineapple Pager et ça a visiblement réveillé une fibre nostalgique chez certains d'entre vous. Donc merci à Brice pour l'info, car il a carrément passé sa soirée à coder un truc énoooOOOooorme (et super utile) qui s'appelle MonitorBox .

Parce qu'on va pas se mentir, on croule tous sous les notifications. Entre Slack, les emails, et les alertes de sécurité, notre cerveau a fini par développer un mécanisme de défense radical : il ignore TOUT !!! C'est ce qu'on appelle la "fatigue de l'alerte". J'avoue que pour un admin sys en astreinte, c'est le début de la fin. Le jour où le serveur de prod tombe vraiment, on swipe la notif comme si c'était une pub pour des croquettes bio... Pas terrible donc pour la continuité de service.

L'interface de MonitorBox - sobre mais efficace ( Source )

Et c'est là que Brice intervient justement avec son idée de génie : Ressusciter le bon vieux pager des années 90. Au début je pensais que c'était juste pour le fun (un délire de vieux geek quoi), mais en réalité c'est un vrai outil de surveillance pro.

MonitorBox est conçu pour tourner sur un vieux PC recyclé (genre un vieux Dell Optiplex GX270 ou un ThinkPad T60) sous Debian 12 Bookworm et l'idée, c'est de sortir l'alerte critique du flux continu de votre smartphone pour l'envoyer sur un appareil qui ne sert qu'à ça. Ainsi, quand le beeper à votre ceinture se met à gueuler sur la fréquence 466.975 MHz, vous savez que la maison brûle, sans même regarder l'écran.

Et techniquement, c'est hyper propre !!! Le système utilise une vue Terminal (parfaite pour un vieil écran CRT qui traîne) et un dashboard web moderne sous JavaScript pour le suivi. L'arme secrète reste ensuite le support du protocole POCSAG.

Via le port série (type /dev/ttyS0 ou un adaptateur FTDI), MonitorBox pilote un émetteur radio qui se charge de balancer les infos sur les ondes. Et toudoum, voilà comment votre vieux Tatoo ou Tam-Tam reprend du service !

⚠️ Attention quand même, émettre sur des fréquences radio est ultra-réglementé. Vérifiez donc bien la législation avant de jouer les apprentis sorciers, car pas moyen de plaider l'ignorance si les mecs de l'ANFR débarquent chez vous avec leur camionnette de détection Agence Tous Risques...

J'adore perso son approche qui vise le "Zéro faux positif". En effet, le script s'appuie sur Shell, curl et espeak pour la synthèse vocale locale, et intègre une logique de "Retry" comme ça si un service ne répond pas, l'outil vérifie à nouveau avant de vous réveiller en pleine nuit. Ça réduit drastiquement les fausses alertes, contrairement aux outils de monitoring habituels qui hurlent parfois au loup pour une micro-latence passagère de rien du tout.

MonitorBox est léger (pas besoin de base de données SQL compliquée, juste un fichier servers.conf), souverain, et permet de redonner vie à du matos qu'on croyait bon pour la déchetterie.

Brice nous propose en gros un mix parfait entre low-tech et haute performance. Et si vous voulez tester le bousin, tout le code est open source (licence MIT) et disponible sur GitHub . Seul petit bémol, il vous faudra bel et bien un vrai câble DB9 ou DB25 et un adaptateur qui tient la route, sinon votre VM va juste vous envoyer bouler violemment. Aaaah ces drivers USB chinois, je vous jure...

Bref, merci Brice pour l'inspiration et pour ce beau projet à la fois rétro et moderne !

SHADE-Arena - Quand les IA apprennent à nous saborder en douce

Par : Korben
18 juin 2025 à 07:02

J’étais tranquillement en train de lire le dernier papier d’Anthropic avec mon café quand mon chat (Percy) m’a regardé avec son regard de psychopathe, semblant me demander pourquoi j’avais l’air de quelqu’un qui venait de voir un fantôme. La vraie raison, c’est que je viens de découvrir qu’Anthropic testait maintenant comment les IA pouvaient nous mentir en pleine face au travers de leur projet SHADE-Arena. Derrière ce nom un peu barbare se cache en réalité un laboratoire secret pour mesurer les capacités de sabotage de nos assistants virtuels préférés.

❌
❌