Ouais, je sais, on est le 1er mai, et je suis pas cens\u00e9 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 !<\/p>\n

\nbash -c \"$(curl -fsSL https:\/\/raw.githubusercontent.com\/c0m4r\/kula\/refs\/heads\/main\/addons\/install.sh)\"\n<\/span><\/span><\/code><\/pre>\nC\u00f4t\u00e9 technique, le projet va chercher ses infos directement dans \/proc<\/code> et \/sys<\/code> toutes les secondes. Comme \u00e7a y’a pas besoin d’un programme “agent” s\u00e9par\u00e9 \u00e0 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.<\/p>\n Les donn\u00e9es passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agr\u00e9g\u00e9, 5 minutes agr\u00e9g\u00e9), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par d\u00e9faut). Et quand la limite est atteinte, les nouvelles donn\u00e9es \u00e9crasent les vieilles. Comme \u00e7a l’usage disque est ma\u00eetris\u00e9, et y’a pas besoin de faire de m\u00e9nage.<\/p>\n Niveau m\u00e9triques, c’est plut\u00f4t complet je trouve… CPU, GPU (VRAM, charge, conso), m\u00e9moire, swap, load average, processus par \u00e9tat, temp\u00e9ratures CPU\/GPU\/disque, batteries, entropie syst\u00e8me, sync horloge. Le r\u00e9seau remonte les d\u00e9bits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions \u00e9tablies…etc.<\/p>\n Et c\u00f4t\u00e9 disque c’est par composant : IOPS, lectures\/\u00e9critures par seconde, octets\/s, plus l’usage des syst\u00e8mes de fichiers. Et bien s\u00fbr tout ce qui est containers Docker, podman, et m\u00eame ces cgroups bruts dont vous \u00eates si fiers ^^, pour ceux qui font tourner des trucs sans Docker.<\/p>\n <\/p>\n Et le truc auquel je ne m’attendais pas mais que j’aurais pu anticiper parce que c’est \u00e0 la modeuuuuh, c’est l’assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer \u00e0 un mod\u00e8le de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et m\u00eame faire appel \u00e0 une fonction get_metrics<\/code> pour interroger les donn\u00e9es en mode agent.<\/p>\n Tout \u00e7a en local bien s\u00fbr. C’est plut\u00f4t sympa pour debugger par exemple un pic de CPU r\u00e9current \u00e0 3h du matin sans devoir vous taper des heures de graphes !<\/p>\n Le d\u00e9ploiement Docker c’est comme \u00e7a :<\/p>\n\ndocker run -d --name kula --pid host --network host\n<\/span><\/span> -v \/proc:\/proc:ro -v kula_data:\/app\/data c0m4r\/kula:latest\n<\/span><\/span><\/code><\/pre>\nNotez le param\u00e8tre --pid host<\/code> et \/proc:\/proc:ro<\/code> : car KULA a besoin de voir l’h\u00f4te et pas le container.<\/p>\n Bah ouais, c’est logique, sinon il va monitorer juste son propre container, ce qui n’a aucun int\u00e9r\u00eat, hein…<\/p>\n Notez que si vous \u00eates sur un VPS LXC mutualis\u00e9 bas de gamme, certains h\u00e9bergeurs restreignent l’acc\u00e8s \u00e0 \/proc<\/code> du host… et l\u00e0, malheureusement, KULA ne pourra remonter que ce qu’il voit ce qui est souvent pas grand-chose… sniiif.<\/p>\n Pour les puristes, y’a aussi des paquets .deb<\/code>, .rpm<\/code>, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). \u00c7a couvre \u00e0 peu pr\u00e8s tout ce qui se croise sur un homelab !<\/p>\n Et c\u00f4t\u00e9 auth, c’est d\u00e9sactiv\u00e9 par d\u00e9faut (le port par d\u00e9faut est le 27960, pas le 80), mais quand vous l’activerez vous tomberez sur de l’Argon2id avec des jetons de session hash\u00e9s en base.<\/p>\n Par contre, m\u00eame 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 \u00e0 la fois.<\/p>\n Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards s\u00e9par\u00e9s. Pas glop ! Et bien s\u00fbr, c’est Linux only parce que tout repose sur \/proc<\/code> et \/sys<\/code>.<\/p>\nC’est encore un projet un peu jeune, donc \u00e0 voir comment \u00e7a vieillit mais pour votre petit VPS perso d’amour ou une machine dans un \nsetup d’auto-h\u00e9bergement<\/a> \n, c’est top pour esquiver \u00e0 la fois htop qui est trop minimaliste et Grafana qui est trop usine \u00e0 gaz.<\/p>\n Si vous voulez voir la d\u00e9mo, y’en a une ici : \ndemo.kula.ovh<\/a> \n!<\/p>\n \nSource<\/a>\n<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Ouais, je sais, on est le 1er mai, et je suis pas cens\u00e9 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\u00e8s facilement votre serveur Linux en temps r\u00e9el, sans aucune d\u00e9pendance. c0m4r , le dev derri\u00e8re le projet, l’a cod\u00e9 en Go avec une obsession claire : Que \u00e7a marche partout sans rien installer \u00e0 c\u00f4t\u00e9 ! C’est vrai que les outils de monitoring temps r\u00e9el sur Linux ont tendance \u00e0 grossir avec le temps. Netdata est pass\u00e9 par exemple d’un script l\u00e9ger \u00e0 une plateforme SaaS. KULA veut faire exactement l’inverse ! Parce que si vous avez un VPS \u00e0 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\u00e9 ! Il y a m\u00eame un installeur guid\u00e9 en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me r\u00e9p\u00e8te, je sais): bash -c “$(curl -fsSL https:\/\/raw.githubusercontent.com\/c0m4r\/kula\/refs\/heads\/main\/addons\/install.sh)” C\u00f4t\u00e9 technique, le projet va chercher ses infos directement dans \/proc et \/sys toutes les secondes. Comme \u00e7a y’a pas besoin d’un programme “agent” s\u00e9par\u00e9 \u00e0 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\u00e9es passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agr\u00e9g\u00e9, 5 minutes agr\u00e9g\u00e9), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par d\u00e9faut). Et quand la limite est atteinte, les nouvelles donn\u00e9es \u00e9crasent les vieilles. Comme \u00e7a l’usage disque est ma\u00eetris\u00e9, et y’a pas besoin de faire de m\u00e9nage. Niveau m\u00e9triques, c’est plut\u00f4t complet je trouve… CPU, GPU (VRAM, charge, conso), m\u00e9moire, swap, load average, processus par \u00e9tat, temp\u00e9ratures CPU\/GPU\/disque, batteries, entropie syst\u00e8me, sync horloge. Le r\u00e9seau remonte les d\u00e9bits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions \u00e9tablies…etc. Et c\u00f4t\u00e9 disque c’est par composant : IOPS, lectures\/\u00e9critures par seconde, octets\/s, plus l’usage des syst\u00e8mes de fichiers. Et bien s\u00fbr tout ce qui est containers Docker, podman, et m\u00eame ces cgroups bruts dont vous \u00eates 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 \u00e0 la modeuuuuh, c’est l’assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer \u00e0 un mod\u00e8le de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et m\u00eame faire appel \u00e0 une fonction get_metrics pour interroger les donn\u00e9es en mode agent. Tout \u00e7a en local bien s\u00fbr. C’est plut\u00f4t sympa pour debugger par exemple un pic de CPU r\u00e9current \u00e0 3h du matin sans devoir vous taper des heures de graphes ! Le d\u00e9ploiement Docker c’est comme \u00e7a : docker run -d –name kula –pid host –network host -v \/proc:\/proc:ro -v kula_data:\/app\/data c0m4r\/kula:latest Notez le param\u00e8tre –pid host et \/proc:\/proc:ro : car KULA a besoin de voir l’h\u00f4te et pas le container. Bah ouais, c’est logique, sinon il va monitorer juste son propre container, ce qui n’a aucun int\u00e9r\u00eat, hein… Notez que si vous \u00eates sur un VPS LXC mutualis\u00e9 bas de gamme, certains h\u00e9bergeurs restreignent l’acc\u00e8s \u00e0 \/proc du host… et l\u00e0, 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). \u00c7a couvre \u00e0 peu pr\u00e8s tout ce qui se croise sur un homelab ! Et c\u00f4t\u00e9 auth, c’est d\u00e9sactiv\u00e9 par d\u00e9faut (le port par d\u00e9faut est le 27960, pas le 80), mais quand vous l’activerez vous tomberez sur de l’Argon2id avec des jetons de session hash\u00e9s en base. Par contre, m\u00eame 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 \u00e0 la fois. Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards s\u00e9par\u00e9s. Pas glop ! Et bien s\u00fbr, c’est Linux only parce que tout repose sur \/proc et \/sys. C’est encore un projet un peu jeune, donc \u00e0 voir comment \u00e7a vieillit mais pour votre petit VPS perso d’amour ou une machine dans un setup d’auto-h\u00e9bergement , c’est top pour esquiver \u00e0 la fois htop qui est trop minimaliste et Grafana qui est trop usine \u00e0 gaz. Si vous voulez voir la d\u00e9mo, y’en a une ici : demo.kula.ovh ! Source<\/p>\n","protected":false},"author":1,"featured_media":2896,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"give_campaign_id":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_kadence_starter_templates_imported_post":false,"footnotes":""},"class_list":["post-2895","page","type-page","status-publish","has-post-thumbnail","hentry"],"campaignId":"","_links":{"self":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages\/2895","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/comments?post=2895"}],"version-history":[{"count":0,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/pages\/2895\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/media\/2896"}],"wp:attachment":[{"href":"https:\/\/elearningsamba.com\/index.php\/wp-json\/wp\/v2\/media?parent=2895"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}