Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

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

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

Pup branche votre agent IA sur Datadog

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

Source

Microsoft Sentinel Logstash output plugin: DCR-based log ingestion

End to end architecture logstash > dce > dcr > log analytics workspace, authenticated with entra id (image microsoft)
Microsoft has released a new version of the Logstash output plugin for Microsoft Sentinel in public preview. The plugin replaces the older authentication method—a shared workspace key—with Microsoft Entra ID app-based authentication and routes data through Azure Monitor's Data Collection Rules. This article explains how the plugin works, what you need to set it up, and its current limitations.

Source

Enable Windows Group Policy Preferences (GPP) debug logging

Enable Preference Logging (image Microsoft)
Starting with the February 2026 preview updates for Windows 11 24H2 and 25H2, Microsoft has made Group Policy Preferences (GPP) debug logging configurable directly in Local Group Policy via gpedit.msc. Previously, these settings were primarily managed through domain-based Group Policy Objects (GPOs); enabling them via Local Group Policy typically required manually copying the GroupPolicyPreferences .admx/.adml templates into the local PolicyDefinitions store. You can now enable per-CSE (client-side extension) event logging and file-based tracing on individual client devices without a domain controller.

Source

Real-time data ingestion with Microsoft Sentinel’s Codeless Connector Framework (CCF) Push

Codeless Connector Framework (CCF) Push workflow (image Microsoft)
Microsoft Sentinel is Azure's cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automated Response) platform. The Codeless Connector Framework (CCF) — formerly known as the Codeless Connector Platform — is the mechanism that enables partners, customers, and developers to build data connectors without writing infrastructure code. The newly public-preview CCF Push feature extends this framework with an event-driven ingestion pattern that sends security data directly to Sentinel as events occur, bypassing the latency inherent in traditional polling. This article explains what CCF Push is, how it differs from pull connectors, which Azure resources it automatically provisions, and how you configure an application to push data using the Log Ingestion API and OAuth 2.0.

Source

Sysmon in Windows 11 Insider Preview builds 26300.7733 (KB5074178) and 26220.7752 (KB5074177)

Running system monitor (sysmon)
Microsoft released Windows 11 Insider Preview Build 26300.7733 (KB5074178) and Build 26220.7752 (KB5074177), to the Dev and Beta Channels, respectively. These updates introduce native System Monitor (Sysmon) functionality, expand Voice Access support, and include several fixes for File Explorer and cloud storage integration. The releases represent cumulative quality updates for Windows 11 version 25H2 through enablement packages.

Source

❌