Monitorer Incus avec Prometheus, Grafana et Alertmanager — observabilité PME 2026

📍 Article principal du sujet : Incus 6 LTS — gérer conteneurs système et VMs Linux pour PME ouest-africaine

Sans observabilité, on exploite Incus à l’aveugle. Tant que tout va bien, c’est invisible ; le jour où un conteneur consomme 6 Go de RAM par fuite mémoire ou qu’un disque sature à 95 %, on apprend la mauvaise nouvelle par le client. La parade industrielle : Prometheus pour la métrologie, Grafana pour la visualisation, et un alerting sur les seuils critiques. Bonne nouvelle, Incus expose nativement un endpoint /1.0/metrics au format Prometheus depuis la version 5.0 — pas besoin d’exporter intermédiaire à maintenir.

Ce tutoriel monte la stack complète sur le même Hostinger Cloud VPS que la production : Prometheus dans un conteneur Incus dédié, Grafana dans un autre, Alertmanager pour les notifications, et des dashboards prêts à l’emploi pour visualiser la consommation par instance, l’état du pool de stockage, la charge réseau et la santé du démon Incus.

Pourquoi l’endpoint natif Incus plutôt que node_exporter

node_exporter est l’exporter Prometheus de référence pour métriques système Linux : CPU, RAM, disque, réseau de l’hôte. Il fait excellement bien son travail mais ne sait pas distinguer ce qui est consommé par chaque instance Incus — il voit la machine globale. L’endpoint /1.0/metrics d’Incus, lui, ventile les métriques par instance et par pool, ce qui change tout pour identifier le coupable d’une saturation.

La bonne combinaison : node_exporter sur l’hôte pour les métriques système, et le scraper Incus en parallèle pour les métriques par conteneur. Les deux flux arrivent dans Prometheus et se croisent dans les dashboards Grafana — typiquement « consommation RAM totale hôte » vs « somme des consommations par conteneur » donne la consommation hors-conteneur (démon Incus, ARC ZFS, processus admin).

Prérequis

• VPS Linux 64 bits, 4 Go RAM minimum, 60 Go SSD
• Incus 6 LTS opérationnel — voir Installer Incus avec Zabbly
• Caddy installé sur l’hôte pour exposer Grafana en HTTPS
• Niveau attendu : confortable Linux, notion de Prometheus et de scrape config
• Temps estimé : 90 minutes pour la stack complète avec dashboards

Étape 1 — Activer l’endpoint metrics côté Incus

# Sur l'hôte Incus
sudo incus config set core.metrics_address ":8443"
# Vérifier que le démon écoute
sudo ss -tlnp | grep 8443

L’endpoint expose les métriques sur le port 8443. Par défaut il exige une authentification TLS par certificat client — bonne pratique de sécurité, mais qui complique légèrement le scrape par Prometheus. Pour un setup simple, on génère un certificat client dédié à Prometheus.

sudo openssl req -x509 -newkey rsa:4096 -nodes \
  -keyout /etc/incus-prometheus/key.pem \
  -out /etc/incus-prometheus/cert.pem \
  -days 3650 -subj "/CN=prometheus"
sudo incus config trust add-certificate /etc/incus-prometheus/cert.pem --type=metrics

Le type metrics limite ce certificat à la lecture des métriques — il ne peut pas créer ou supprimer d’instances, même si quelqu’un compromettait Prometheus. Principe du moindre privilège appliqué proprement.

Étape 2 — Conteneur Prometheus

incus launch images:debian/12 prometheus-srv
incus shell prometheus-srv

apt update && apt install -y prometheus
# Récupérer les certificats clients depuis l'hôte
mkdir -p /etc/prometheus/incus-cert
exit

# Sur l'hôte, transférer les certs
incus file push /etc/incus-prometheus/cert.pem prometheus-srv/etc/prometheus/incus-cert/
incus file push /etc/incus-prometheus/key.pem prometheus-srv/etc/prometheus/incus-cert/
# Récupérer le cert du serveur Incus pour la verif
sudo cat /var/lib/incus/server.crt | incus exec prometheus-srv -- tee /etc/prometheus/incus-cert/server.crt

Le certificat serveur est nécessaire pour que Prometheus valide qu’il parle bien à un démon Incus authentique et pas à un MITM. C’est cette étape qu’on néglige souvent et qu’on regrette quand un audit de sécurité le pointe du doigt.

Étape 3 — Configurer le scrape Prometheus

incus shell prometheus-srv
cat <<'EOF' > /etc/prometheus/prometheus.yml
global:
  scrape_interval: 30s
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'incus-host'
    scheme: https
    static_configs:
      - targets: ['10.124.10.1:8443']
    tls_config:
      cert_file: /etc/prometheus/incus-cert/cert.pem
      key_file: /etc/prometheus/incus-cert/key.pem
      ca_file: /etc/prometheus/incus-cert/server.crt
      server_name: incus
    metrics_path: /1.0/metrics

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['10.124.10.1:9100']

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
EOF
systemctl restart prometheus
exit

L’IP 10.124.10.1 est celle du bridge incusbr0 côté hôte vue depuis le conteneur Prometheus. Vérifier avec incus exec prometheus-srv -- ip route : la route par défaut pointe vers le bridge. Si l’IP diffère sur votre setup, ajuster en conséquence.

Étape 4 — node_exporter sur l’hôte

# Sur l'hôte Incus directement (pas dans un conteneur)
apt install -y prometheus-node-exporter
systemctl enable --now prometheus-node-exporter
ss -tlnp | grep 9100
# Doit montrer node_exporter écoutant sur 9100

Le firewall hôte doit autoriser le bridge incusbr0 à accéder au port 9100. Sur Ubuntu avec UFW : sudo ufw allow from 10.124.10.0/24 to any port 9100. Sans cette règle, Prometheus dans son conteneur ne pourra pas scraper l’hôte.

Étape 5 — Conteneur Grafana

incus launch images:debian/12 grafana-srv
incus shell grafana-srv

apt update
apt install -y apt-transport-https software-properties-common wget
mkdir -p /etc/apt/keyrings
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor > /etc/apt/keyrings/grafana.gpg
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" \
  > /etc/apt/sources.list.d/grafana.list
apt update
apt install -y grafana
systemctl enable --now grafana-server
exit

Grafana écoute sur le port 3000 par défaut. On l’expose ensuite via Caddy avec HTTPS automatique pour qu’on puisse y accéder depuis n’importe quel navigateur sans tunnel SSH manuel.

# Sur l'hôte
incus list -c n4 grafana-srv --format csv
# grafana-srv,10.124.10.71

cat <<'EOF' >> /etc/caddy/Caddyfile
metrics.example.org {
  reverse_proxy 10.124.10.71:3000
}
EOF
systemctl reload caddy

Étape 6 — Configurer les data sources et dashboards

Pointer son navigateur vers https://metrics.example.org, login admin/admin (à changer immédiatement). Configurer une source de données Prometheus :

• Type : Prometheus
• URL : http://10.124.10.70:9090 (l’IP du conteneur prometheus-srv)
• Save & Test : doit retourner « Data source is working »

Pour le dashboard, Grafana propose un import par ID depuis grafana.com. Le dashboard officiel Incus (ID 19131) couvre les bases : RAM/CPU/disque par instance, état du pool, débit réseau, état du démon. Pour l’hôte global, le dashboard node_exporter (ID 1860) est la référence.

# Dans Grafana : + → Import → entrer ID 19131 → sélectionner data source Prometheus → Import

En quelques secondes, vous voyez les graphes en temps réel. Le panneau « Memory usage by instance » est le plus utile au quotidien — il révèle d’un coup d’œil quel conteneur consomme trop, sans avoir à interroger l’API.

Étape 7 — Alertmanager pour les notifications

Sans alerting, le dashboard est utile pour les diagnostics post-mortem mais ne réveille personne quand ça brûle. Alertmanager pousse les notifications vers email, Slack, Discord, Telegram ou un webhook custom.

incus shell prometheus-srv
apt install -y prometheus-alertmanager
cat <<'EOF' > /etc/prometheus/alertmanager.yml
global:
  smtp_from: 'monitoring@example.org'
  smtp_smarthost: 'smtp.exemple.org:587'
  smtp_auth_username: 'monitoring@example.org'
  smtp_auth_password: 'mot-de-passe-app'

route:
  receiver: admin-mail
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: admin-mail
    email_configs:
      - to: 'admin@example.org'
EOF

cat <<'EOF' > /etc/prometheus/alerts.yml
groups:
  - name: incus
    rules:
      - alert: IncusInstanceMemoryHigh
        expr: incus_memory_Active_bytes / incus_memory_MemTotal_bytes > 0.9
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "Conteneur {{ $labels.name }} > 90% RAM"
      - alert: IncusDiskSpaceLow
        expr: incus_disk_used_bytes / incus_disk_total_bytes > 0.85
        for: 5m
        labels: { severity: critical }
        annotations:
          summary: "Pool {{ $labels.name }} > 85% rempli"
EOF
systemctl restart prometheus prometheus-alertmanager
exit

Au premier déclenchement, Alertmanager attend 30 secondes pour grouper les alertes (évite la pluie de mails), puis envoie le résumé. Pour Slack ou Discord, remplacer la section email_configs par slack_configs ou webhook_configs.

Étape 8 — Persistance et résilience

Une stack monitoring qui tombe avec le service qu’elle surveille n’est pas très utile. Trois recommandations pour un setup réaliste :

• Snapshots quotidiens des conteneurs prometheus-srv et grafana-srv via le pipeline backup déjà en place — voir Backup distant chiffré vers S3.
• Retention Prometheus : par défaut 15 jours, à monter à 30 ou 90 jours selon les besoins via --storage.tsdb.retention.time=90d.
• Healthcheck externe : un service comme Healthchecks.io qui pingue Prometheus toutes les 5 minutes vous prévient si tout votre VPS tombe d’un coup.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour une agence dakaroise qui héberge 30 conteneurs Incus, la stack monitoring tient dans 1 Go de RAM total (Prometheus + Grafana + Alertmanager). Sur un VPS Hostinger 8 Go déjà occupé par les services productifs, c’est insignifiant — moins de 5 % de la mémoire utilisée pour une visibilité totale.

L’argument différenciant face à un concurrent qui exploite à l’aveugle : la capacité à anticiper les problèmes. Un client qui appelle parce que son site rame, on a déjà reçu l’alerte 30 minutes avant et on est en train d’enquêter. La perception de qualité de service grimpe sans avoir à recruter du personnel supplémentaire.

Pour les contrats SLA qu’on signe avec des PME exigeantes (banques, assurances, ministères), Grafana fournit aussi le reporting mensuel qui sert à prouver le respect des engagements : taux de disponibilité par service, temps de réponse moyen, incidents catégorisés. C’est le genre de livrable qui fait la différence entre un prestataire amateur et un prestataire pro.

Tutoriels frères

• Backup distant chiffré des conteneurs Incus — pour sauvegarder la stack monitoring elle-même.
• Héberger 100 conteneurs Incus sur un seul VPS — où le monitoring devient indispensable.
• Logs centralisés Loki et Promtail pour Incus — l’étape suivante après les métriques.

Pour aller plus loin

• 🔝 Retour à l’article principal sur Incus
• Documentation officielle Incus metrics
• Documentation Prometheus
• Dashboard Grafana officiel Incus (ID 19131)
• Pour pratiquer : Hostinger Cloud VPS

FAQ

Combien de conteneurs Prometheus peut-il scraper ?
Plusieurs centaines sans problème sur la stack proposée. Le facteur limitant est la cardinalité des labels (chaque instance × chaque métrique). Pour un parc de 100 conteneurs avec 30 métriques chacune, on est très loin des limites.

Grafana Cloud gratuit suffit-il ?
10 000 séries gratuites, ça couvre 30 à 50 conteneurs. Au-delà, l’auto-hébergement coûte moins cher et offre la souveraineté des données.

Différence avec VictoriaMetrics ?
VictoriaMetrics est plus léger en RAM et plus rapide en query pour de gros volumes. Pour moins de 100 conteneurs, Prometheus standard est largement suffisant.

Stocker les métriques sur S3 ?
Pas directement avec Prometheus standard. Thanos ou Grafana Mimir le permettent ; complexité supérieure, intéressant à partir de plusieurs téraoctets de métriques historiques.

Comment alerter via Telegram ?
Créer un bot Telegram avec @BotFather, récupérer le token, créer un canal, ajouter le bot, et utiliser le webhook generic d’Alertmanager pour pousser les messages au bot.