Serveur : vps-cloud-tp — Infomaniak Public Cloud (OpenStack)
Date d'intervention : 12 août 2026
Mise en place d'une supervision avec alertes sur les ressources critiques
(RAM, CPU, stockage), en réponse directe à l'incident documenté dans
Remise en service et sauvegarde :
le serveur est resté hors service une semaine sans que personne ne s'en
aperçoive, faute d'outil d'observation.
Entre Netdata et Grafana + Prometheus, Netdata est retenu : détection
automatique, alertes préconfigurées, empreinte mémoire faible (~120 Mo) —
adapté à une instance à 1 vCPU / 2 Go de RAM dans un cadre de découverte.
curl -fsSL https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
sudo sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry
Point de méthode : le script est téléchargé et inspecté avant exécution,
plutôt qu'exécuté directement en root depuis Internet — réflexe attendu en
environnement professionnel.
Impact mesuré : +116 Mo de mémoire (~6 % du total) pour la surveillance
complète de la machine — compromis jugé acceptable.
Par défaut, Netdata écoute sur toutes les interfaces (0.0.0.0:19999),
sans authentification. Seul le groupe de sécurité OpenStack empêchait un
accès externe.
Fichier /etc/netdata/netdata.conf :
[web]
bind to = 127.0.0.1
sudo systemctl restart netdata
ssh -i cle-vps-cloud.pem -p 2222 -L 19999:localhost:19999 ubuntu@179.237.76.136
Tableau de bord accessible sur http://localhost:19999 depuis le poste local,
sans port supplémentaire ouvert, trafic chiffré par SSH.
| Ressource | Avertissement | Critique |
|---|---|---|
| Mémoire utilisée | > 80 % | > 90 % |
| Processeur (moyenne 10 min) | > 75 % | > 85 % |
| Espace disque | > 80 % | > 90 % |
Les trois ressources exigées par le programme sont couvertes sans
configuration supplémentaire, chargées depuis
/usr/lib/netdata/conf.d/health.d/.
sudo apt install stress-ng -y
stress-ng --cpu 1 --timeout 90s --metrics-brief
Charge de 100 % sur le vCPU unique pendant 90 secondes, observée en temps réel
sur le tableau de bord (Avg CPU per Node à 100 %). Wiki.js reste accessible,
simplement ralenti.
oom_kill a posteriori).