Superviser son homelab en 2026 : Uptime Kuma + Grafana + alertes (guide complet)

Un homelab qui tourne, c’est bien. Un homelab dont on sait, à la seconde près, qu’un service est tombé, que le disque arrive à saturation ou que la RAM grimpe, c’est un homelab qu’on maîtrise. Trop d’auto-hébergeurs découvrent qu’un service est mort… quand ils essaient de l’utiliser. La supervision n’est pas un luxe réservé aux entreprises : avec deux ou trois conteneurs, vous obtenez une visibilité complète et des alertes qui vous préviennent avant les utilisateurs.

Dans ce guide, on monte une stack de monitoring complète et 100 % self-hosted via Docker : Uptime Kuma pour la supervision de disponibilité (les services répondent-ils ?), Prometheus + node_exporter pour les métriques système (CPU, RAM, disque, réseau), et Grafana pour de beaux tableaux de bord. On termine par les alertes Telegram pour être notifié instantanément. À la fin, vous saurez en un coup d’œil si tout va bien, et vous serez prévenu sinon.

Prérequis

• Un serveur ou homelab sous Linux avec Docker et Docker Compose installés. Voir l’installation de Docker dans notre guide reverse proxy Caddy + Docker.

• Idéalement un VPS ou une machine dédiée à la supervision (un petit nœud suffit : la stack consomme peu). Pour le choix du matériel/VPS, voir meilleur VPS pour le self-hosting.

• Un reverse proxy (Caddy) si vous voulez exposer les interfaces en HTTPS, ce qui est recommandé.

• Un compte Telegram et l’application, pour recevoir les alertes.

• 30 à 45 minutes.

Si vous hésitez sur les outils, notre comparatif Uptime Kuma vs Grafana vs Netdata explique pourquoi ces briques sont complémentaires plutôt que concurrentes.

Architecture de la stack

Avant de plonger, comprenons qui fait quoi :

• Uptime Kuma : sondes de disponibilité (HTTP, TCP, ping, DNS…). Réponse à la question « est-ce que mon service répond ? ». Interface simple, alertes intégrées.

• node_exporter : agent léger qui expose les métriques système d’une machine (CPU, RAM, disque, réseau) au format Prometheus.

• Prometheus : base de données temporelle qui collecte (« scrape ») périodiquement les métriques de node_exporter.

• Grafana : visualisation. Se branche sur Prometheus pour afficher des tableaux de bord et déclencher des alertes sur seuils.

On déploie le tout dans un seul docker-compose.yml pour la simplicité.

Étape 1 : Préparer l’arborescence et le docker-compose

Créez un dossier de travail :

mkdir -p ~/monitoring && cd ~/monitoring

mkdir -p prometheus

Créez le fichier de composition :

nano docker-compose.yml

services:

  uptime-kuma:

    image: louislam/uptime-kuma:1

    container_name: uptime-kuma

    restart: unless-stopped

    volumes:

      - uptime-kuma-data:/app/data

    ports:

      - "3001:3001"



  node-exporter:

    image: prom/node-exporter:latest

    container_name: node-exporter

    restart: unless-stopped

    command:

      - '--path.rootfs=/host'

    pid: host

    volumes:

      - '/:/host:ro,rslave'

    ports:

      - "9100:9100"



  prometheus:

    image: prom/prometheus:latest

    container_name: prometheus

    restart: unless-stopped

    volumes:

      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro

      - prometheus-data:/prometheus

    command:

      - '--config.file=/etc/prometheus/prometheus.yml'

      - '--storage.tsdb.retention.time=30d'

    ports:

      - "9090:9090"



  grafana:

    image: grafana/grafana-oss:latest

    container_name: grafana

    restart: unless-stopped

    environment:

      - GF_SECURITY_ADMIN_PASSWORD=ChangezCeMotDePasse

    volumes:

      - grafana-data:/var/lib/grafana

    ports:

      - "3000:3000"

    depends_on:

      - prometheus



volumes:

  uptime-kuma-data:

  prometheus-data:

  grafana-data:

Sécurité : Changez GF_SECURITY_ADMIN_PASSWORD par un mot de passe fort. Les ports sont exposés ici en clair pour la mise en place ; en production, placez ces services derrière un reverse proxy HTTPS et ne publiez pas les ports directement sur Internet (retirez les sections ports: une fois passé par Caddy sur un réseau Docker partagé).

Étape 2 : Configurer Prometheus

Prometheus a besoin de savoir quoi collecter. Créez son fichier de config :

nano ~/monitoring/prometheus/prometheus.yml

global:

  scrape_interval: 15s

  evaluation_interval: 15s



scrape_configs:

  - job_name: 'prometheus'

    static_configs:

      - targets: ['localhost:9090']



  - job_name: 'node'

    static_configs:

      - targets: ['node-exporter:9100']

Comme tous les conteneurs sont sur le même réseau Docker (celui par défaut du projet compose), Prometheus joint node-exporter par son nom de service. Lancez la stack :

docker compose up -d

Vérifiez que tout démarre :

docker compose ps

Les quatre conteneurs doivent être running.

Étape 3 : Vérifier la collecte des métriques

Vérifiez que node_exporter expose bien ses métriques :

curl -s http://localhost:9100/metrics | head -5

Vous obtenez des lignes de métriques au format Prometheus. Ensuite, ouvrez Prometheus dans le navigateur sur http://IP_DU_SERVEUR:9090, allez dans Status > Targets : la cible node doit être à l’état UP. Si elle est DOWN, vérifiez le nom du service et le port dans prometheus.yml.

Étape 4 : Configurer Uptime Kuma

Ouvrez http://IP_DU_SERVEUR:3001. Au premier lancement, créez le compte administrateur (identifiant + mot de passe fort).

Ajoutez ensuite vos premières sondes (« monitors ») :

1. Cliquez sur Add New Monitor.

2. Type HTTP(s) pour un site ou service web : renseignez l’URL (ex. https://cloud.exemple.fr), un nom parlant, l’intervalle de vérification (60 s est un bon défaut).

3. Type TCP Port pour un service sans interface web (ex. une base de données) : indiquez l’hôte et le port.

4. Type Ping pour vérifier qu’une machine répond sur le réseau.

Uptime Kuma affiche immédiatement un historique de disponibilité, le pourcentage d’uptime, et le temps de réponse. Créez une page de statut publique via Status Pages si vous voulez partager l’état de vos services.

Astuce : Pour qu’une tâche planifiée (comme une sauvegarde restic) signale qu’elle s’est bien exécutée, créez un monitor de type Push dans Uptime Kuma. Votre script appelle l’URL fournie à la fin ; si l’appel n’arrive pas dans le délai imparti, Uptime Kuma vous alerte. Pratique pour détecter une sauvegarde silencieusement échouée.

Étape 5 : Configurer Grafana

Ouvrez http://IP_DU_SERVEUR:3000 et connectez-vous avec admin et le mot de passe défini dans le compose.

Ajouter Prometheus comme source de données

1. Menu Connections > Data sources > Add data source.

2. Choisissez Prometheus.

3. Dans Prometheus server URL, saisissez http://prometheus:9090 (résolution par nom de conteneur sur le réseau Docker).

4. Cliquez Save & test : vous devez voir « Successfully queried the Prometheus API ».

Importer un tableau de bord prêt à l’emploi

Inutile de tout construire à la main : la communauté propose d’excellents tableaux de bord. Pour node_exporter, importez le célèbre dashboard Node Exporter Full (ID 1860) :

1. Menu Dashboards > New > Import.

2. Saisissez l’ID 1860 dans le champ, cliquez Load.

3. Sélectionnez votre source de données Prometheus, puis Import.

Vous obtenez instantanément un tableau de bord complet : usage CPU, mémoire, espace disque, I/O, trafic réseau, charge système. C’est le panneau de contrôle de votre serveur.

Étape 6 : Mettre en place les alertes Telegram

L’intérêt du monitoring, c’est d’être prévenu. On configure Telegram dans les deux outils.

Créer un bot Telegram

1. Dans Telegram, cherchez @BotFather, lancez-le et envoyez /newbot.

2. Choisissez un nom et un identifiant pour le bot. BotFather vous donne un token (du type 123456789:AAH...).

3. Démarrez une conversation avec votre nouveau bot (envoyez-lui un message quelconque).

4. Récupérez votre chat ID : ouvrez dans un navigateur https://api.telegram.org/bot<VOTRE_TOKEN>/getUpdates et repérez le champ chat.id dans la réponse JSON.

Alertes dans Uptime Kuma

1. Dans Uptime Kuma : Settings > Notifications > Setup Notification.

2. Type Telegram, collez le Bot Token et le Chat ID.

3. Cliquez Test pour recevoir un message de vérification, puis Save.

4. Éditez vos monitors et cochez cette notification : vous serez alerté à chaque passage UP → DOWN et au rétablissement.

Alertes système via Grafana

Pour être prévenu quand le disque dépasse 85 % ou la RAM 90 %, créez une règle d’alerte dans Grafana :

1. Alerting > Contact points > Add contact point, type Telegram, renseignez token et chat ID, testez.

2. Alerting > Alert rules > New alert rule. Définissez une requête PromQL, par exemple pour l’espace disque utilisé sur la racine :

100 - ((node_filesystem_avail_bytes{mountpoint="/"} * 100) / node_filesystem_size_bytes{mountpoint="/"})

3. Fixez la condition « IS ABOVE 85 » sur une fenêtre de 5 minutes, associez le contact point Telegram, et enregistrez.

Vous recevrez désormais un message dès qu’un seuil critique est franchi, avant que ça ne devienne un incident.

Vérification de la stack

Faites le tour de contrôle :

# Les quatre services tournent

docker compose ps



# Prometheus a bien la cible node en UP (renvoie "up")

curl -s 'http://localhost:9090/api/v1/query?query=up{job="node"}' | grep -o '"value":\[[^]]*\]'



# node_exporter répond

curl -sI http://localhost:9100/metrics | head -1

Provoquez un test réel : arrêtez volontairement un service surveillé par Uptime Kuma (docker stop <service>), attendez l’intervalle de vérification, et confirmez que vous recevez bien l’alerte Telegram, puis le message de rétablissement après redémarrage.

Bonnes pratiques et sécurité

• Ne pas exposer les ports en clair. Placez Grafana, Prometheus et Uptime Kuma derrière votre reverse proxy Caddy en HTTPS. Prometheus en particulier n’a aucune authentification native : il ne doit jamais être accessible publiquement.

• Sauvegardez les volumes. Les configurations Uptime Kuma, les dashboards Grafana et l’historique Prometheus vivent dans les volumes Docker. Incluez-les dans votre stratégie de backup (voir sauvegardes chiffrées avec restic).

• Surveillez les machines distantes. Installez node_exporter sur chaque machine de votre homelab et ajoutez-les comme cibles dans prometheus.yml. Sécurisez le scraping inter-machines via le VPN WireGuard plutôt qu’en clair.

• Définissez une rétention raisonnable. --storage.tsdb.retention.time=30d évite que Prometheus ne remplisse le disque. Augmentez si vous avez besoin d’historique long, en surveillant l’espace.

• Alertes utiles, pas bruyantes. Trop d’alertes tue l’alerte. Réservez les notifications aux événements actionnables (service down, disque plein, certificat expirant) et regroupez le reste dans les dashboards.

FAQ

Uptime Kuma et Grafana ne font-ils pas la même chose ?

Non, ils sont complémentaires. Uptime Kuma répond à « est-ce que ça répond ? » (disponibilité, vu de l’extérieur) avec une mise en place quasi instantanée. Grafana + Prometheus répondent à « comment ça se porte à l’intérieur ? » (métriques système détaillées, tendances, capacité). Les utiliser ensemble donne une vision complète. Notre comparatif Uptime Kuma vs Grafana vs Netdata détaille les forces de chacun.

Quelle charge cette stack impose-t-elle au serveur ?

Modeste. node_exporter est négligeable, Uptime Kuma tient dans ~100 Mo de RAM, Prometheus et Grafana consomment selon le nombre de cibles et la rétention, mais quelques centaines de Mo suffisent pour un homelab classique. Le principal poste est le disque pour l’historique Prometheus, maîtrisé par la durée de rétention. Un petit VPS ou un mini-PC suffit largement.

Pourquoi pas Netdata, qui s’installe en une commande ?

Netdata est excellent pour un diagnostic en temps réel ultra-détaillé sur une machine, avec une installation triviale. Mais pour centraliser plusieurs machines, conserver un historique long et personnaliser des tableaux de bord et alertes, la combinaison Prometheus + Grafana reste plus flexible et standard. Rien n’empêche de faire cohabiter Netdata localement et Grafana en central.

Comment surveiller mes conteneurs Docker eux-mêmes ?

Ajoutez cAdvisor à la stack : il expose des métriques par conteneur (CPU, RAM, réseau, I/O) que Prometheus collecte comme node_exporter. Importez ensuite un dashboard Grafana dédié aux conteneurs Docker (plusieurs sont disponibles dans la galerie). Vous distinguez alors quel conteneur consomme quoi.

Les alertes fonctionnent-elles si le serveur de monitoring tombe lui-même ?

Non, et c’est une limite classique : un système ne peut pas s’alerter de sa propre panne. La solution est une supervision externe. Utilisez un service tiers (ou une seconde instance Uptime Kuma sur une autre machine/VPS) pour surveiller la disponibilité de votre serveur de monitoring. Ainsi, si toute la stack tombe, vous êtes quand même prévenu.

🛒 Matériel recommandé

Pour ce projet, voici le matériel que nous conseillons (liens Amazon) :

• Mini PC homelab
• SSD NVMe

En tant que Partenaire Amazon, Selfhostr réalise un bénéfice sur les achats remplissant les conditions requises — sans surcoût pour vous.

Sur le même sujet

• Uptime Kuma vs Grafana vs Netdata : quel outil de supervision

• Reverse proxy HTTPS automatique avec Caddy et Docker

• Sauvegardes chiffrées automatiques avec restic et Backblaze B2

• Meilleur VPS pour le self-hosting en 2026

Votre homelab est désormais sous surveillance : disponibilité, métriques système et alertes instantanées. Vous saurez avant tout le monde quand quelque chose ne tourne pas rond. Pour suivre les nouveaux outils de monitoring, les failles et les bons plans VPS, rejoignez notre bot de veille Telegram.